[M3devel] null type?

[Darko]

A type denotes a set of allowable values. The NULL type is the set of values that only contains the value NIL. You need it because every expression has a static type so you need one for the expression "NIL".

This to me looks like a bug. I have something similar in my code, declared CONST Nil: REFANY = Nil; so I can write PROCEDURE(a, b, c := Nil). Maybe that's what they had in mind but thinking the type of NIL was REFANY.


On Apr 22, 2013, at 10:38 AM, Jay K wrote:

> Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it.
> This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared.
>  
>  
>   - Jay
>  
> > Date: Sun, 21 Apr 2013 21:03:02 -0500
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] null type?
> > 
> > 
> > 
> > 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
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/7302e3f8/attachment-0002.html>