Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf@gmail.com]

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 :)

> 
> 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.

> 
> Students aren't dumb, not as programmers are! (:-))

So then I am still a student that walks wide eyed into any crap. :)


> 
> That is strange because syntax is such a minor part and because in case of
> 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 mental degradation. 


> what is wasted on so-called tool-chains.

Because complexity breeds toolchains. Or: mankind wants to be fooled so fool them.

> > 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)
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 tries to understand our code later, as I tried to indicate before.

The whole type system originated with structural equivalence. On which we can build some interesting tricks then. We can use the type structure to admit 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 procedure for processing. It is just an algebraic assurance that the calculation will 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 solving all our problems. Ada did not fully fulfil the Dod spec in this respect. Read the Steelman document. And you were complaining that you could not put any safeguards into your iso units software. And I just complain bitterly that at times that I do not see the wood for the trees when trying to interface 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 variable.
(perhaps the "functional" word is a bit overloaded here, bit it will work for 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 have.
Like naming the physical quality we deal with.
Like assuring that our formulas work out according to the International System 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  understanding. But we will have to find the correct way of describing the operational 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 functional stuff as well. in order to build a secure program. 

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. But at the moment 2 reasons for using them are confused: the perfectly legitimate ways (converting from one derived type to another) are mixed up with non-portable ways of use (fixing up the storage specification of a variable).

By the way I did look at your scanner and parser stuff, it is impressive. but 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.
 
> 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.

> 
> 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 compatible, 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.