[R6RS] Re: Zapping SET-CAR! & SET-CDR!
R. Kent Dybvig
Tue Oct 26 18:27:40 EDT 2004
> I'm not sure I understand the "not a big deal". Do you mean that the
> underlying implementation language can be Scheme with set-ca/dr! and
> mutators for immutable record fields (to implement the #n# syntax) but
> set-ca/dr! is not available to the user?
No, I mean that the reader doesn't need set-car! or set-cdr! to handle
shared structure, and it doesn't need set-car! or set-cdr! to handle
cycles that can be resolved in some other way.
> It is the case (#1# #1=(a b c)) I am worried about. It is true
> that you could make multiple passes on the input to avoid set-car!
> in this case.
It is never necessary for the reader to make a multiple passes over the
stream of input characters, but it may have to do a second pass over
an intermediate representation of the output if a reference can't be
resolved on the first pass. When it does, read may be slower, but not
> However, this can't be handled without set-car!:
> #1=(a b #1# c)
Right. This would be an "unresolvable cycle" error.
> You could specify that this is an error, but that would be strange because
> the following very similar datums would be acceptable:
> #1=#(a b #1# c)
> #1=(a b #(#1#) c)
This difference doesn't seem strange to me, since it follows naturally
from differing properties of the datatypes. I assume it isn't strange
to you that (#1=a . #1#) is acceptable but the very similar datum
#(#1=a . #1#) is not. If this is a bad analogy, then I don't understand
> So is the proposal to
> - get rid of set-ca/dr! and keep the possibility of circular lists
> - get rid of set-ca/dr! and the possibility of circular lists
The latter. I'm happy to forgo cyclic list constants for the property
that the reader can be written using other, more primitive Scheme
features. Indeed, it seems like a waste of effort to support cyclic list
constants (in the reader, printer, list?, etc.) if we don't otherwise
have to support cyclic lists.
More information about the R6RS