[Nickle]crashing nickle in <100 bytes
Keith Packard
nickle@nickle.org
Tue, 23 Jul 2002 19:43:13 -0700
Around 1 o'clock on Jul 24, Carl Worth wrote:
> Thanks. I take it this hasn't been committed yet though, right?
Yeah, I went ahead and committed the whole mess. Bool types, utf-8 getc/
putc/ungetc and the fix for recursive automatic struct initializers.
> With this change, will it actually be possible to implement list
> structures without using pointer datatypes, (as in the definition
> above)?
Yes, but you can already do that with unions:
typedef list;
typedef union {
void end;
list next;
} listref;
typedef struct {
listref ref;
} list;
listref listend = (listref.end)<>;
list a = { ref = listend };
> Hmm... with a new nil type, I wonder if it wouldn't make sense to
> change what happens when objects are declared without
> initializers.
Nil isn't a type, it's just a value which is commensurate with every
pointer type. I'm not sure what type it is...
> For example, currently primitive datatypes and structured values behave
> slightly differently:
I added these default initializers on Bart's request -- it was a pain to
manually initialize a nested structure so that you could start assigning
to the various members. This makes nickle a bit friendlier to C
programmers.
> Perhaps all uninitialized data could receive a value of nil?
I like the current exception when using uninitialised data; that catches
more programming errors. Besides, there isn't one value which is
commensurate with every type in the system; nil is a pointer value.
> Maybe it would even make sense to eliminate the convenience creation
> of structures and instead just initialize them to nil? (Especially
> since the programmer can get the empty structure by simply adding an
> empty initializer, "= {};")
One of the convenience features is that nested structures are also created
automatically.
> One thing that I would like is if I could assign a structured value
> without explicitly providing its type, (in the same style as the
> initializer), such as:
Yes, that would be nifty, but it requires transmitting type information
backwards across the assignment operator. As these values can occur in
any expression context, the general solution requires fairly complete type
inference which is about to be thrown out the window in favor of algebraic
types.
Keith Packard XFree86 Core Team HP Cambridge Research Lab