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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.110.6 with SMTP id t6mr52489451yhg.57.1433431874932; Thu, 04 Jun 2015 08:31:14 -0700 (PDT) X-Received: by 10.140.42.195 with SMTP id c61mr11917qga.11.1433431874906; Thu, 04 Jun 2015 08:31:14 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!z60no266814qgd.1!news-out.google.com!k20ni45169qgd.0!nntp.google.com!z60no266808qgd.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 4 Jun 2015 08:31:14 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.210.0.212; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.210.0.212 References: <59a4ee45-23fb-4b0e-905c-cc16ce46b5f6@googlegroups.com> <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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <40b1c612-5430-4ea6-9291-197047b2423d@googlegroups.com> Subject: Re: Build language with weak typing, then add scaffolding later to strengthen it? From: jan.de.kruyf@gmail.com Injection-Date: Thu, 04 Jun 2015 15:31:14 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 7621 X-Received-Body-CRC: 3147505593 Xref: news.eternal-september.org comp.lang.ada:26180 Date: 2015-06-04T08:31:14-07:00 List-Id: On Sunday, May 31, 2015 at 10:52:03 AM UTC+2, Dmitry A. Kazakov wrote: >=20 > Yes, repeating the old saying - if C is a solution what was the problem? Apparently writing a Linux Kernel?? (could not resist that one :) >=20 > As if social "science" could give answers. I will tell my wife.=20 To me they stumble and fall just like we do, but perhaps together we will g= ain a bit more knowledge. >=20 > Students aren't dumb, not as programmers are! (:-)) So then I am still a student that walks wide eyed into any crap. :) >=20 > That is strange because syntax is such a minor part and because in case o= f > Ada it is very difficult (at least to me) to understand its BNF, because > they tried to push precedence (and some other) rules into it. That is one of the issues I tried to argue. > Nothing lost, > nothing gained. Some bad features added, but we are free not to use them. I try just that and it has saved me from some more advanced stages of menta= l degradation.=20 > what is wasted on so-called tool-chains. Because complexity breeds toolchains. Or: mankind wants to be fooled so foo= l them. > > But types hardly belong there. >=20 > They do.=20 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 hav= ing 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) 2. name equivalence. (as long as the type names are equivalent it will work= ) 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 tri= es to understand our code later, as I tried to indicate before. The whole type system originated with structural equivalence. On which we c= an build some interesting tricks then. We can use the type structure to adm= it or not admit a variable to an algebraic algorithm, and if this record is= equivalent to, or a subset of that record we can feed them to some procedu= re for processing. It is just an algebraic assurance that the calculation w= ill be successful. But the type system, as it has evolved over the years, has been overloaded = with the name equivalence idea. And this to me is important in this discussion: it has not succeeded in sol= ving all our problems. Ada did not fully fulfil the Dod spec in this respec= t. Read the Steelman document. And you were complaining that you could not = put any safeguards into your iso units software. And I just complain bitter= ly that at times that I do not see the wood for the trees when trying to in= terface Ada to the kernel. 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 vari= able. (perhaps the "functional" word is a bit overloaded here, bit it will work f= or the purpose of the discussion) The structural type is fine for the algebra and the storage. The functional type would serve to help us with all the other issues we hav= e. Like naming the physical quality we deal with. Like assuring that our formulas work out according to the International Sys= tem of Units. And we dont multiply apples with apples, etc. You name it, there is a wide field here. 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 u= nderstanding. But we will have to find the correct way of describing the op= erational interaction limitations of the different functional types we use. In using the language we will now have a choice: just use structural equivalence (what you blame me of :) or use the functio= nal stuff as well. in order to build a secure program.=20 In this way I would think that we will do away with a lot of 'unchecked con= versions' which to my understanding were designed to fit a character onto a= n integer and the like. But at the moment 2 reasons for using them are conf= used: the perfectly legitimate ways (converting from one derived type to an= other) are mixed up with non-portable ways of use (fixing up the storage sp= ecification of a variable). By the way I did look at your scanner and parser stuff, it is impressive. b= ut I thought Sparre might perhaps be better served when he understands the = very basics first, and perhaps it is enough for what he wants. Only he can = judge. =20 > 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. >=20 > Really? I never saw such bosses. Usually a boss does not even know that > there are types. Ah, they made the salesman the boss, shame! > They are there, whether you wanted or not. Yes, but not dreaming is deadly. So even if Ada might not see here way open= to solve all this, perhaps her children might. The Ada design basics are from 1977 - 1983. And today it is still very comp= atible, so what do we expect. It is fantastic that it has stood up so long= . Read this if you want to get some perspective on the speed of development: http://heerdebeer.org/ALGOL/The_History_of_ALGOL.pdf cheers, j.