Can enum and immutable be unified?

[Ary Borenszweig]

Michiel Helvensteijn escribió:
 > Walter Bright wrote:
 >
 >> immutable - data that cannot change or be changed (imagine it is stored
 >> in ROM)
 >>
 >> const - read only view of data, you cannot change it but others can
 >>
 >> enum - compile time constant, has no storage
 >>
 >> The only place these overlap is in the declaration of symbolic
 >> constants. C++ has all three, but in a way that is context dependent
 >> that very few people are aware of.
 >
 > Aren't immutable and enum the same thing? At least to the programmer?

Yesterday I was thiking the same thing. I think the only difference to 
the programmer between those is that you can take the address of 
something immutable, but can't take the address of a compile time constant.

Now I wonder why would you like to take the address of something that's 
immutable. The times I remember passing something's address is to change 
it, something like:

int x = 10;
foo(&x);
// now x might have changed

But immutable variables cannot change, so no need to pass it by reference.

The other usage is performance. If it's an immutable big struct you 
might want to pass it by reference instead of copying the whole thing. 
If you can't pass a reference to something immutable you couldn't do 
with this optimization. But in this case, the compiler could choose to 
rewrite mentions to big immutable variables as references to those in a 
transparent way to the programmer. Of course this is harder for the 
compiler writer, but it's much easier for the user.

(as a starting point the compiler could do without this optimization and 
see if the users are having problems without it)

I can't come up with other cases where you'd want to pass a reference to 
something immutable.

So let's suppose we don't need to take an immutable varaible's address. 
We get rid of "enum" then and unify "immutable" and "enum" into the 
single "immutable" keyword. The compiler still has to determine what to 
put in ROM and what not. But I think this one is easy: primitive types 
can go in ROM, also maybe small immutable structs, maybe primitive 
arrays, but not classes or references to classes.

Is there something fundamentally wrong with this reasoning?