[R6RS] Position on list of issues

[Manuel Serrano]

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

- remove transcript-{on,off}
Yes, let's remove them.

- remove FORCE and DELAY
Yes, let's remove them too.

- remove multiple values
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.

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

- make syntax case-sensitive
YES!!! Strongly yes.

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

- specify evaluation order
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.

- support for processes
Yes.

- support for network programming
Yes.

- object-oriented programming
No. I  don't think that we can arrive at a consensus in a reasonably short
period.
 
- external representation for records
Neutral.

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

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

- pattern matching / destructuring
Yes. Having pattern-matching and redesigning variable arity functions 
could help the compiler.

- abstract data type for continuations
Let's get rid of continuation ;-)

- support composable continuations
Against.

- add box types
What for? Against. 

- uninterned symbols
  vs. Chez's globally unique names
Neutral.

- extended symbol syntax
Yes.

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

- optional and keyword arguments as in DSSSL
Well, well. I support this but I hope that we will be able to improve
a little bit the semantics of DSSSL arguments.

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

- module system
Yes.

- non-hygienic macros
I *strongly* support this.

- records
Yes.

- mechanism for new primitive types
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. 

- Unicode support
I'm afraid we have to deal with unicode

- errors and exceptions
I *strongly* support this.

- require mode where "it is an error" means "an error is signalled"
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.

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

- multiline comments
Yes.

- external representation for circular structures
Neutral. I think this is tightly related to serialization.

- #!eof
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.

- more escape characters
Yes.

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

- CASE-LAMBDA
I'm against.

- add COND-EXPAND
Yes.

- allow the name of the macro being defined in SYNTAX-RULES to be
  arbitrary (or _)
Neutral because, I repeat my self, I'm in favor of non hygienic macros
*and* pattern matching.

- allow continuations created by begin to accept any number of values
I don't understand the motivation here so I'm neutral.

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

- tighten up specification of inexact arithmetic
Neutral.

- add +0, -0, +inf, -inf, +nan
Yes for +inf, -inf, +nan. Neutral for +0, -0.

- add bitwise operations on exact integers
Yes.

- SRFI 4 homogeneous numeric vectors
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.

- specify dynamic environment
What for? Multi-threading for instance? I don't understand thus I'm neutral.

- operations on files
I strongly in favor of this.

- binary I/O
  or: new I/O subsystem entirely
I strongly in favor of this.

- string code
What doe it mean?

- regular expressions
Yes.

- command-line parsing
Yes.

- hash tables
Yes.

- library for dates
Yes.

- system operations
Yes.

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

- split language into core and libraries
I still don't have an opinion...

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



-- 
Manuel