[r6rs-discuss] comment and vote (if allowed)

From: Elf <elf>
Date: Mon, 20 Aug 2007 17:32:20 -0700 (PDT)

I was unable to register for the voting process due to a set of computer
failures on my end. I realise that this vote is invalid, but I wanted to bring
up a few things.

First, I have been using scheme for around 10 years. I've written code
in and for around 70% of the implementations listed on schemers.org,
professionally, academically, for teaching, and recreationally. At WPI I am
known for my scheme 'zealot' ways, and am often called upon by other students
(and professors) to explain why I use and love it, and to help them understand
it (in the cases of students). Professionally, I wrote a learning-constraints
engine for spam analysis. When non-programmers or dabblers ask me to teach
them to code, I haul out SICP. Scheme is a language-concept to which I am
thoroughly devoted.

However...

I am entirely against R6RS as it currently stands, and would vote 'no' if given
a chance. Here are some of my reasons. I will try to only cover material not
adaquately covered by others, so my objections to unicode,
numerical issues, record syntax, multiple-values, I/O, etc will go unstated
(besides in this sentence).

One of the stated goals of R6RS is to allow educators to use the language
to teach programming effectively. This will fail. 10 years ago, students
grumbled about the parentheses, but got over it. Today, students go insane
trying to understand macros. Scheme is confusing enough for most students
without adding tonnes of extra confusing syntax on top. Scheme is a beautiful
language, and books like SICP can help them appreciate that... but
with R6RS, many of the exercises will no longer work. Given the syntactical
unfamiliarity and discomfort that students already have to work through, adding
more and more confusing material will render scheme entirely useless
as a means of instructing anything other than the hatred of scheme (which is
already rampant).

Immutable exported identifiers are perhaps the least sound idea imaginable. As
an example, one of the most common things I do with records is something
like the following:

(define-record-type foo (make-foo a) foo?
      (a foo-a foo-a-set!))

(let ((s foo-a-set!))
     (set! foo-a-set!
           (lambda (foorec val)
               <some type or value checking for val>
               (s foorec val))))

...

which is incredibly useful for, say, using records as structs in an ffi, or
ensuring various options are legal in correlation with each other. Immutable
exports kills this. Furthermore, what is gained by this? There is no R6RS
support for explicit environments, which would be a way of keeping any
optimisation gains through immutability without forcing top-level bindings
to be horridly restricted.

The removal of "load" and of almost all REPL functionality is even more absurd.
First, again on the teaching front, it is significantly easier to
get comfortable and to debug one's programs when first learning if one has
direct instant feedback. The lack of "load" kills that. Second, perhaps
I am the alone in this, but I don't compile my Scheme as a general rule. I
live inside the REPL (and there are rarely less than two terminals with
interpreters running). I do not want to compile my code every half hour
as I'm testing ideas. What exactly is the rationale for leaving this out?
While R5RS may not have 'specified' it adaquately enough, I have yet to
find an implementation where (load "/path/file.scm") didn't work as expected.

I have another concern with R6RS, political in nature. One of the avowed
purposes of R6RS was to try to close the gap between implementations, to
acheive greater interoperability and portability. In what way will R6RS
achieve this, as the community currently stands? Most of the original RnRS
authors, major SRFI writers, and dialect implementators have formally and
informally registered objections to it, in whole or in part, and voted 'no'.
A standard that implementators will not follow and that the designers abhor is
not a standard; it's a death sentence.

As a minor note, the organisation and style of the documents themselves are
terribly confusing and a major departure from r4 and r5. The 'main'
document jumps all over the place conceptually, and the self-reference and
reference to the 'library' doc makes it absolutely incoherent to try to
follow.

It is also disquieting to me how many "implementation responsibilities" and
restrictions are proposed. The tone of the document is vastly different from
almost all other scheme-related literature that I have read. Adding feature
upon feature, restriction upon restriction, is fine for Ada. Scheme is not
and has not been Ada, ever, thankfully, despite both being designed by
committee. How could this happen to 'scheme' now, and how can we call a
feature-laden, over-specified compiler design guide 'scheme' at all?


-elf
Received on Mon Aug 20 2007 - 20:32:20 UTC