Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> (My strong suspecion is that it *is* 12 
>> *bytes* - since, after all, a single Unicode code point is 24 bits already.)
> 
>   That depends on whether it's a "raw" unicode value (ie. in practice an
> integer) or eg. an UTF8-encoded unicode character (which would make each
> character of variable size).

My understanding is that single characters are stored as 32-bit 
integers. (Because that's simple, and they fit nicely into CPU 
registers.) I could be mistaken though...

>> The situation is actually worse than it looks. All this lazy evaluation 
>> magic is implemented by storing program state around the place, so an 
>> "unevaluated" string probably takes up more space still...
> 
>   I have always wondered about that. Lazy evaluation can indeed be of
> great help optimizing many things. For example, if you read a file into
> a string and then just read a small part of it, the lazy evaluation will
> automatically skip reading the rest of the file.
> 
>   However, in situations where lazy evaluation does not actually help
> much (or at all), which isn't a very uncommon case, it feels like a
> useless waste of memory.

And time - don't forget time. (Takes time to build a closure, takes time 
to execute it. All of which can be avoided if you know you don't need it.)

For this reason, we have the following facts:

1. There is a special compiler pass for detecting places where laziness 
is *not* necessary, and automatically removing it. (E.g., an inner loop 
where you can *see* that the value is obviously used in the next loop.) 
When you compile a library, the compiler even leaves a note to itself 
telling it how strict each function is with its arguments.

2. There are mechanisms for the programmer to explicitly turn off 
laziness where not required. (Unlike the compiler's automatic detection 
stuff, this operation actually changes the behaviour of the program - 
which is why you, the programmer, must say this is OK.)

Post a reply to this message