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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b5ab7c96b188b59e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-13 08:29:02 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!cyclone1.gnilink.net!spamkiller2.gnilink.net!nwrdny03.gnilink.net.POSTED!0f19ed38!not-for-mail From: "Frank J. Lhota" Newsgroups: comp.lang.ada References: Subject: Re: The "()" operator revisited. X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Tue, 13 Jan 2004 16:29:02 GMT NNTP-Posting-Host: 151.203.203.2 X-Complaints-To: abuse@verizon.net X-Trace: nwrdny03.gnilink.net 1074011342 151.203.203.2 (Tue, 13 Jan 2004 11:29:02 EST) NNTP-Posting-Date: Tue, 13 Jan 2004 11:29:02 EST Xref: archiver1.google.com comp.lang.ada:4367 Date: 2004-01-13T16:29:02+00:00 List-Id: "Robert A Duff" wrote in message news:wcck73w9536.fsf@shell01.TheWorld.com... > "Frank J. Lhota" writes: > > > Last June, I proposed that in order to provide an abstract array capability, > > Ada 0y should support user-defined "()" and "():="operators. Since this > > issue has come up again, I would like to summarize and expand on this > > proposal. > > This is a good idea. As you note below, it's got a long way to go > before you've got a list of wording changes to the RM. For example, the > notion of operator-named *procedures* does not currently exist in Ada. First, I'm glad you like the idea. Granted, Ada does not have operator-named procedures, but there has been discussions about making ":=" an operator. > But before bothering with that, I think there are some important > issues to work out: > > You seem to be saying that components of arrays (or just abstract > arrays?) are always passed by copy. That seems like a real problem, > since for efficiency, most compilers pass large things by reference. > (I'm talking about the case of array-of-large-array or > array-of-large-record.) I did not mean to imply anything about the parameter passing convention used. Clearly, we need to support all parameter passing conventions, since any type can be used as an array component. The confusion probably arose from the discussion of passing an array component as a parameter of mode "in out". Now if the array component is aliased, passing the component by reference is easy: simply pass the address of the component. If the component is not aliased, as is often the case, this method would not work. The way many compilers (including GNAT) handle passing a packed component to a subprogram is: - Create a temporary variable of the given component type; - If the parameter is of mode "in" or "in out", unpack the array component into the temporary variable; - Pass this temporary variable to the subprogram; and - If the parameter is of mode "out" or "in out", pack the temporary variable value into the array component. Note that although this requires a temporary copy, it does NOT require that the subprogram parameter use pass by copy. Given that this is done currently for packed arrays, there is no good reason why this cannot be done for the proposed abstract > Furthermore, if the component type is limited, it is *required* to be > passed by reference. This raises the question: can "():=" be declared > for limited types? The idea of assigning a limited component to an array component is tricky, given that there is never to be more than one copy of an object of a limited type. We can, however, take advantage of the fact that limited objects are always aliased, and implement such an array as a collection of access values to the limited objects. For this to work, however, the Value parameter of "():=" would need to be "in out" mode in order to get a non-constant reference, so I propose that we also allow "():=" to be declared as procedure "():=" ( Source : in out Abstract_Array_Type; Index_1 : in Index_Type_1; Index_2 : in Index_Type_2; ... Index_N : in Index_Type_N; Value : in out Component_Type ); I have prototyped this with a limited type. > What does A(I)'Access mean in this scheme? Abstract array components, in general, are not aliased, so that expression would not be legal. In some abstract arrays, however, the components would be aliased, so we should probably allow the user to specify the access value to be returned in such cases. > Are there interactions with Adjust, which is normally called for > assignment of nonlimited controlled types? The "()" and "():=" are regular subprograms, so Adjust would be called whenever the subprogram code requires it. > You seem to treat 'out' parameters as copy-out only. But for composite > types, 'out' means pretty much the same thing as 'in out' -- at least > *some* parts of the object are copied *in* (see RM for details). > Likewise, if the component type is an access type, you can't allow > undefined values to be created -- all access objects have to be > initialized to 'null' if they aren't initialized to something else > meaningful. This type of initialization could easily be done before calling the subprogram, so I don't see how this is a barrier for abstract arrays. > You seemed to be hoping that this new notation could underly the > definition of the *existing* array indexing semantics. That would be > elegant. However, some of the above issues mean it doesn't work -- at > least as you've defined it so far. Is there an issue other than parameter passing? > > Note: the following discussion probably has an insufficient amount of > > legalese to satisfy language lawyers. Once we've thrashed out these ideas, > > I'll be happy to work with anyone with formalizing this proposal. > > I hate to be discouraging, but my guess is that a proposal like this is > *not* going to be accepted by the ARG, even if were written up as proper > RM wording changes. That is quite possibly true. I have never done a submission to the ARG before, so I'm not really up on the procedure. The first step, however, is to have a solid idea for submission, which is why we're discussing it here. > > Similar declarations can be added to Ada.Strings.Bounded. This would permit > > the higher-level Ada string types to use the same notation as the low-level > > standard String type. > > Well, it allows that for the particular notation of array indexing, > and that would be a good thing. But it doesn't completely solve > the problem. It doesn't support slice notation (but I don't think > slices are all that important). And it doesn't support string literal > notation -- I think that *is* important -- it's really annoying that you > can't have a string literal of type uunbounded string. Similarly, it > doesn't support aggregate notation. > > If I were designing a language from scratch, I would allow user-defined > meanings for all of the above notations. But as I said, unfortunately, > I don't see this happening for Ada 0X. > > - Bob