[R6RS] 3 things we may want to vote on

[William D Clinger]

> - Make continuations created by BEGIN accept multiple values?

I would vote "yes" on this.  It would not break any portable code.

> http://mailman.iro.umontreal.ca/mailman/private/r6rs/2004-October/000267.html
>
> 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 ...))
     E1)

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
ambiguous.

Will