<div dir="ltr">There's another aspect of the NULL type which should be considered here. NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor of all reference types, NULL is the ultimate descendant of all reference types. As a result any variable of a reference type can be assigned NIL. Because of its unusual position, NIL is the only member of type NULL, since no other value makes sense (which is why it's sometimes called the "absurd" type).</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 22, 2013 at 10:38 AM, Jay K <span dir="ltr"><<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">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.<br>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.<br>
<br> <br> - Jay<br> <br><div><div></div>> Date: Sun, 21 Apr 2013 21:03:02 -0500<br>> From: <a href="mailto:rodney_bates@lcwb.coop" target="_blank">rodney_bates@lcwb.coop</a><br>> To: <a href="mailto:m3devel@elegosoft.com" target="_blank">m3devel@elegosoft.com</a><br>
> Subject: Re: [M3devel] null type?<div><div class="h5"><br>> <br>> <br>> <br>> On 04/21/2013 03:55 PM, Jay K wrote:<br>> > What is the meaning of this:<br>> ><br>> > cm3/elego/graphicutils/src/RsrcFilter<br>
> ><br>> > init(p1, p2, p3, p4, p5, p6 := NIL) : T;<br>> > (* Initializes the resource search path. *)<br>> ><br>> ><br>> > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T =<br>
> ><br>> <br>> Modula-3 says:<br>> <br>> 2.2.7: 'The following reference types are predeclared:<br>> ...<br>> NULL Contains only NIL'<br>> <br>> And:<br>> <br>> 2.2.8: 'A formal parameter declaration has the form<br>
> Mode Name: Type := Default<br>> ...<br>> If Type is omitted, it is taken to be the type of Default.'<br>> <br>> And:<br>> <br>> 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.'<br>
> <br>> So all the pi's have type NULL, and only NIL can be passed to them<br>> as actuals. That's what the language says. It looks like the code<br>> in Init thinks it can get non-NIL reference values, but an attempt to pass<br>
> one in a call should fail a runtime assignability check, since it<br>> won't be a member of NULL.<br>> <br>> When Init passes one of these to Convert (Yes, I peeked into<br>> RsrcFilter.m3), it is assignable, with no runtime check. Convert<br>
> thinks it has a REFANY, and other calls to Convert could indeed<br>> give it something non-NIL, but not from the calls in Init.<br>> <br>> Of course, unsafe code could probably LOOPHOLE (remember, any word<br>
> can be verbed) something non-NIL to NULL and pass it to init/Init.<br>> If the compiler did the most obvious thing, this might do what was<br>> apparently intended.<br>> <br>> But then again, a compiler would be fully compliant with the language<br>
> and perfectly within its rights to optimize out such a parameter,<br>> not actually pass it at runtime at all, and just insert constant NIL<br>> wherever the formal was referenced in the body of Init, thus undermining<br>
> the above intent.<br>> <br>> Which makes for a good example of how unsafe code (almost?) always<br>> depends on assumptions about what a compiler will do.<br>> <br>> ><br>> > What are the types of p1, p2, etc.?<br>
> ><br>> ><br>> > - Jay<br>> <br></div></div></div> </div></div>
</blockquote></div><br></div>