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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Build language with weak typing, then add scaffolding later to strengthen it? Date: Thu, 4 Jun 2015 19:23:43 +0200 Organization: cbb software GmbH Message-ID: References: <46b2dce1-2a1c-455d-b041-3a9d217e2c3f@googlegroups.com> <3277d769-6503-4c7f-885f-3a730762b620@googlegroups.com> <9fa68fb7-89f0-42b3-8f25-20e70cb34d63@googlegroups.com> <87egm3u662.fsf@adaheads.sparre-andersen.dk> <20c56bea-2803-4aa9-a626-2d25e480df20@googlegroups.com> <1dmgofrqo3xn5$.1p4241xr4z92p.dlg@40tude.net> <1066il1b5nk21.ioykgza5bnsw.dlg@40tude.net> <40b1c612-5430-4ea6-9291-197047b2423d@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: evoS9sCOdnHjo0GRLLMU1Q.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: news.eternal-september.org comp.lang.ada:26181 Date: 2015-06-04T19:23:43+02:00 List-Id: On Thu, 4 Jun 2015 08:31:14 -0700 (PDT), jan.de.kruyf@gmail.com wrote: > On Sunday, May 31, 2015 at 10:52:03 AM UTC+2, Dmitry A. Kazakov wrote: > >> Yes, repeating the old saying - if C is a solution what was the problem? > > Apparently writing a Linux Kernel?? (could not resist that one :) Oh, that problem! They should have let it be... (:-)) >> As if social "science" could give answers. > > I will tell my wife. > To me they stumble and fall just like we do, but perhaps together we will > gain a bit more knowledge. Yeah, so far answers social "science" ever gave, ultimately led to brainwashing closely followed by concentration camps... >> what is wasted on so-called tool-chains. > > Because complexity breeds toolchains. And the complexity is bred by mental laziness. >>> But types hardly belong there. >> >> They do. > > This is the main reason why I wanted to answer this post: > I tried to do some thinking while driving over the last few days. And I > got the hint for what follows out of one of your old posts (I think) about > having units of measurement as a type, etc. > > I came to the conclusion that perhaps 2 things got confused over the years > in the typing scheme: > 1. structural equivalence. (i.e. a storage specification) ? Structural equivalence is an attempt to infer the behavior of an object from its internal structure, or, more generally, from the way of its construction. A mathematician would not even bother with that idea because it clearly incomputable for anything beyond trivial. An engineer would tell you that it is rubbish because it does not abstract the problem space. How would you put the internal structure of the planet Mars to know if it were a planet different from Earth? > 2. name equivalence. (as long as the type names are equivalent it will work) Nominal equivalence is when things are known to be equivalent a priory, usually from the problem space, or per design. > These days we go for name equivalence and make new types or rename types > to our hearts content. And so confuse things horribly for the person that > tries to understand our code later, as I tried to indicate before. Sure, because he or she must share that a priory knowledge with you. If you name something Pi, the reader must know trigonometry already. What puzzles me, is why do you think that writing instead an infinite continued fraction would be better to communicate Pi? Pi is incomputable for humans as well. If all men were as silly as people believing in structural types equivalence we would still be living in stone age... > The whole type system originated with structural equivalence. Type systems appeared in mathematics after the disaster of naive set theories. http://en.wikipedia.org/wiki/Type_theory > So my solution would be to have, besides the "structural type" attribute > to a variable, also a "what it is" or a "functional type" attribute to a > variable. There is no "is". Neither in real world or in programming. Equivalence in mathematics is just a binary relation of certain properties. http://en.wikipedia.org/wiki/Equivalence_relation > Like assuring that our formulas work out according to the International > System of Units. And we dont multiply apples with apples, etc. Oh, but you do. Add diagonal of your monitor to the width of the button "A" on the Logitech keyboard. The measurement unit is exactly same: [m]. > And to put that into the symbol table parse tree of a compiler is trivial, > it is just a copy more or less of the existing type tree. At least to my > understanding. But we will have to find the correct way of describing the > operational interaction limitations of the different functional types we > use. You cannot handle measurement units on the syntax level. It is useless for most practical reasons. As an example consider writing a calculator dealing with dimensioned values. > In using the language we will now have a choice: > just use structural equivalence (what you blame me of :) or use the > functional stuff as well. in order to build a secure program. See the example above. Structural equivalence is fundamentally unsafe. It is a well known fact any C programmer learns on his hide - the "structure" of int is same even if one int is a file descriptor and another is the Avogadro constant... Why don't you look into the standard output descriptor when comparing 1 to 1? > In this way I would think that we will do away with a lot of 'unchecked > conversions' which to my understanding were designed to fit a character > onto an integer and the like. We do it away by making conversions checked, but automated. What Ada really lacks is subtyping beyond merely constrained instances. >> This is solvable without Unchecked_Conversion, e.g. by ad-hoc supertypes, >> if Ada had them. > > Yes, I think what I described above would cater for that. It would not, because the structures are evidently different. Here lies the fundamental flaw of the idea. The difference and the similarity do not come from the structure, they come from the problem space. The structures of Character 'A' and Wide_Character 'A' are different. Yet the problem space entity is exactly same. See? A software architect would say that the structure is an implementation detail, deserving no attention, never to be trusted at the client side. Deducing anything about the program logic from structures is a *bug* on the client's part. > The Ada design basics are from 1977 - 1983. And today it is still very > compatible, so what do we expect. It is fantastic that it has stood up so > long. It is because nothing interesting happened since 1995. We are living through the Dark Ages of computing... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de