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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Latest suggestion for 202x Date: Sat, 22 Jun 2019 20:37:29 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <728c4668-8fa0-4a57-a502-2bf476fc3940@googlegroups.com> <4908c3e3-18dc-4953-bf26-46f160d2ebfd@googlegroups.com> <9dcf22a2-2255-4089-b1f0-93e31448415e@googlegroups.com> <86h88obeu0.fsf@gaheris.avalon.lan> <39e749cd-de5c-44fa-b8ec-50d36f3bd52c@googlegroups.com> NNTP-Posting-Host: 3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:56715 Date: 2019-06-22T20:37:29+02:00 List-Id: On 2019-06-22 19:44, Keith Thompson wrote: > "Dmitry A. Kazakov" writes: >> On 2019-06-21 22:24, Keith Thompson wrote: >>> "Dmitry A. Kazakov" writes: >>>> On 2019-06-21 20:12, Keith Thompson wrote: >>>>> I *can't* replace A by a function without modifying the code that uses >>>>> it. >>>> >>>> In short if I can't do something then I don't need it, sour grapes... >>>> >>>>> I suppose containers weaken that argument >>>> >>>> No, it is no argument regardless. >>>> >>>> If Ada has problems with array abstraction, and it has, that is >>>> irrelevant to the point that this is the *same* abstraction. >>>> >>>> A language that syntactically distinguish array calls and function calls >>>> breaks the abstraction or lacks it completely. >>> >>> Is breaking that abstraction such a bad thing? >> >> Yes, because abstraction is useful. Arrays have no "physical" >> meaning. It is always an artifact of software design, some >> implementation detail, not to expose. >> >>> Why *should* array >>> indexing and function calls be treated as the same thing? >> >> Because they model the same thing, a mapping, when arrays come in >> consideration. > > I disagree. Array indexing operations refer to elements of an array > object. Function calls yield a value, and can have side effects. So can array indexing, when you get a copy of an array element, its construction may do whatever you wanted, e.g. spawn format c: /q. Anyway side effects, when relevant, break abstraction and thus cannot count for that reason. >>> What about >>> record component selection? >> >> Same. It is not mapping of ordered 1st class object to 1st class >> object in this case, but surely the syntax sugar of record member >> selection must be same for records and functions. And it is, since Ada >> 2005 started to support dotted notation: >> >> R.X -- Record member *or* call to primitive X of R or ... > > So would you prefer "R.X" to be written as "R(X)" (or perhaps "X(R)")? No, because X is not a 1st class object. The point is that in both cases the syntax is same. Same syntax for same intention. In the case of mappings the preferable syntax is A(I), regardless the implementation. In the case of hierarchical naming the preferable syntax is R.X. The syntax should help understanding the programmer's intent, rather than reflect irrelevant details like if A is an array or R is a record. >>> What operations *aren't* function calls? >> >> Ideally there should be none. All built-in syntax forms must be >> available for user-defined operations. Ada suffers greatly when it >> violates this design principle, e.g. consider "and then", "range", >> "in", "'Image" etc. > > If you want Lisp, you know where to find it. Except that Lisp has no syntax but balanced brackets. Another degenerative language of that sort is Forth. The problem is that the syntax is so dire that it cannot assist program understanding. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de