[R6RS] Collated opinions on list of issues

Marc Feeley feeley
Wed Mar 31 08:12:13 EST 2004


I have collated all the opinions on the list of issues into a single
list.  Please read it to understand the position of others and get a
feeling of how controversial the issues are.  When there is no text
next to an editor's name it means that no opinion was expressed
(please let me know if I have made an error).

There is strong consensus on some issues (e.g. remove
transcript-{on,off}), some are fairly evenly split
(e.g. case-sensitive syntax) and for others opinions are rather
neutral (e.g. tighten up specification of EQ? and EQV?).

As expected, there is strong consensus that modules, non-hygienic
macros, and records need to be addressed.  I think we should start
technical discussions on those issues first given that they are
interrelated and it is likely that other issues depend on them.

Marc

================================================================
DELETIONS from R5RS

- remove transcript-{on,off}

  Clinger:

  Dybvig:
    No objection.

  Feeley:
    Yes.

  Flatt:
    In favor.

  Kelsey:
    Yes.

  Serrano:
    Yes, let's remove them.

  Sperber:
    By all means.


- remove FORCE and DELAY

  Clinger:
    I think the main argument for keeping these in R6RS is that they
    are really hard to implement correctly.  They don't belong in the
    core, but they'll be reimplemented badly if we don't put them into
    a standard library.

  Dybvig:
    I agree with Will that these should be in a standard library.

  Feeley:
    No, they are useful.  They could be put in a standard library however.

  Flatt:
    Neutral.

  Kelsey:
    No.

  Serrano:
    Yes, let's remove them too.

  Sperber:
    Why?  Again, I find these very useful.


- remove multiple values

  Clinger:
    I don't see the point of removing these.  Multiple values have
    demonstrated their worth in several implementations, including at
    least Chez Scheme, Larceny, and PLT Scheme.  What advantage would
    accrue from removing them?

  Dybvig:
    I believe that they should remain and that we should in fact add
    let-values from SRFI 11.

  Feeley:
    I think multiple values are a wart in the language.  I'm only
    mildly in favor for removing them and will not pursue the issue
    unless others support removal.

  Flatt:
    Weakly opposed. (Like others, I find multiple values useful.)

  Kelsey:
    No.

  Serrano:
    No, let's keep them. If we keep them in the language, we can
    design a construction that enables compilers to handle MV without
    allocation structures on the heap. If it is only a library, I'm
    afraid this would be nearly impossible.

  Sperber:
    Like Manuel and Kent, I don't see any particular need for this.  I
    think the present specification fits Scheme very well, and I've
    found them to be very useful.  I'd probably add some syntactic
    sugar in a library, but other than that, I'd leave them alone.


================================================================
INCOMPATIBLE CHANGES to R5RS

- make syntax case-sensitive

  Clinger:
    This would break at least some real code.  If the perceived need
    for case-sensitive identifiers is to communicate with other
    languages, then let's invent some lexical syntax such as
    {hashCode} or |hashCode| that allows programmers to write
    case-sensitive identifiers.  That wouldn't break any R5RS code.

  Dybvig:
    I wouldn't mind breaking some existing code to make symbols case
    sensitive.  My reasons have only to do with expanding the namespace.
    For example, I find it really useful to write, e.g., Expr for the
    procedure that handles exprs, and use expr as the name of Expr's argument.

  Feeley:
    I support this for two reasons, 1) more elegant interfacing with
    languages that are case-sensitive, 2) because case-insensitivity
    is a concept that is dependent on natural language (English,
    French, Turkish, etc).  The first reason is arguable and very much
    a question of taste but the second reason is hard to go against,
    especially if source code can be written in Unicode.  The classic
    example is that the lowercase version of "I" is "i" in most
    languages but "dotless-i" in Turkish.  So "i" and "I" are not the
    same case-insensitive identifiers to a Turk.  Adopting a
    case-sensitive syntax would eliminate this issue.

  Flatt:
    Neutral.  DrScheme's teaching languages are case-sensitive, and
    it's not clear to me whether this increases or decreases confusion
    for beginners.  Those who prefer case sensitivity in PLT Scheme
    put "#cs" in front of an S-expression (usually a module) to make
    it case sensitive, and this seems to work well.

  Kelsey:
    No.

  Serrano:
    YES!!! Strongly yes.

  Sperber:
    I also don't see any pressing concrete need for this.  (Marc:
    maybe you could elborate how this would improve interoperability?)
    Sure, the specification needs to handle extended character sets,
    but Tom Lord's has just shown one simple way to address this in
    his SRFI 52 draft.
    I actually like case-insensitive syntax, and at least one HCI
    person (who gave a talk at the Pittburgh ICFP) seems to think that
    it's the better way to go.


================================================================
EXTENSIONS that would break implementation-specific extensions

- specify evaluation order

  Clinger:
    www.schemers.org lists 60 implementations of Scheme.  Some of
    these implementations have defined an implementation-specific
    order of evaluation, and have told their users they can rely on
    this order of evaluation.  No matter what order we choose--- if we
    can even agree on one among ourselves, which I doubt--- it will
    break code that was written to rely upon other orders of
    evaluation.

  Dybvig:
    I don't mind specifying that internal defines are ordered from
    left to right, but I object to specifying the order in which the
    subexpressions of an application or right-hand sides of let and
    letrec are evaluated.  The unspecified order gives the programmer
    a way to express that evaluation order is unimportant, and we'd
    lose that entirely.  Said another way, a fixed evaluation order
    forces overspecification.
    I've considered the argument that it's easier to prove programs
    correct or to portably test programs if the evaluation order is
    specified, but a simple way around that is to first transform the
    program to make the order explicit, then prove or test the
    program, and draw conclusions only about the transformed program.

  Feeley:
    Neutral.  I don't think it solves any problems and it would be
    harder for the compiler to perform some optimizations.

  Flatt:
    Strongly in favor.

  Kelsey:
    Torn.  It would help make code portable but there are
    implementations out there that might be hard to change.  On this
    one I feel strongly both ways.

  Serrano:
    I'm rather neutral. I agree that a left-to-right evaluation order
    is intuitive and I agree that for portability enforcing an
    evaluation order is important.

  Sperber:


- support for processes

  Clinger:
    Here we have the same issue as with evaluation order, and we also
    have the fact that a process semantics that makes sense for many
    architectures and OSs isn't going to make sense for all.  Support
    for processes may belong in standard libraries, but that support
    should not be required of all R6RS-conforming implementations.

  Dybvig:
    Pthreads is fairly ubiquitous these days, so it might be useful to
    have a standard thread system based on pthreads.  This is probably
    better as an SRFI in the short term, however.

  Feeley:
    Neutral.  Processes/threads are important but I doubt we can
    arrive at a consensus on a process model and API.  I think we
    should discuss this further.  Perhaps my threading SRFIs can be
    used as a starting point.

  Flatt:
    Opposed. (These should all be future work via SRFIs.)

  Kelsey:
    This needs to be a (successful) SRFI first.

  Serrano:
    Yes.

  Sperber:


- support for network programming

  Clinger:
    IMO this is more appropriate for standardization than processes,
    and belongs in a standard library, but should not be required of
    all implementations.

  Dybvig:
    This should go into a standard library.

  Feeley:
    Neutral.  Like processes I doubt we can arrive at a consensus on a
    networking model and API.  It would be best to start with a SRFI.

  Flatt:
    Opposed. (These should all be future work via SRFIs.)

  Kelsey:
    This needs to be a (successful) SRFI first.

  Serrano:
    Yes.

  Sperber:


- object-oriented programming

  Clinger:
    There are many incompatible extensions for object-oriented
    programming.  We can't standardize here without breaking a lot of
    implementation-specific code.  If there were a clear winner among
    the OO extensions, it would be one thing, but I don't see a clear
    consensus at this time.

  Dybvig:
    This is probably too controversial.

  Feeley:
    Against.  It would be best to start with a SRFI.

  Flatt:
    Opposed. (These should all be future work via SRFIs.)

  Kelsey:
    This needs to be a (successful) SRFI first.

  Serrano:
    No. I don't think that we can arrive at a consensus in a
    reasonably short period.

  Sperber:


- external representation for records

  Clinger:
    Again, there are several incompatible implementation-specific
    extensions for this.  It might be worthwhile to break them, since
    whatever we decide to do for records is going to break some
    implementation-specific extensions anyway.

  Dybvig:
    This seems like a good idea to me.

  Feeley:
    I support this so that debugging and textbooks can be more
    consistent over implementations.  While we are at it we should
    also standardize on an external representation for procedures and
    ports.

  Flatt:
    Opposed. (These should all be future work via SRFIs.)

  Kelsey:
    This needs to be a (successful) SRFI first.

  Serrano:
    Neutral.

  Sperber:


- serialization

  Clinger:
    This is a generalization of the issue for records, I think.  I'm
    not convinced serialization is worth standardizing, but I doubt
    whether too many systems have implementation-specific extensions
    for serializing general objects.

  Dybvig:
    No opinion.

  Feeley:
    Serialization of records is useful for distributed systems (i.e.
    exchanging records between different processes) and for storing
    records in files.  It would be good to allow such communication of
    records between different implementations of Scheme, so a standard
    serialization format is needed.

  Flatt:
    Opposed. (These should all be future work via SRFIs.)

  Kelsey:
    This needs to be a (successful) SRFI first.

  Serrano:
    Let's take care about this. What would it mean to serialize a
    compiled closure? I'm in favor of serialization if we accept to
    exclude some date types (such as procedure). I'm against it if the
    serialization is supposed to support all values.

  Sperber:


================================================================
EXTENSIONS to R5RS (controversial and probably unnecessary)

- pattern matching / destructuring

  Clinger:
    Mainly I don't want to put this sort of thing in the core
    language.

  Dybvig:
    No opinion.

  Feeley:
    I'd like to discuss this because pattern matching becomes very
    useful in the presence of records.

  Flatt:
    Opposed. (Another SRFI.)

  Kelsey:
    More needed SRFIs.

  Serrano:
    Yes. Having pattern-matching and redesigning variable arity
    functions could help the compiler.

  Sperber:


- abstract data type for continuations

  Clinger:
    For years I've been pointing out that a procedure that takes one
    argument and passes it to a captured continuation is equivalent to
    that continuation, and I don't see the point of creating any
    artificial distinctions between the two...
    ...unless they are necessary to support composable continuations,
    and we decide to take that leap.  

  Dybvig:
    This strikes me as similar to the arity? procedure that we've
    voted down several times in the past, in that it is useless in the
    presence of procedural embeddings.  If an continuation? is false
    of an object, does that mean it can't behave like a continuation?

  Feeley:
    I strongly support this and it should be in the core.  Call/cc
    would go into a standard library.

  Flatt:
    Neutral.

  Kelsey:
    More needed SRFIs.

  Serrano:
    Let's get rid of continuation ;-)

  Sperber:
    I'm all for that, for the reasons Marc states in his Scheme workshop
    paper.


- support composable continuations

  Clinger:
    My mind is open on this.

  Dybvig:
    I think it would be nice to standardize on a set of low-level
    operators that are strong enough to implement call/cc and the
    variety of functional control operators that have been proposed,
    then relegate call/cc to library status.  (To be clear: I want to
    make sure we have support for continuations in the core.)

  Feeley:
    I'm not sure what this means.

  Flatt:
    Neutral.

  Kelsey:
    More needed SRFIs.

  Serrano:
    Against.

  Sperber:


- add box types

  Clinger:
    This just isn't very important.

  Dybvig:
    I never use boxes myself, so I'd prefer to let them die.  There's
    not much advantage to including them once we have records.

  Feeley:
    I weakly support this.

  Flatt:
    Neutral.

  Kelsey:
    More needed SRFIs.

  Serrano:
    What for? Against. 

  Sperber:


- uninterned symbols
  vs. Chez's globally unique names

  Clinger:
    My mind is open on this.  We may need something like Chez's
    globally unique names for the record system.

  Dybvig:
    Naturally, I'd like to include globally unique names (which we call
    gensyms).

  Feeley:
    I support uninterned symbols (I don't know Chez's globally unique
    names well enough).

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    Neutral.

  Sperber:


- extended symbol syntax

  Clinger:
    I'd prefer to simplify the symbol syntax.  I gag on any syntax
    that allows a program's identifiers to contain whitespace.

  Dybvig:
    This goes along with gensyms.

  Feeley:
    I strongly support this.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    Yes.

  Sperber:


- add LETREC*, define internal DEFINE in terms of it

  Clinger:
    My mind is open on this, but I will offer some arguments against
    doing this when we get around to technical discussions.

  Dybvig:
    I don't care about adding letrec*, but specifying that definitions
    be evaluated left to right might be useful.

  Feeley:
    I support this.

  Flatt:
    In favor.

  Kelsey:

  Serrano:
    Neutral.

  Sperber:
    I'm all for making internal and global DEFINE to have consistent
    semantics, by whichever means necessary.  I'm agnostic on how to
    achieve this.  LETREC* is probably useful, so I'm for adding it.


- optional and keyword arguments as in DSSSL

  Clinger:
    CASE-LAMBDA is better than optional arguments, and keyword
    arguments should be banished to some KEYWORD-LAMBDA macro.

  Dybvig:
    I prefer case-lambda.  Optional and keyword arguments can be
    handled in a library.

  Feeley:
    I support this.  I do not feel case-lambda is an appropriate
    substitute because in my view it leads to unelegant code in the
    common case.  Normally the same core computation is performed by
    each combination of optional arguments and with case-lambda this
    requires defining a separate procedure performing this core
    computation.  Moreover keyword arguments implemented as a macro
    will be very inefficient (construction and traversal of the list
    of parameters).  I think keyword arguments will be necessary for
    some I/O procedures that would otherwise have too many parameters
    with no obvious ordering (for example an "open-file" procedure
    that needs the filename, the creation mode, the character
    encoding, the end-of-line encoding, etc).

  Flatt:
    Weakly opposed.

  Kelsey:
    Not in plain LAMBDA.  Their could be other LAMBDA-...

  Serrano:
    Well, well. I support this but I hope that we will be able to
    improve a little bit the semantics of DSSSL arguments.

  Sperber:


================================================================
EXTENSIONS to R5RS (controversial or difficult but necessary)

- module system

  Clinger:

  Dybvig:
    I favor both Dr. Scheme's notion of modules, which to me are more
    like libraries or compilation units, and Chez Scheme's notion of
    modules, which are available to control scope at all levels.  I
    believe that they are really separate notions.

  Feeley:
    I strongly support this.

  Flatt:
    Very strongly in favor. (To me, other topics are a waste of time until
    this one is settled.)

  Kelsey:
    Yes.

  Serrano:
    Yes.

  Sperber:


- non-hygienic macros

  Clinger:

  Dybvig:
    Naturally, I think this is a good idea.

  Feeley:
    I strongly support this.

  Flatt:
    In favor.

  Kelsey:

  Serrano:
    I *strongly* support this.

  Sperber:


- records

  Clinger:

  Dybvig:
    Yes, both in a procedural and syntactic form.

  Feeley:
    I strongly support this.

  Flatt:
    In favor.

  Kelsey:
    Yes.

  Serrano:
    Yes.

  Sperber:


- mechanism for new primitive types

  Clinger:

  Dybvig:
    Isn't this essentially the same as records?

  Feeley:
    I strongly support this, but to me this just means records are new
    types.

  Flatt:
    I'm not sure what this means.

  Kelsey:

  Serrano:
    I support this. Contrarily to Marc I think that not only records
    should define new types. I think that this feature is important
    when it comes to the foreign interface.

  Sperber:


- Unicode support

  Clinger:

  Dybvig:
    Yes (as part of the core).

  Feeley:
    I strongly support this.

  Flatt:
    Neutral.

  Kelsey:
    Maybe.  We should at least adjust the language to make it more
    compatible with unicode.

  Serrano:
    I'm afraid we have to deal with unicode

  Sperber:


- errors and exceptions

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    I strongly support this.

  Flatt:
    In favor.

  Kelsey:
    Maybe.  I am not sure that anyone knows what the right
    thing to do is.

  Serrano:
    I *strongly* support this.

  Sperber:


- require mode where "it is an error" means "an error is signalled"

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    I support this for most errors (some errors are too hard to
    detect).  I think the standard should explicitly say which
    exception is raised by each type of error.

  Flatt:
    In favor.

  Kelsey:
    Yes, depending on the details of which errors are included.

  Serrano:
    I agree with Marc,
      I support this for most errors (some errors are too hard to detect).
      I think the standard should explicitly say which exception is raised
      by each type of error.

  Sperber:
    I suggested this, so I must be for it.


================================================================
EXTENSIONS to R5RS (probably not terribly controversial)

- multiline comments

  Clinger:

  Dybvig:
    Yes.  Plus #;<s-expr> to comment out s-expressions.  This came up
    at some point but didn't make this list.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:
    Yes.

  Serrano:
    Yes.

  Sperber:


- external representation for circular structures

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:
    Yes, although I am not sure if WRITE should produce such
    a representation by default.

  Serrano:
    Neutral. I think this is tightly related to serialization.

  Sperber:


- #!eof

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:
    Yes.

  Serrano:
    I'm not sure to understand the meaning of #!eof. Does it means
    that when the reader will read #!eof it will return an object
    satisfying the R5Rs eof-object? predicate? If this interpretation
    is correct I'm against it.

  Sperber:
    I'm all for having a single distinguished EOF value, even though
    something subconscious about this particular syntax strikes me as
    ugly.


- more escape characters

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:
    Yes.

  Serrano:
    Yes.

  Sperber:


- require that #f, #t, and characters be followed by a delimiter

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    Yes.  It will make the following external representations
    possible: #f64(...) and #record-name(...) whether they are
    standard or implementation specific extensions.

  Flatt:
    Neutral.

  Kelsey:
    Yes.

  Serrano:
    Yes.

  Sperber:
    I'm agnostic on this.-


- CASE-LAMBDA

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    I'm opposed.  Both optional and keyword arguments are needed.

  Flatt:
    In favor.

  Kelsey:

  Serrano:
    I'm against.

  Sperber:


- add COND-EXPAND

  Clinger:

  Dybvig:
    Is this something like eval-when?  We've worked out eval-when so
    that it is really quite sensible (and useful), but I sense strong
    opposition to it.  I don't think the Dr. Scheme notion of module
    completely covers what eval-when can do, but I'd be happy to be
    proven wrong.

  Feeley:
    Yes.  This will make the SRFI process more useful and allow
    introspection.

  Flatt:
    Strongly opposed. (We should have a module system.)

  Kelsey:

  Serrano:
    Yes.

  Sperber:


- allow the name of the macro being defined in SYNTAX-RULES to be
  arbitrary (or _)

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:
    Yes.

  Serrano:
    Neutral because, I repeat my self, I'm in favor of non hygienic
    macros *and* pattern matching.

  Sperber:


- allow continuations created by begin to accept any number of values

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:
    Yes.

  Serrano:
    I don't understand the motivation here so I'm neutral.

  Sperber:


- tighten up specification of EQ? and EQV? (or otherwise address their
  portability problems)

  Clinger:

  Dybvig:
    No opinion.

  Feeley:
    Neutral.

  Flatt:
    Neutral.

  Kelsey:
    Yes.

  Serrano:
    Neutral.

  Sperber:


- tighten up specification of inexact arithmetic

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:
    Maybe, depending on what is meant.  I would definitely like to
    make it easier to avoid silent coercions from exacts to inexacts.

  Serrano:
    Neutral.

  Sperber:


- add +0, -0, +inf, -inf, +nan

  Clinger:

  Dybvig:
    Yes, but with slightly different syntax.  +0 and -0 are already
    both exact 0, and I wouldn't want to change that.  IEEE -0.0 would
    presumably have to be written as -0.0 (or -0e20 or -0###, etc.).
    I also favor +inf.0, -inf.0, and +nan.0 since the .0 makes clear
    that they are inexact (in case someone someday wants to add exact
    nan or [hmm...] inf); also, the .0 makes the numberness jump out
    better.
    This probably goes along with a commitment that inexact numbers
    are IEEE floats.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    Yes for +inf, -inf, +nan. Neutral for +0, -0.

  Sperber:


- add bitwise operations on exact integers

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:
    Yes.

  Serrano:
    Yes.

  Sperber:


- SRFI 4 homogeneous numeric vectors

  Clinger:

  Dybvig:
    No opinion.

  Feeley:
    I think homogeneous numeric vectors are important, but I'm not
    sure SRFI 4 is the best way because of the explosion of primitives
    (on the other hand this seems necessary for performance).  I
    believe byte vectors will be necessary for binary I/O.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    I think that this issue should be related to the possibility of
    defining new types and to the serialization. I think that this is
    more complex than it looks like.

  Sperber:


- specify dynamic environment

  Clinger:

  Dybvig:
    No opinion.

  Feeley:
    Yes.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    What for? Multi-threading for instance? I don't understand thus
    I'm neutral.

  Sperber:


- operations on files

  Clinger:

  Dybvig:
    Yes.

  Feeley:
    Yes.  But we need to be careful and stay portable to various file
    systems.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    I strongly in favor of this.

  Sperber:


- binary I/O
  or: new I/O subsystem entirely

  Clinger:

  Dybvig:
    Unsure.

  Feeley:
    Yes.  Scheme I/O currently sucks.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    I strongly in favor of this.

  Sperber:


- string code

  Clinger:

  Dybvig:
    Yes (library).

  Feeley:
    I'm not sure what this means.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    What doe it mean?

  Sperber:


- regular expressions

  Clinger:

  Dybvig:
    Yes (library).

  Feeley:
    Neutral.  To me regular expressions are an example of a user
    library (i.e. not a "standard" library specified in the R6RS).

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    Yes.

  Sperber:


- command-line parsing

  Clinger:

  Dybvig:
    Yes (library).

  Feeley:
    Neutral.  Like regular expressions, this should also be a user
    library.  However it might be useful to standardize on scripting
    (i.e. features that are necessary to write scripts and the syntax
    of scripts).  The problem is that this is very operating-system
    specific.  I wonder if we shouldn't add operating-system specific
    libraries to the R6RS, in particular a UNIX section and a
    Microsoft Windows section.  These sections would specify features
    that apply to these systems only.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    Yes.

  Sperber:


- hash tables

  Clinger:

  Dybvig:
    Yes (library).

  Feeley:
    Neutral.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    Yes.

  Sperber:


- library for dates

  Clinger:

  Dybvig:
    Yes (library).

  Feeley:
    Neutral.

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    Yes.

  Sperber:


- system operations

  Clinger:

  Dybvig:
    Yes (library).

  Feeley:
    Neutral (I would be more in favor if we have operating-system
    specific sections).

  Flatt:
    Neutral.

  Kelsey:

  Serrano:
    Yes.

  Sperber:


================================================================
EDITORIAL CHANGES

- split language into core and libraries

  Clinger:

  Dybvig:
    Yes---but I prefer a rather larger core than some might prefer,
    probably even larger than the current r5rs.

  Feeley:
    Strongly in favor (but I realize this will require a lot of
    discussion).

  Flatt:
    Strongly in favor.

  Kelsey:
    Yes.

  Serrano:
    I still don't have an opinion...

  Sperber:


================================================================
ADDITIONAL EXTENSIONS

- Support for expression comments, as mentioned above.

  Dybvig:
    (let ((x 3) #;(y 4))
      #;(write (list x #;y))
      (* x x))
    reads as (let ([x 3]) (* x x)).  This also subsumes the common usage of
    ' to comment out top-level forms, which breaks down for non-top-level
    definitions.

- Support for a subset of Common Lisp format (in a library).

  Dybvig:
    Lack of support for formatted I/O is something that turns lots of
    people off about Scheme.

================================================================



More information about the R6RS mailing list