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,UTF8 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 19:29:50 +0200 Organization: cbb software GmbH Message-ID: <137h8159vih64$.16id4nb6e54mp$.dlg@40tude.net> References: <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> <4e60b1dd$0$6635$9b4e6d93@newsspool2.arcor-online.net> <1imztu5j0f0pv$.1oy8qpcm0cpvv$.dlg@40tude.net> <4e60ff91$0$6550$9b4e6d93@newsspool4.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 8fJJxezLlBSyWLh3EB2R4g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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:20830 Date: 2011-09-02T19:29:50+02:00 List-Id: On Fri, 02 Sep 2011 18:08:49 +0200, Georg Bauhaus wrote: > On 02.09.11 14:40, Dmitry A. Kazakov wrote: > >> empirical, adj >> ... >> 2. based on practical experience rather than scientific proof >> 3. (of a proposition) subject, at least theoretically, to verification >> 4. (Medicine) of or relating to medical quackery > > The non-scientific meanings are not applicable to how this study > of understanding programming languages was conducted. Obviously this study has little to do with science. I have no idea how such stuff passes peer reviews... >> Integral is not an addition. > > Other operations aren't addition either, yet some are considered > more worthy of inclusion as infix symbols than others. I just think > that language design should reflect computers' + more than + from > school. No, it should not. > The point is: the language does not draw attention to + > as a source of errors induced by school think. No, the semantics of + is defined pretty clear and it is consistent with the school mathematics. + does not mean the group operation of Z. Computers do not handle Z. + means "addition". >> Addition is used by (Lebesque) integration, >> but defined on a set measure. It has the standard notation +, e.g. >> >> µ(A U B) = µ(A) + µ(B) if A and B are disjoint, etc > > µ is equally abhorred, as is ∪. Maybe ∪ should not be used > in languages other than SETL because ∪ implies properties > of data structures that typical implementations of a Set will > not have? How so? Bot µ and U represent absolutely no problem, so long sets are finite, which is 99.9% of all cases modeled using computer programs. >>> Is there anything about + that makes its meaning more special >>> than that of ∫? >> >> Yes. Integral is a value according to some measure. + is an operation of a >> group. (I hope you won't argue that * is addition because it could be >> defined in terms of +) > > This is a mathematical perspective on mathematical properties only, > not simply on program text. In a computer program, you write > > + (1, 2) > ∫ (f'access, a, b) > > How is ∫ special? Integration is special, because incomputable. The approximations of, done by computers, are too implementation-dependent to be abstracted in the way used in mathematics. On the contrary, the implementations of model numbers are much more simpler and closer to their mathematical counterparts. No less important is that model numbers indeed form the structures (rings etc) of same nature (properties) as the corresponding mathematical structures. > At the very least, an operator such as + should not be predefined to > the maximum extent possible. The operator should convey that it > will not perform high school addition but computer addition. No. E.g. + of mod 2**16 means exactly same, the mathematical + does. >> Nope. Mathematically there is no difference between an array and a valued >> pure subprogram. Both are run-time implementations of a mapping. Why there >> should be different notation for them? > > The study by McIver & Conway explains a number of reasons, > all having to do with programmers. I don't buy such "studies" on methodological grounds. Whatever explanations they give, that is an urban myth. You, me and anybody else here is capable to produce tons of such stuff. Meanwhile the hard facts are impossible to gather in any statistically relevant form, because such experiments would cost billions of bucks and require very sophisticated methods to develop. For the rest see Ernest Rutherford about science and stamp collecting. We could only be happy that guys "studying" programming languages have not a ounce of influence on the governments, the "climatologists" have. Lysenko is dead, but his cause lives. >> 1. Overflow is not an error it is a valid, mandated behavior. > > I still don't want most programs to overflow. Then they should not let overflow happen. >>> The human brain needs to learn, and then to rummage through a mountain >>> of, information about the expression and its meaning in order to see, >>> for example, from where this strange and irregularly occurring difference >>> in executing x + y should stem, for seemingly the same x and y, by the >>> looks of it. (Timing dependent shared variable update through y, say.) >> >> And a consistent use of Whatever.Package.Name.Add instead of + is supposed >> to ease the process of learning? > > Not + alone, but a suitably defined language allowing programmers > to express their expectations, and be given clear and simple indications > of its effects. I am not against manifested contracts, as you probably know. But the idea that syntax should convey contract is all wrong. It won't work, it never worked. The contracts belong to the types. > What can aid understanding? The language should convey the idea at different levels of abstraction. It is like a good movie or a good book. Anybody can find there something at his level of depth or shallowness. Understanding works by recognition of common concepts and patterns with an ability to go deeper, gradually down to the bottom, but only when felt needed. This makes a good language. C is bad because it does what you wanted, it requires full, persistent, concentrated attention to each tinny piece of the code written or read. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de