[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