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.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,86b85dca70d5fd7a,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-27 00:20:04 PST Path: supernews.google.com!sn-xit-02!sn-xit-01!supernews.com!newsfeed.stanford.edu!xfer10.netnews.com!netnews.com!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: mark_lundquist@my-deja.com Newsgroups: comp.lang.ada Subject: Ada '0x generics brain-fartz (long) Date: Wed, 27 Dec 2000 08:10:24 GMT Organization: Deja.com Message-ID: <92c85f$qir$1@nnrp1.deja.com> NNTP-Posting-Host: 130.213.202.149 X-Article-Creation-Date: Wed Dec 27 08:10:24 2000 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-Http-Proxy: 1.1 x65.deja.com:80 (Squid/1.1.22) for client 130.213.202.149 X-MyDeja-Info: XMYDJUIDmark_lundquist Xref: supernews.google.com comp.lang.ada:3400 Date: 2000-12-27T08:10:24+00:00 List-Id: There haven't been too many times when I've wanted Ada95 to do something more or different than it already does. The few times I have, it usually turns out that someone else has already thought it through long before and more thoroughly (like "limited access"... BTW I still want it :-). I've seen plenty of ideas for "improvements" to Ada that are unnecessary and/or unworkable and/or bizarre. So I humbly submit an idea... actually two ideas... for improvements to Ada. Although as essentially convenience features they border on "unncessary", to my limited brain they seem like the might be workable, and they don't seem "bizarre" -- that is, they seem like they fall within the "spirit" of Ada rather than doing violence to it. CAVEAT EMPTOR: This is totally half-baked cerebroflatulence. It may be crap! OK, idea #1: "generic specialization". The thought is that you could have a construct that could bind some (but not necessarily all) actual parameters to formals in the manner of an instantiation. This construct creates a new generic, which can then be instantiated in the normal way (or, of course, further specialized). The idea is somewhat analogous to the constraining of a subtype. As a generic, it could be named in a formal_package_declaration. In addition, the package form of this construct might be allowed to have its own declarative region (and its own private part). If that part contained constructs that required completions, then a body would be required. The idea here is loosely analogous to a derived type adding new (that is, non-inherited) primitives. Finally: an instance of a generic package specialization (crappy term, but I'm not worried about that now) would (potentially) match a formal_package_actual_part as an instance of any generic (package or package specialization) that it (directly or indirectly) specializes. To extend the derivation analogy, a hierarchy of generic specializations would constitute a "specialization class" -- the closure over specialization, and the matching rules for generic formal packages would be modified so as to be "class-wide" with respect to this "specialization class". (If this analogy helps you understand the idea, great... if not, then just forget it :-)... the analogy was not what gave me the idea). I have in mind a syntax something like this: generic new [] package_specification; The generic_actual_part has to be complete, just like in an instantiation of the named generic package. But since the formal parameter declarations of this construct are visible here, they can be named in the generic_actual_part -- this "passes through" parameters of the specialization to the generic being specialized. And of course, an (explicit) actual parameter to the specialized generic can be an expression that includes some of the formal parameters to the specialization. Example: -- A normal generic package... -- generic with type T is private; Size : Positive; Frutzable : Boolean; package Base is Snarkify (This : in out T); Desnarkify (This : in out T); end Base; -- -- A specialization! -- type My_Type is -- or, think "formal type of an -- enclosing generic"... generic Size : Positive; Frutzable : Boolean; new Base (My_Type, Size, Frutzable) package Special is Refloobimerize (This : in out My_Type); end Special; -- A further specialization -- generic Exooberated : Boolean; new Special ( Size => 20, -- (named association this time) Frutzable => Exooberated and not Something_Else ) package More_Special is end More_Special; . . . -- An instantiation -- package P is new More_Special (Exooberated => False); X : My_Type; begin . . . P.Snarkify (X); -- (from the "base" generic) P.Refloobimerize (X); -- (from a specialization) . . . -- -- In a generic formal package -- generic with package Template is new Base (<>); package Gee is end Gee; -- Instantiation of a specialization of Base (via Special), -- just like in the earlier example: -- package Pee is new More_Special (Exooberated => False); package Gee_Pee is new Gee (Template => Pee); -- -- ...So Gee_Pee gets a "view" of Pee as an instance of Base. -- Do you know why I came up with this idea? Neither do I! :-) Except that I seem to remember thinking that it would save a lot of renames in certain situations! Get it? Another application of this idea would be where you have a base generic with a formal type that makes fewer assumptions (that is, creates a _more_ restrictive view, e.g. limited, or with unknown discriminants, or abstract tagged vs. not abstract) and then extend it by a specialization, with a formal type that makes more assumptions (e.g. tagged vs. ?, unlimited, etc.) and adds new operations that would be have been illegal in the base generic due to the more restrictive view of the type. Now you have a generic that can be instantiated on some types and provides the base functionality, and another generic that would be instantiable for a subset of those types allowed for the base generic, which would provide the base functionality plus extended functionality that only makes sense for the types in the subset (you instantiate the specialization, not the base and the specialization). Make sense? This application is really a special case of the "lots of renames" scenario, because the way you do this in Ada95 is to use lots of renames (and in Ada95, adding functionality to the "base" requires a cascade of modifications to the extended/specialized forms to propagate the new declarations). Visibility of private parts would be like for child packages -- the private part and body of a specialization can see the private parts of whatever it's (transitively) specializing. Not sure about bodies yet (like I said... half-baked idea). OK, here is the much shorter Idea Number Two: anonymous instantiation. No windy discussion required here, you can figure it out from an example: -- Normal Ada95... -- generic package Gen is end Gen; -- Still normal... -- generic package Template is new Gen (<>); package Eric is end Eric; -- An anonymous instantiation! -- package Gen_Eric is new Eric (Template => new Gen (); The purpose is to lower syntactic overhead and increase clarity, when you're building chains of generic instantiations where the only purpose of some instantiations is to serve as actuals to generic formal packages (in particular with the "signature package" idiom, but by no means just in that case). OK, shoot me down in flames! Who knows what hideous ramifications lurk, what broken invariants? I leave it to the language lawyers... -- mark Mark Lundquist Rational Software Sent via Deja.com http://www.deja.com/