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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,103b407e8b68350b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-16 10:19:47 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!fu-berlin.de!uni-berlin.de!dialin-145-254-045-211.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Anybody in US using ADA ? One silly idea.. Date: Thu, 16 Jan 2003 19:20:27 +0100 Organization: At home Message-ID: References: <1041908422.928308@master.nyc.kbcfp.com> <1041997309.165001@master.nyc.kbcfp.com> <1042086217.253468@master.nyc.kbcfp.com> <1042477504.547640@master.nyc.kbcfp.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-045-211.arcor-ip.net (145.254.45.211) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1042741186 23217223 145.254.45.211 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:33096 Date: 2003-01-16T19:20:27+01:00 List-Id: Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >> Hyman Rosen wrote: >> >> > Dmitry A. Kazakov wrote: >> >> I agree. As I said, it is a long way to go to get rid of generics. >> > >> > And as I said, I have no idea why you would want to. >> >> I think I explained why. > > You explained why, but I didn't see any explanation of what you would > like to do instead. You are the first who asks. (:-)) > Clearly, I should be able to write a "stack" abstraction (or other data > structure) that takes any type as element. And I shouldn't have to > write it more than once. And I should be able to constrain any > particular stack to have a particular element type, with this type > checked at compile time. (Or, I can use a class-wide type as the > element, if I want any type in a class.) > > I'd be interested to know if you have something in mind that meets these > criteria. Tagged types in Ada (or the corresponding feature in most > other languages) don't give you the compile-time checking. > > It seems to me that if the feature is not generics or templates, > then it would at least have to share some properties with those > features. OK, here is my program of how containers could be made non-generic. I haven't worked out all details and I do not even know if it is possible. This is a program, not a solution or proposal for Ada2005. --- If we consider stack (container) then the first question is what is the class of types which can be used with it. We want to 1. have an ability to specify the class as a type 2. have it open (extensible) 3. clone the class (typed containers) The minimal requirement is an ability to copy the element (sort of "type X is private"). type Element is abstract tagged null record; Here the first deviation from Ada comes. All types have to be tagged [in the sense of existing T'Class] and there should be a way to explicity say that a type has [or has to have] copy-constructor: type Element is abstract; ?function? (Source : Element) return Element is abstract; The stack could be defined as an array of Element'Class. It is impossible in Ada for many reasons, but the major is that the size of Element'Class is unknown. A thinkable way could be to make a constrant for it a discriminant of the array. Clearly there should be a way to bind Element and Stack as an array type and its element are bound. Frankly, I do not know yet. type Stack (?) is private; procedure Push (...); That multiple inheritance is inevitable is clear. We definitely want no more problems like with Root_Stream_Type. Now if we want a new type to be used with the stack, we just derive it from Stack'Element as a subtype. The crucial point is what to do with already existing types. There is a solution for this. The language should allow not only subtyping, but also supertyping. Let we want to put Integer into the stack. Then we could create a new "bridge" type which is *both* a subtype of Stack'Element and a supertype of Integer. This would have an effect of making Integer a subtype of Element. By the way this feature would also solve many other problems. This also should mean that deriving should no more determine the representation of the new type, if not explicitly specified. Typed (=>compile-time checkable) containers should be no problem if Element and Stack are bound. One could use sort of "type X is new Y;" to clone them into a new pair and then derive from new Stack'Element. Performance should not be an issue, if Push and Pop are inlined and types (=tags) are statically known. So it should be as efficient as generics are. However this also requires some rework. The language should require [if programmer wants] absence of discriminants and tags in specific objects (statically known constraints). I belive it is already the case for array bounds, correct me if I am wrong. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de