Can enum and immutable be unified?

[Ary Borenszweig]

Ary Borenszweig escribió:
> 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.

Sorry, I wanted to write that the compiler can choose what things are 
compile-time constants and what things should go into ROM. Primitives, 
small structs, etc, should be compile-time constants.