[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