From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cc4f25d878383cc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-07 21:28:06 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!howland.erols.net!news-out.worldnet.att.net.MISMATCH!wn3feed!wn2feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc52.POSTED!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada References: <3C0AACCE.329CFB60@worldnet.att.net> <45601fc.0112031740.3e217c8a@posting.google.com> <3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com> <3C0EF0A0.9F42EDB4@adaworks.com> <7KbQ7.13821$L51.28784@rwcrnsc54> <3C118E95.B5F013C8@adaworks.com> Subject: Re: Dimensions (was Re: Another Idea for Ada 20XX) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Sat, 08 Dec 2001 05:28:05 GMT NNTP-Posting-Host: 204.127.202.213 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52 1007789285 204.127.202.213 (Sat, 08 Dec 2001 05:28:05 GMT) NNTP-Posting-Date: Sat, 08 Dec 2001 05:28:05 GMT Organization: AT&T Broadband Xref: archiver1.google.com comp.lang.ada:17625 Date: 2001-12-08T05:28:05+00:00 List-Id: "Richard Riehle" wrote in message news:3C118E95.B5F013C8@adaworks.com... > Mark Lundquist wrote: > > > > I have no idea what you're getting at with the "helper type to avoid > > recursion"... :-) > > In implementing the infix operators for an experimental version of this > package, I found myself having to solve the problem of having the > full definition of the type as a numeric type itself. Hmm, if I'm understanding this correctly, it's you always have this problem when deriving privately and re-exporting the primitives of the base type (it's not unique to numeric types and/or infix operators). You can always convert up to the base type and back down again in the body of the primitive, right? Anyway, this is OT from our dimensions discussion, sorry... > > Actually, I think (a) is worse than (b). One could define the package > as generic and include generic formal parameters for the range constraints. That gives you something analogous to declaring a type whose first subtype is constrained (in fact I guess that's just how you would write the full type definition in your generic spec), where you do not intend to create any other subtypes. That's pretty limiting... you get nowhere near the full power of the subtyping system. > In fact, I designed some generics to test this and found that the real problems > are: 1) no notion of zero I hadn't thought of that... yeah, that is a problem. > > > (e) , (f), and (g) from your posting. > > I give you the points on those. > > My suggestion, however, does work for some situations. Sure, but it's survival, it's no way to live :-) > > Meanwhile, I am experimenting with other options that might permit a solution > without new language features. I will report on my findings if they are at all > interesting. > Sounds good :-) -- Mark