[Nickle]constant values

Keith Packard keithp@keithp-149.keithp.com
Tue, 14 Aug 2001 00:13:59 -0700


The Nickle implementation has provided for read-only storage for a long
time, for a while it was used to hold some numeric constants to ensure they
wouldn't get overwritten.  But read-only storage hasn't ever been exposed
in the language, largely because the C const model is horribly broken.

The C model is that 'const' variables have storage allocated from 
non-writable memory, such as write-protected RAM or even ROM.  Because 
there's no run-time checking, and values are passed by address all over 
the place, this forces C to make 'const' a part of the datatype which 
causes ugliness all over the landscape.

I think that 'const' must not be a part of the datatype; this eliminates 
the C horror of including 'const' as a part of typechecking.  'const' 
should be an attribute of the underlying storage; but I'm not sure how 
fine-grained it should be.  

Should we be able to create a 'const' array variable which contains a
non-'const' array object?  That would allow modifications to the array 
elements but not a wholesale replacement of the array value.  How about 
the other way 'round?

I've hacked some stuff up to start experimenting, but I'm not happy with 
the results yet.  In particular, the syntax is horrible:

	int	const a = 1, const b = 2, c = 3;

I could attach the 'const' to te datatype as a prefix like the storage 
class.  It also doesn't cause the 'const' attribute to be inherited by 
related storage:

	> int[3] const a = { 1, 2, 3 };
	> a = (int[3]) { 4, 5, 6 };
	Unhandled exception "readonly_box"
	        "Attempted assignment to constant box"
	        [3] {4, 5, 6}
	> a[0] = 7
	7
	> a
	[3] {7, 2, 3}

I'd fix that, but I don't know how it should work.

-keith