[Nickle]Tonight's topics

[Bart Massey]

Tonight's topics: left to right, <undef> partial and total, broken
types, 0 considered harmful.


Keith and I just spent several hours on the phone,
concluding several things:

1) He is right, and I am wrong.  Even right-associative
   operators should evaluate left-to-right.

2) There should be no such thing as a structured value some
   of whose elements are <undef>.  Yet, the language should
   not try to guess what value things should be initialized
   to.  Ergo, though I was fond of them, the automatic
   implicit struct and array creation have to go.  This will
   ensure prompt run-time detection of trouble, and remove a
   serious definitional problem in the type system.

3) There should be no way to create a type with no obviously
   well-defined values.  In the absence of partial <undef>
   this means that
     typedef x;
     typedef struct {
        x y;
     } x;
   has to go, and also its singly and mutually recursive
   cousins.  I sincerely doubt anyone will miss them.

4) Runtime <undef> detection should be augmented by a static
   analysis ala Java to detect the use of potentially
   undefined values.  Since this analysis doesn't have to be
   sound or complete, it can be simple and comprehensible.
   We will probably make it sound and conservative for
   everything but globals anyhow.  Hopefully it will be
   useful rather than annoying, as I've found it to be in
   Java.

5) There's a whole bunch of cruft in the design and
   implementation of Nickle around the "zero" value.
   We don't want to talk about what the language and
   implementation currently do.  Here's how things will
   work when Keith's done:

     As in the C specification, the lexeme "0" will be
     magic.  It will be different than, e.g., 0x0, 00, 0.0,
     '\0', and (1-1).  It may denote any one of several
     constants, depending on its type context, namely the
     zero integer, the null value of some specific pointer
     type, or the zero of type poly.  This last constant is
     a zero created by e.g.
       poly x = 0;
     and will be type-convertible at runtime to any of the
     other kinds of zero.

   The end result of this is that 0 will no longer be a
   source of type insecurity.  For example, the following
   will finally be an error:

     int x = 0;
     poly y = x;
     *int z = y;

     *int x = 0;
     poly y = x;
     *string z = y;

     
Comments on any of this are welcome.

	Bart