[M3devel] null type?

[Jay K]

 > 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};    At the backend level?  It is always CGType.Addr, right?  And there are not fields within a struct being pointed to, right?   Our backend interface has two type systems. 1) CGType = roughly [int8, uint8, int16, uint16, int32, uint32, int64, uint64, float, double, extended, addr, struct]    That is it -- pointers are just addresses, no type beyond that. Be they record pointers or objects or VAR parameters.   Structs have a size associated with them as needed. But no fields.  2) typeids, opaques, structs, enums, typenames, objects, fields, methods   They are overlapping.  The NTx86 backend does nothing with the second set of types, and it works, and it is correct. Debugging is not good.   The gcc backend, only for some targets, encodes the second set of types in strange ways that only m3gdb understands. They have no affect on codegen, and some targets, e.g. Darwin and I think HP-UX, ignore them entirely. Debugging is not good on Darwin or with stock debuggers.   In the C backend, originally, I also ignored the second set. And again, it works but debugging was poor.Now in the C backend, I pay a lot of attention to the second set and it is much better. Not quite done, but getting there.  The question is in that context.  Given a variable/parameter of type NULL, what is its best most typeful representation in C or C++?Probably just void* or char*.   - Jay Date: Mon, 22 Apr 2013 16:29:06 -0700
From: lists at darko.org
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] null type?

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
> 
 		 	   		  

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