Operands extending this type can make a reasonable assumption of
immutability. In Ruby, almost nothing is truly immutable (set_instance_var)
but for the sake of our compiler we can assume the basic behavior will
continue to work unchanged (the value of an instance of fixnum 3 will remain
Knowing that we have a literal which will not change can be used for
optimizations like constant propagation.
ENEBO: This cachedObject thing obviously cannot be used from multiple
threads without some safety being added. This probably also is not the
fastest code, but it is very simple. It would be really nice to make this
side-effect free as well, but this is difficult without adding a level of
indirection or pre-caching each value we encounter during construction.
Implementing class is responsible for constructing the cached value.
Returns the cached object. If not then it asks class to create an
object to cache.
Has this object already been cached?
retrieve the live value represented by this immutable literal. An
interesting property of knowing something cannot change at compile
time is that all information neccesary to construct it is also known
at compile time. We don't pre-create these since we don't want to
assume the cost of constructing literals which may never be used.