Is there any reason that you want to stick to the term
"immutable", even saying "immutable is not literally
immutable"?

If you're just writing your own library it may not really
matter; only the users of the library need to understand
the local meaning of the term.

Being a srfi, however, means that somebody else in the
Scheme community may be going to follow the document and
implement it.  And you're asking them to use a term in
a way the term doesn't literally mean.  I guess there
must be a strong reason to do so, but I can't imagine any.

--shiro

>From: ChurlSoo Joo <xxxxxx@gmail.com>
Subject: Re: initial comments
Date: Thu, 17 Sep 2009 15:50:34 +0900

> How about making a note on the corresponding <specification>, like this?
>
> The mutable fields can be modified, whereas any attempt to modify the values
> of the immutable fields via mutators signals an error.
> Note: The immutable fields are not literally immutable.  Their values, for
>           instance, can be modified by other fields whose values work as a
> kind of
>           private methods.
>
>
> 2009/9/17, Donovan Kolbly <xxxxxx@rscheme.org>:
> >
> > On Wed, Sep 16, 2009 at 1:36 PM, Robby Findler
> > <xxxxxx@eecs.northwestern.edu> wrote:
> > > I'm not sure if this is what's being asked, but I too think of
> > > "immutable" as "cannot change" (which is in line with the English
> > > meaning of the word).
> > >
> > > Robby
> >
> > I'll third or fourth that motion.  "immutable" carries a very
> > different semantic that will lead to nothing but confusion if used in
> > the way being proposed in this SRFI.
> >
> > RScheme's object system has a concept of immutable slots exactly for
> > the reason someone mentioned earlier -- it's advise to the compiler
> > that the value will not change, and hence the value can be cached and
> > it's known that calls through an unknown function will not change it
> > either.  (IIRC, this idea was taken directly from Dylan)
> >
> > --
> > -- Donovan
> >
>
>
>
> --
> Joo