[M3devel] null type?

[Rodney M. Bates]

On 04/25/2013 01:16 PM, Hendrik Boom wrote:
> On Thu, Apr 25, 2013 at 12:36:11PM -0500, Rodney M. Bates wrote:
>>
>>
>> On 04/25/2013 08:20 AM, Hendrik Boom wrote:
>>>
>>> Could the problem be just with NULL-typed variables where the NULL type
>>> is not mentioned explicitly in the declaration?
>>>
>>> These might merit a warning.
>>>
>>> By the way, what is done with
>>>     VAR x := 1;
>>>
>>
>> No, the type of 1 is INTEGER, and the type of 1L is LONGINT.
>>
>> But you could make something like that happen with
>> CONST OneOnly : [1..1] = 1;
>> VAR x := OneOnly;
>
> Is there some reason why 1 is by default given the maximal type
> containing 1, whereas NIL is given the minimal type containing NIL?

Hmm, that's a good question.  I'm just speculating here, but I can think
of a couple of things.

There is just one NULL in the language, and it is builtin and the same minimum for
all reference types, traced and untraced.  In contrast, every integer (and enumeration)
literal value would have a different minimal type, and these are not builtin types.
They would all be implicitly defined by their literal values, creating a lot of stuff
floating around the compiler that wouldn't do much, since they would all be statically
assignable, wherever referenced.

As for making NIL have maximal type, there isn't one in the language now.
It would have to include both the traced and untraced hierarchies.  Then
somebody could declare a variable of that type, giving a need to be able
to distinguish the non-NIL values at runtime as traced or not.  That would
either call for some kind of fat pointer (which there would not be enough bits,
in case of UNTRACED REF CHAR) or having every referent have a heap allocator
word, which would then undermine using untraced refs for unsafe low-level
coding like pointers to things not in any heap.

I suppose there could have been separate traced and untraced NILs, but that
probably would have gotten major complaints and been much harder to justify than
say, 1 vs. 1L, which are necessary for resolution of arithmetic operators.

>
> -- hendrik
>
>>
>>> Is x implicitly of type 1:1?
>>>
>>> -- hendrik
>>>
>>
>