[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on the draft standard
Jinx pointed out (as did Mike Shaff) that my posting is unclear.
After talking this one through with Mike Shaff, he and Ifeel that this
issue deserves some discussion, though the results may not be
applicable to the IEEE standard.
As we see it, there are two things we might want to be able to say
with respect to mutability:
(define-immutable fred value)
says that the binding of fred to value cannot be changed. The value
of the storage may change if there exists a mutator to alter it, thus:
(define-immutable mylist '(a b))
(set-car! mylist 1)
(set! mylist fred)
This construct is not theoretically necessary, but neither are a lot
of other things in scheme. What makes such a construct desirable is
that if I can show that there is no mutator that can act on the
relevant value, it frees me to do partial evaluation. If the value is
a lambda, this is enough to let me do procedure integration.
We could argue that this construct would be better expressed by
(declare immutable <name>) [syntax]
A DECLARE form would be permissable in any context that a define form
is permissable. Thinking about it, I prefer this syntax, as it works
for let-bindings as well as defines.
Note that a binding being immutable is not something that causes
contamination. It is okay to say
(let ((b mylist)) ..body..)
and do whatever I please to B.
The second thing that we want to say something about is immutability
of values. By this, we might use:
(define-immutable constant-fred (constant (list '(a b))))
The (constant X) item entitles to put the value in immutable storage,
and makes it an error to do an operation that side-effects the value.
This property is contaminating. Given,
(let ((b constant-fred)) ..body..)
B is a mutable binding to an immutable value.
Now, I am satisfied that I understand DEFINE-IMMUTABLE, though I
debate about DEFINE-IMMUTABLE vs DECLARE. It should either be
nonreversable (i.e. once a binding is made immutable I am stuck) or it
should have temporal scope lasting until the binding is made mutable
again using (DECLARE MUTABLE <name>). Evaluations in the interim are
entitled to have assumed integrability.
I don't like the CONSTANT construct. First, it really wants to be
syntax, because if it takes any value it can have really ugly
propagational effects. What you want, it seems to me, is to have
either a separate set of constructors for constant objects or a syntax
that can be wrapped around the constructors. I don't know which I
like better. In either case, a (CONSTANT?) would need to be added.
I would like to see some discussion of this on the scheme lists.
Finally, to the original question, which has since been answered. Are
the standard function bindings mutable. The answer is apparently
"yes", and thanks to those who answered.