[M3devel] null type?

[Rodney M. Bates]

On 04/21/2013 03:55 PM, Jay K wrote:
> What is the meaning of this:
>
> cm3/elego/graphicutils/src/RsrcFilter
>
>      init(p1, p2, p3, p4, p5, p6 := NIL) : T;
>      (* Initializes the resource search path. *)
>
>
> PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T =
>

Modula-3 says:

2.2.7: 'The following reference types are predeclared:
         ...
         NULL   Contains only NIL'

And:

2.2.8: 'A formal parameter declaration has the form
           Mode Name: Type := Default
         ...
         If Type is omitted, it is taken to be the type of Default.'

And:

2.6.6: 'The literal "NIL" denotes the value NIL.  Its type is NULL.'

So all the pi's have type NULL, and only NIL can be passed to them
as actuals.   That's what the language says.  It looks like the code
in Init thinks it can get non-NIL reference values, but an attempt to pass
one in a call should fail a runtime assignability check, since it
won't be a member of NULL.

When Init passes one of these to Convert (Yes, I peeked into
RsrcFilter.m3), it is assignable, with no runtime check.  Convert
thinks it has a REFANY, and other calls to Convert could indeed
give it something non-NIL, but not from the calls in Init.

Of course, unsafe code could probably LOOPHOLE (remember, any word
can be verbed) something non-NIL to NULL and pass it to init/Init.
If the compiler did the most obvious thing, this might do what was
apparently intended.

But then again, a compiler would be fully compliant with the language
and perfectly within its rights to optimize out such a parameter,
not actually pass it at runtime at all, and just insert constant NIL
wherever the formal was referenced in the body of Init, thus undermining
the above intent.

Which makes for a good example of how unsafe code (almost?) always
depends on assumptions about what a compiler will do.

>
> What are the types of p1, p2, etc.?
>
>
>   - Jay