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

["G.B." <bauhaus@futureapps.invalid>]

On 22.05.15 14:57, J-P. Rosen wrote:
> Le 22/05/2015 13:29, kalvin.news@gmail.com a écrit :
>> Even C could be made more robust, if simple type checking is
>> performed at compile time. For example,
>>
>> typedef int apples;
>>
>> typedef int oranges;
>>
>> apples a = 5; oranges o = a;
>>
>> should generate type check error as the types are definitely
>> different types. Also, assigning enums to ints and ints to enums
>> should be considered illegal.
>>
> I don't agree. C is a low level language, and good at that. Its types
> are those of the  machine: bytes and addresses, the rest is a (small
> quantity of) syntactic sugar.

Not sure this description of what C is in the eye of
an Adaist will win an argument; first, it is not exactly
right. (If myths say that int was influenced by PDP hardware
40 years ago, this doesn't seem to reflect C compilers in use
today, or yesterday.)

While the C type int is defined by the C standard,
one needs to consult the implementation's docs to
learn the specifics of int for a given implementation.

Same for Ada!

There would have been an opportunity to point out
the extended possibilities that Ada offers for expressing
expectations on types. But

   LS : String(1 .. 100_000);

is not defined by the Ada LRM as an unequivocally valid
piece of Ada source text, since Positive, and therefore
String, are only defined to much the same extent that C's
int is defined by C.

OTOH, what happens if I'd write  *(p + 100000-1) in a
C program?

Then, the C standard is explicit about what a byte is.
A C int cannot be expressed as bytes of C. Nor is the
behavior of int objects in borderline situations devoid
of context in the standard.

There also is no forced relationship of machine words and
int for a C implementation: 32 bits on a 64 bit architecture
is a valid choice. But that _is_ a source of trouble!

The issues are elsewhere, and it seems like a good opportunity
to show that, with Ada, there is actually more in the hands
of a programmer to address issues that cannot be addressed in
portable C source text; e.g., reactions to overflow.

C is in many ways as strongly typed as Ada, just not everywhere,
and that's worth pointing out, specifically addressing the typical
problems that C programs tend to run into.

C, in addition, has neither subtype constraints, nor derived types,
nor language-defined representation expressions etc.. But is _does_
have named type equivalence:

typedef struct apples { int amount; } Apples;
typedef struct oranges { int amount; } Oranges;

Oranges f() {
   Apples a = { .amount = 5 };

   return a;
}

The definition triggers a compile time error: it is nor permissible
to return a structurally equivalent struct apples when instead
a struct oranges was named as the return type in f's profile.

If the error is corrected, then the code produced, even when
just modest optimization is requested, will be the same as if
only a scalar type had been used.

That is not to say that I'd expect C programmers to avoid bare int.
Nor that the "solution" looks attractive. But it does confirm
that to say that C is a weakly typed _language_ will be ignored
by any C programmer in charge. Doing so falls short of being
an argument.