rom vs const

12.2: adda/cstr/rom vs const:

what did rom vs const mean?
. the use of a "rom" designation only makes sense when sharing;
because, const means it's rom even to self
(ie, no writes after init) .
. the rom and const could reuse the same symbol
since when a param says const
that's the same as promise to the caller that it'll be
treated as read-only: ie, const.
. const is like in-mode and that is the default mode;
12.3:
. there is still the issue of what happens to a param later;
eg, when my formal param uses the constant specifier,
it assures not only that it won't do any modifications
but also that it won't pass the obj to a modifying function .
. another issue is compatability:
{mutable, contst} can be assigned to const;
only mutable can assigned to mutable
(a param is mutable when declared as inout-mode ).
. due to obj's having access to themselves,
whether an operation of theirs is really read-only
is totally up to them their private implementations
unless the system can detect when they write .
. if the system can't detect that,
there will have to be more copying to assure modularity .
12.2:
.  one efficiency trick for reducing the amount of copying,
is to wait for an attempted write
before doing the copy .
12.3:
. once the run-time mgt can detect writes to a rom,
it needs to raise an exception,
so, to avoid such messes,
param providers and their compilers
need to know what operations are modifiers .
. the way operations are described in an interface,
(`f) is assumed to be self-modifying
unless it states otherwise;
for f to be seen as non-modifying
it should be defined as a function
(ie, not out-mode params or side-affects)
or be tagged as non-modifying:
( !`f ).