-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Full name (required): John David Stone

Location (optional): Grinnell, Iowa, USA

Affiliation (optional): Grinnell College

Contact details (optional): n/a

Statement of interest (not required if you registered for the
R6RS ratification or the 2009 Steering Committee election):

        I teach courses in computer science at a small liberal-arts
college.  We use Scheme in our introductory course because its simplicity
and expressiveness enable our students to understand some of the key ideas
of computer science -- notably recursion, procedural abstraction, and
data abstraction -- quickly and accurately, without the encumbrances of
fragile syntax and quirky semantics.  We also use Scheme in more advanced
courses (such as our courses on programming languages, algorithms, automata
theory, and computational linguistics), particularly for small,
specialized examples and demonstrations.

Vote (required): no

Rationale (optional):

        In the R6RS ratification vote in 2007, I made my decision by
considering whether the R6RS proposal was a substantial improvement over
R5RS.  This time, however, the question is quite different, since the R7RS
proposal is offered more as an alternative to R6RS than as a successor to
it.  So my approach this time is to make head-to-head comparisons of R6RS
and the proposed R7RS:  Which one would I rather use in teaching computer
science to undergraduates?  Which set of features -- the R6RS extensions,
or the proposed R7RS changes -- are more useful?  Which would be more
difficult to replace with home-grown substitutes?

        Although I tried to judge both R6RS and the R7RS proposal on their
merits, R6RS (as I see it) has earned a considerable head start.  Like many
Scheme teachers, I've already written a substantial amount of
R6RS-conformant code (see http://www.cs.grinnell.edu/~stone/afp-code/ for a
large sample of it).  Indeed, I've already _re_-written a fair amount of
R5RS code into R6RS for my classes, and adapted some of my teaching
practices to features that were added in R6RS (such as libraries and
Unicode support).  To the extent that the R7RS proposal backtracks to R5RS
and then goes off in a different direction from R6RS, it seems to me that
it is inevitably starting at a disadvantage.

        This is not a criticism of Working Group 1, which in my opinion has
fulfilled its charge reasonably well.  I think that the charge itself
incurs this disadvantage.

        In all, I considered about thirty head-to-head comparisons between
features of R6RS and features of the R7RS proposal, but I'll focus on seven
that seem especially significant for teaching:

        (1) Libraries.  In courses for Scheme novices, I wouldn't try to
cover R6RS phases and import-export levels, because we wouldn't be dealing
with any complicated macros.  My students would see almost exactly the same
subset of the constructions relating to libraries, importing, and exporting
under either R6RS or the proposed R7RS.

        There is one significant difference, however: versions.  Under
R6RS, I have the option of teaching students how versioning of libraries
works; under the proposed R7RS, there would be no language support for that
topic.

        (Also, looking ahead, I can foresee that the decision in the R7RS
proposal to reserve the library name (scheme base) is going to cause
problems for R8RS and the next transition.)

        (2) Records.  Scheme beginners will find it a lot easier to read
and understand section 5.5 of the proposed R7RS than section 6 of the R6RS
"Standard libraries" document, so R7RS has an edge here.  In practice, I
think that students would find the two kinds of records about equally easy
to use.

        (3) Exceptions.  R6RS exceptions are more complicated than
exceptions under the proposed R7RS, because they can't be understood
without conditions, but this doesn't strike me as a very heavy imposition
on teachers and students.

        The R7RS proposal doesn't include assertions.  This creates a
needless divergence from R6RS, where the assert syntax is required in
the base.  One could argue that assertions are an unsuitably blunt
instrument for error detection and reporting.  Even so, they are useful
enough as a teaching tool that I'd like the language to support them.

        (4) Parameters and dynamic environments.  I suppose that it's
better to have this topic up front and readily discussable, as part of the
proposed R7RS core language, than to have it lurking in the background, as
in R6RS, to emerge unexpectedly at some not-very-teachable moment.  I'm not
really looking forward to teaching this part of the language to beginners
either under R6RS or under the R7RS proposal.  I can evade my
responsibility more easily under R6RS, or face it with better language
support under the R7RS proposal.

        (5) Unicode.  The proposed R7RS doesn't require Unicode, so several
of the R6RS programs that I've written would have to be extensively revised
in order to be portable under the R7RS proposal.  I really don't want to
have to go back to seven-bit ASCII for strings and symbols.

        Here's a typical example: Some of the libraries I've written this
semester deal with formulas of the propositional calculus as data.  I know
from past experience that using the symbols 'and, 'or, and 'not in those
data, as conjunction, disjunction, and negation signs, confuses students.
So I don't use those symbols; I use the logicians' symbols at codepoints
2227, 2228, and 00AC instead.  This saves me from having to think up some
misspelling or Esperanto equivalent of "and" just to be able to render the
datum without misleading readers.

        (6) The include and include-ci syntaxes and the load procedure.
These don't belong in Scheme.  They undermine the model of modular design
and construction of programs that the library system so carefully promotes.
Even if I never mention them, students will find out about them, use them
inappropriately, and promptly confuse themselves and their lab partners.
Advantage R6RS.

        (7) R6RS provides libraries for hash tables and bitwise operators
- -- very good!  Its (rnrs lists) library standardizes the names and
interfaces of some very important higher-order procedures -- for-all,
exists, filter, fold-left, fold-right -- while the proposed R7RS doesn't
support any of these.  Of course, we teachers can always write our own
libraries to support them, as apparently we're going to have to continue to
do for random-number generation.  My guess is that the implementers will do
at least as good a job.

        On the other hand, the proposed R7RS specifies at least one useful
library that R6RS doesn't have, namely (scheme time).  Alas, since
libraries other than (scheme base) are optional under the R7RS proposal, a
portable R7RS program couldn't rely on (scheme time) anyway.

        To sum up:  R6RS is, on the whole, a somewhat better language for
teaching undergraduates than the proposed R7RS.  I conclude that adopting
the proposal and displacing R6RS would not be in the best interest of my
segment of the Scheme community.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAlF6+rUACgkQbBGsCPR0ElSORQCfQfU3dLUDE6s3dc3jTRPCxkt/
ldkAoNOk6T5HlCz64M4ZWrlkhokIGzyc
=W5o6
-----END PGP SIGNATURE-----

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports