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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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