[M3devel] null type?

[Darko]

You're wrongly suggesting I object to single valued to single value types.  Read what I wrote, there's no such implication or logic since I'm discussing a special case. What I object to is the confusion created by allowing the use of the NULL typed variables in particular, evidenced by the error. It's not any more difficult to outlaw variables of NULL anymore than it is to outlaw the use of empty types.

The type system and its mathematical simplicity is not affected by what the compiler deems acceptable, you still have the NULL type defined as before. The issue is acceptable variable declarations.

Anyway, it's an idea. If you don't like it ignore it. If someone threatens to implement it, take it up with them, I'm sure they'll enjoy the discussion.



On Apr 24, 2013, at 8:45 PM, mika at async.caltech.edu wrote:

> What is lost is some of the mathematical simplicity of the type system.
> 
> A type is just a set of values.
> 
> There is nothing odd about a type that can contain a single value.
> 
> By your logic, we should outlaw declarations of variables of type [1..1]
> as well.  Or variables of type { OK } (one-value enumerations).
> 
> The upshot would be to require special-case code in programs that
> *generate* Modula-3 code to check for types of a single value
> and avoid those through some gyrations involving value substitutions.
> 
> I can see how that could be a big hassle in some cases---it would require
> the aforementioned code generators to be able to perform value substitutions
> and possibly dead-code elimination.
> 
>     Mika
> 
> 
> 
> 
> Darko writes:
>> Probably not a good idea to make it illegal for backwards compatibility =
>> if you really think it's going to break things, so perhaps issue a =
>> warning instead. But besides providing a type for NIL it doesn't serve =
>> much purpose and I can't see anything being lost by outlawing it, =
>> eliminating the confusion with REFANY might be gained.
>> 
>> Just because it's a valid bit of code doesn't mean it's not a bug. =
>> Looking at the code you can reasonably assume the author thought NIL was =
>> of type REFANY. It's a useless declaration unless it's trying to make =
>> some sort of point by being useless. It's a declaration to pass in one =
>> possible value which it's already assigned and which you can't change.=20=
>> 
>> 
>> 
>> On Apr 24, 2013, at 7:53 PM, mika at async.caltech.edu wrote:
>> 
>>> Darko writes:
>>>> =20
>>>> --Apple-Mail-2--196294281
>>>> Content-Transfer-Encoding: quoted-printable
>>>> Content-Type: text/plain;
>>>> 	charset=3Dus-ascii
>>>> =20
>>>> I think the correct approach is to treat a variable declaration with =
>> a =3D
>>>> type NULL as an error. The correspondence to C would be void, but =
>> just =3D
>>>> void, not void*.  What is the representation of the declaration "void =
>> =3D
>>>> x"? I'm guessing C doesn't allow that.
>>> =20
>>> It's not an error since there is precisely one legal value for such a =
>> variable,
>>> namely, NIL.  That value can be inferred from the type without =
>> inspecting the
>>> variable.
>>> =20
>>> If you make it illegal to declare variables of type NULL you may have =
>> to go
>>> back and change various code generators that depend on it.
>>> =20
>>> There are types that are truly empty in Modula-3, and it is illegal to
>>> declare variables of those types (but not illegal to declare those =
>> types
>>> or to use them to construct other types), e.g.,
>>> =20
>>> CONST
>>> A =3D 3;
>>> B =3D 1;
>>> =20
>>> TYPE
>>> T =3D [A..B];
>>> =20
>>> VAR
>>> t : T; (* static error *)
>>> =20
>>> TYPE
>>> A =3D ARRAY T OF X; (* not an error *)
>>> =20
>>> etc.