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!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.ada Subject: Re: Latest suggestion for 202x Date: Sat, 22 Jun 2019 10:44:00 -0700 Organization: None to speak of 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="2f013ee26bcebe806da06fd05ace0a1c"; logging-data="15818"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19b3O2SNumSxn6YSmv/O4OC" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:GZAB7nfcrvOyo5gKateYQcEUQVw= sha1:uUnDH3qsSu5/XQbVpfshxLHnf1A= Xref: reader01.eternal-september.org comp.lang.ada:56713 Date: 2019-06-22T10:44:00-07:00 List-Id: "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. >> 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)")? >> 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. >> But please don't overestimate how much I care about this. In my >> opinion, it's really not that big a deal. I personally like brackets >> better than parentheses for array indexing, but I have no particular >> problem with Ada's choice. > > In my view it is a language design problem. I have nothing against > adding further types of brackets: {}, <>, || but they all must be > user-defined. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */