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-Thread: 103376,c1fe4bc1dd51fc87 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: User-defined type attributes Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <30f629fd-69d3-4d40-995f-9933f52b8dad@s37g2000prg.googlegroups.com> Date: Thu, 13 Mar 2008 20:58:15 +0100 Message-ID: <965suhjl0bxt$.74se2ylyksin.dlg@40tude.net> NNTP-Posting-Date: 13 Mar 2008 20:58:15 CET NNTP-Posting-Host: df509a99.newsspool1.arcor-online.net X-Trace: DXC=]B9lgYHA?]nm7>ihJR;B_cic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgb6VSnhTQTBJe[6LHn;2LCVn[ On Thu, 13 Mar 2008 11:32:23 -0700 (PDT), Eric Hughes wrote: > On Mar 12, 3:23 pm, "Dmitry A. Kazakov" > wrote: >> Attributes in Ada aren't necessarily static, even type's attributes aren't. >> To me static functions is an independent, yet important issue. > > Most attributes are completely static. The ones that aren't (like > T'Callable, E'Caller) seem all to be of a kind that (1) statically > return a function (2) whose first parameter is the type of the object, > and then (3) apply it to that object. In which sense function is static? If understand what you wrote, it simply means that the name "Callable" is static. Yes it is. > Given that this is at least in > the spirit of a preelaborable attribute, there's the possibility of > treating these cases as syntactic shorthand: Obj'Attr for > Obj'Attr( Obj ), or alternately for Obj.Obj'Attr. Yes, as well as, Attr (Obj), which would be IMO a better way. I think everybody is tired writing Integer'Image(X) rather than X'Image. > I did a brief scan > of ARM05/Annex-K just now, and this applies to all the cases I found > (which were all tasking or type attributes). Nevertheless the result is not static, thus it cannot be used, say, in a declaration of a modular type. I consider this issue as fully independent. We need static functions beyond attributes. Consider pattern matching: loop if Match (Text, Pattern ("*.ada")) then there is no way to define Pattern in a way that would force the compiler to translate "*.ada" at compile time. > So I'll modify my idea to deal with historical syntax: > 1) The definition of an attribute function has a static expression. > 2) The syntax for invoking an attribute may imply a dynamic function > call. > > Such implicit calls generate a syntax ambiguity between "attribute > procedure Op( X : T )" and "attribute procedure Op( X : T ; Y : T )" > when invoking with only positional parameters. What would > Obj'Op( Obj ) mean? I assume this can be adequately addressed. > >> In my view attributes should be primitive operations. I would handle them >> similarly to prefix notation. I.e. X(Y,Z), Y.X(Z), Y'X(Z) considered >> equivalent. > > The whole point of user attributes is to gain cleaner syntax for > referring to the environment of a type or object, that which is > available at pre-elaboration time, and supports generic programming > better. Without such a syntax there are lots more formal parameters > that need to be forwarded around. Why? The only thing you need is formal generic ADTs. Ada's generics lack ADTs, which is the reason why you need to pass operations together with the formal types. There exist formal built-in types like "private", "<>", "digits <>" etc, but there is no user-defined ones. Add these and all primitive operations will go with the actual type just per magic. It would be IMO a natural step for anybody who wanted generics to evolve in an Ada-way. (Not for me, as you know, I prefer generics removed from the language.) > Just making attributes run-time functions eliminates a useful > distinction. Functions on a type are part of the tradition algebraic > specification of a type. Attributes on a type are part of the > language environment inside of which a type specification is > expressed. These are very different. I don't see why this distinction is important. Anyway it leaks, because you certainly need constrained types in the types algebra. This brings discriminants with it. Do you want to introduce attributes for the discriminants of a subtype? Like X'Tag? which is of course merely a discriminant. I think it would be an overkill. Then what would you do with 'Pos, 'Succ, 'Adjacent etc attributes which have nothing to do with types algebra? In my view this distinction just does not hold since Ada 95, because that introduced user-defined classes. In my view attributes in Ada 83 meant mere "magical things", meta-subprograms which profiles cannot be spelt in the language. This has changed, we can spell most of them now as proper primitive subprograms. More elaborated class model of Ada will become less "magical things" will remain. I think now X'Y notation should be considered as pure syntax sugar, with no semantics. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de