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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,1449b098788729b8 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,CP1252 Path: g2news2.google.com!postnews.google.com!s15g2000yqs.googlegroups.com!not-for-mail From: =?ISO-8859-1?Q?Yannick_Duch=EAne_Hibou57?= Newsgroups: comp.lang.ada Subject: Re: prefix of dereference must be a name? Date: Mon, 3 Aug 2009 20:37:10 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 77.198.58.140 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1249357030 11646 127.0.0.1 (4 Aug 2009 03:37:10 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 4 Aug 2009 03:37:10 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s15g2000yqs.googlegroups.com; posting-host=77.198.58.140; posting-account=vrfdLAoAAAAauX_3XwyXEwXCWN3A1l8D User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; fr),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:7556 Date: 2009-08-03T20:37:10-07:00 List-Id: On 4 ao=FBt, 03:45, Adam Beneschan wrote: > You should look over AI05-0003. =A0I think there's a fair amount of > sympathy for your position; I agree that it would have been better to > have less distinction between "names" and "expressions", but the > problem just never made it high enough on the priority list. =A0It's > simple to say "You should be able to use an expression with an > operator wherever you could use the equivalent function call", but not > at all simple to change the language rules consistently and make sure > the change doesn't cause any other problems, and probably not at all > simple for all the compiler vendors to make the necessary changes. > > AI05-0003 will fix one related issue, I think, to allow qualified > expressions [Type'(Function_Call(...))] to be used where they > currently can't. =A0I felt this one was important, because using > qualified expressions is sometimes the only reasonable way to > eliminate ambiguities in overloading cases---or at least the only non- > clunky way. =A0In your examples, you *could* always replace (A+B) with > "+"(A,B) to get around the problem, so it's not as important to have > this fixed, and a decision has to be made about whether it's worth the > effort. =A0But I agree that it would have been nice if the language had > been designed "right" at the beginning. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0-- Adam Although I agree about your arguments for a more intuitive and less badly-restrictive syntax, I still try to understand why it is like it is, and I suppose there were some good reasons, like avoiding too much deep expressions. Perhaps it was in the hope it would help readability and maintenance, forcing the decomposition of some expressions in intermediate steps. While for the simple example you gave, =93 Type'(Function_Call(...)) =94, this hypothetical reason would surely not apply.