This page is part of the web mail archives of SRFI 100 from before July 7th, 2015. The new archives for SRFI 100 contain all messages, not just those from before July 7th, 2015.
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 <initerm@xxxxxxxxx> 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 <donovan@xxxxxxxxxxx>: > > > > On Wed, Sep 16, 2009 at 1:36 PM, Robby Findler > > <robby@xxxxxxxxxxxxxxxxxxxxx> 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