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,826cd690cb6a7585 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Overloading parentheses and type expectations Date: Fri, 2 Sep 2011 09:54:55 +0200 Organization: cbb software GmbH Message-ID: References: <904e717e-da4c-46c9-bbc2-4bae8368d459@l4g2000vbv.googlegroups.com> <4e5d139f$0$6575$9b4e6d93@newsspool3.arcor-online.net> <3756bc0c-d938-4b45-baa1-b80e59d58055@a10g2000prn.googlegroups.com> <1a879va9fjuwo.1r1b6vbp45lx5.dlg@40tude.net> <4e5dd1c1$0$6638$9b4e6d93@newsspool2.arcor-online.net> <12nar9pjxb1pg.14709ohrczh9p$.dlg@40tude.net> <4e5e54ec$0$7623$9b4e6d93@newsspool1.arcor-online.net> <4e5e6010$0$7611$9b4e6d93@newsspool1.arcor-online.net> <4e5e6199$0$7611$9b4e6d93@newsspool1.arcor-online.net> <1ctkvx8kzbydt.voo17pqegid1$.dlg@40tude.net> <4e5e9c5d$0$7624$9b4e6d93@newsspool1.arcor-online.net> <85cspp5yd1u1$.krrkdtgmlj4j.dlg@40tude.net> <4e5f5583$0$6623$9b4e6d93@newsspool2.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news1.google.com comp.lang.ada:20822 Date: 2011-09-02T09:54:55+02:00 List-Id: On Thu, 01 Sep 2011 11:50:59 +0200, Georg Bauhaus wrote: > On 01.09.11 09:46, Dmitry A. Kazakov wrote: >> On Wed, 31 Aug 2011 22:41:01 +0200, Georg Bauhaus wrote: >> >>> Still SPARK, and in some more cases Ada, do require that we write >>> T'() anyway: to resolve another ambiguity (of ()). >> >> Fix SPARK! > > Not. At least if this makes me an inference machine for "()"; > a "disambiguator"; or a de-obfuscator of clever abbreviations, > omitted names, and long lists of positional parameters. > > What is the use of clever detection? 1. Common sense. 2. Limitations put on human brain. We can memorize only a few concepts and whatever we see or do has to be broken into these basic concepts, e.g. "additive". > To show that in > > f(1), > > given function f, the 1 can only be a an array of length 1? It cannot, because f is not a prefix operation. Anyway, ANY written language needs understanding (translation into the domain). Are you arguing for a hieroglyphic language where each possible program has a corresponding alphabet symbol? >> There is no usable languages without overloading. Since you mentioned () >> [meaning aggregates], think about them used for ordering: >> >> (x) >> >> returns what? For each type and subtype of x there is some "()". They all >> are overloaded. Do you wish to annotate each of them? > > > There is evidence that overloading the meaning of () is not > working with normal people, e.g. McIver & Conway (1996). Rubbish, mathematical notation is taught in school. It is easy to show that all known alternatives (e.g. Polish expressions) are incomprehensive for normal people. > Why would a designer want entirely different things in a language > and then use the same notation for all of them? See above. This is the way human brain works. And the things are not entirely different, they are instances of some class. The language captures this by using "+" everywhere "addition" is meant. > First, infix expressions are a (dis)service offered to programmers > whose wish is less to program a computer, I'd like to see a hard proof that, for instance, Forth is more productive, safer, easier to understand, etc than Ada. > I cannot say it better than, > http://c2.com/cgi/wiki?OperatorPrecedenceConsideredHarmful The text is about levels of precedence. They were probably unaware of the simple fact, that ambiguity should not be resolved using precedence as in C. For proper language design see Ada, where ambiguity stay unresolved: X and Y or Z -- Ambiguous => erroneous > In 3 + 5 (or x + y), which object does "+" manipulate? Three objects: 1. The left argument 2. The right argument 3. The result All this has nothing to do with the notation. Whether "+" is used as an infix operation or as a function call, its semantics remains exactly the same. > Third, an occurrence of qualifying T'(...) frequently creates an object. I doubt it. Anyway, semantically there should be no difference. > "Qualifying" in a different way, though much like Integer'(1 + 2) is not > without uses: > > for P in Pins range 1 .. 3 loop > > rather than > > for P in 1 .. 3 loop > > carries more information, and will add information that is sometimes > necessary for the Ada compiler to know the literals and their types. > I don't find them necessarily silly and redundant. Information unnecessary to understanding the program is noise. When also required by the compiler, it constitutes a language deficiency. (There could be some exceptions from this rule) >> Since the dictionary of any language is far less than the number of >> entities an average program in that language describes, you simply cannot >> avoid some kinds overloading. > > Sometimes overriding works better than overloading. Both are cases of polymorphism. It is OK to inherit "+" from some common base. Unfortunately Ada cannot this due to lack of MD, MI and interface inheritance. But that would change nothing at the syntax level: 1+2 would remain 1+2 (as it should be). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de