[Sorry to have taken so long for this reply...]
Erik Naggum <firstname.lastname@example.org> wrote:
| * Rob Warnock
| | Scheme... has had had multi-arg "apply" since at least 1986... R3RS.
| Seriously, though, I have always disliked the separation between
| essential and non-essential procedueres in Scheme, so if it has
| vanished as a whole, I'm as delighted as I can be when I don't like
| Scheme to begin with. If it is only gone for apply, well, it's a
| step in the right direction.
Well, I've got some good news, and some bad news... ;-}
IEEE Standard Scheme  did indeed erase the "essential/non-essential"
distinction completely, but... as of R5RS "it's BAAAAaaaack", in the form
of "primitive", "library", and "optional" syntax & procedures:
The report is now a superset of the IEEE standard for Scheme [so]...
The classification of features as essential or inessential has
been removed. There are now three classes of built-in procedures:
primitive, library, and optional. The optional procedures are
load, with-input-from-file, with-output-to-file, transcript-on,
transcript-off, and interaction-environment, and - and / with
more than two arguments. None of these are in the IEEE standard.
One might reasonably question "load" being optional, but since "eval" is
now required [since everything in R5RS that is not "optional" is required],
"load" can be synthesized from other primitives.
Likewise, "with-input-from-file" & "with-output-to-file" can be emulated
with wrappers [and in any event are dangerous in the presence of errors,
since R5RS makes no guarantees about file closure on error -- "If an
escape procedure is used to escape from the continuation of these
procedures, their behavior is implementation dependent" -- whereas in
one's own implementation one can at least choose the desired behavior,
using "dynamic-wind" (except: see last item below!)].
As for the primitive/library distinction:
1.3.1 Primitive, library, and optional features
To aid in understanding and implementing Scheme, some features
are marked as library. These can be easily implemented in terms
of the other, primitive, features. They are redundant in the
strict sense of the word, but they capture common patterns of
usage, and are therefore provided as convenient abbreviations.
Since R5RS has "syntax-rules"-style hygenic macros as a required
primitive feature, macros can be used to implement such "library
syntax" as cond/case/and/or/let/let*/letrec/begin/do/delay, &c.
Finally, as mentioned above, "dynamic-wind" is now required, which at
least sets the stage for decent exception handling, but unfortunately
errors are *not* yet specified in terms of callinng a [top-level]
continuation, so there's still no guarantee that an error will even
invoke the "out" limb of a "dynamic-wind" at all!! (*sigh*)
Rob Warnock, 31-2-510 email@example.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043