[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