[M3devel] null type?

[mika at async.caltech.edu]

I'm pretty sure the original code is buggy.

The best type to represent NULL in C(++) I think would be no type at all,
that is, strip the parameter and replace it with a constant (void *)0.

Of course you might have some mismatches if you do that.  Second closest
would be some singleton type.

But I would add that there has been a Modula-3 compiler that treats a
declaration of 

a := NIL 

as 

a : REFANY := NIL 

but that was a buggy compiler.  I had made the mistake in my own code a
few times and when I upgraded my compiler once, it stopped working (as
it should have).

     Mika

Darko Volaric writes:
>--047d7bd76f785e671604dafb6f57
>Content-Type: text/plain; charset=ISO-8859-1
>
>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).
>
>
>On Mon, Apr 22, 2013 at 10:38 AM, Jay K <jay.krell at cornell.edu> 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
>> >
>>
>
>--047d7bd76f785e671604dafb6f57
>Content-Type: text/html; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
><div dir=3D"ltr">There's another aspect of the NULL type which should b=
>e considered here. NULL is the complement of REFANY. Just as REFANY is the =
>ultimate ancestor of all reference types, NULL is the ultimate=A0descendant=
> of all=A0reference=A0types. As a result any variable of a reference type c=
>an be assigned NIL.=A0Because=A0of its unusual position, NIL is the only me=
>mber of type NULL, since no other value makes sense (which is why it's =
>sometimes called the "absurd" type).</div>
><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Apr 2=
>2, 2013 at 10:38 AM, Jay K <span dir=3D"ltr"><<a href=3D"mailto:jay.krel=
>l at cornell.edu" target=3D"_blank">jay.krell at cornell.edu</a>></span> wrote=
>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
>ft:1px #ccc solid;padding-left:1ex">
>
>
>
><div><div dir=3D"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 ca=
>n just treat this as=A0"ADDRESS" presumably. Checks that it is NI=
>L, that is the frontend's job. The error is just that I check that I kn=
>ow about every type. Some types are "predeclared", some come from=
> the frontend. I'll predeclare this. Arguably nothing should be predecl=
>ared.<br>
>=A0<br>=A0<br>=A0=A0- Jay<br>=A0<br><div><div></div>> Date: Sun, 21 Apr =
>2013 21:03:02 -0500<br>> From: <a href=3D"mailto:rodney_bates at lcwb.coop"=
> target=3D"_blank">rodney_bates at lcwb.coop</a><br>> To: <a href=3D"mailto=
>:m3devel at elegosoft.com" target=3D"_blank">m3devel at elegosoft.com</a><br>
>> Subject: Re: [M3devel] null type?<div><div class=3D"h5"><br>> <br>&=
>gt; <br>> <br>> On 04/21/2013 03:55 PM, Jay K wrote:<br>> > Wha=
>t is the meaning of this:<br>> ><br>> > cm3/elego/graphicutils/=
>src/RsrcFilter<br>
>> ><br>> >      init(p1, p2, p3, p4, p5, p6 :=3D NIL) : T;<br>&=
>gt; >      (* Initializes the resource search path. *)<br>> ><br>&=
>gt; ><br>> > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 :=3D =
>NIL) : T =3D<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 :=3D 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 passe=
>d to them<br>> as actuals.   That's what the language says.  It look=
>s 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>&=
>gt; 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 assigna=
>ble, with no runtime check.  Convert<br>
>> thinks it has a REFANY, and other calls to Convert could indeed<br>&gt=
>; give it something non-NIL, but not from the calls in Init.<br>> <br>&g=
>t; 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>&=
>gt; 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 undermin=
>ing<br>
>> the above intent.<br>> <br>> Which makes for a good example of h=
>ow 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>
>
>--047d7bd76f785e671604dafb6f57--