[M3devel] null type?

[Darko]

That should read CONST Nil: REFANY = NIL;  and no, you can't treat it like ADDRESS, it's equivalent to the enumeration TYPE NULL = {NIL};


On Apr 22, 2013, at 10:59 AM, Darko wrote:

> 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/015164c4/attachment-0002.html>