[R6RS] 3 things we may want to vote on
William D Clinger
Tue Jun 7 19:58:10 EDT 2005
> - Make continuations created by BEGIN accept multiple values?
I would vote "yes" on this. It would not break any portable code.
> Two decisions, actually, the second one on specifying primitives to
> return zero values.
I'm against this. Changing existing primitives to return zero
values would break some R5RS-portable code, e.g. the following
macro-expansion of BEGIN:
(begin E1 E2 E3 ...)
=> ((lambda (ignored) (begin E2 E3 ...))
You can't dismiss this as merely pedagogical, since my Twobit
compiler expands BEGIN forms in essentially this way. Others
have written similar code.
I wouldn't hesitate to break code that isn't portable under the
R5RS rules, and I'm willing to break R5RS-portable code if the
benefit outweighs the cost, but I don't see the benefit here.
> - Zap SET-CAR! & SET-CDR! ?
I like this in principle, but it would break a lot of portable
code unless SET-CAR! and SET-CDR! can be provided by a module.
I think this would be a good test for the R6RS module system.
If the R6RS module system can't be used to provide a portable
implementation of SET-CAR! and SET-CDR! that plays well with
the other list primitives, then I will probably argue for
leaving SET-CAR! and SET-CDR! in the language.
> - Make -> a valid identifier?
I have no problem with this, although I don't recall the
motivation for it.
> Two decisions on this issue as well: Whether to make -> a valid
> identifier (for which a lot of people at the last Scheme workshop
> voted), and, if so, how to do it.
As Kent pointed out, the devil is in the details. We have a
concrete proposal, but it isn't acceptable because -i becomes
More information about the R6RS