haltraet@gondle.idt.unit.no (Hallvard Traetteberg) (06/07/91)
A week ago I posted a request for information about EdScheme, a
scheme implementation for PCs. I refered to an article in BYTE, giving som
technical information about EdScheme. These where partly wrong, which most of
the answers pointed out. Overall the answers gave a very positive impression
of the product (including that of the implementor :-). A summary follows (it
became fairly long, because EdScheme seemed to be a product deserving
attention, especially by teachers):
Product data:
From Terry Kaufman <71020.1774@CompuServe.COM>, the implementor:
[The product brochure] fully describes our products which
include a textbook, "The Schemer's Guide", a teacher's manual, "The
Scheming Teacher's Guide", and the EdScheme software.
EdScheme is currently available on three platforms: IBM, Atari, and
Archimedes. It will be available on the Macintosh this September.
From 70262.630@compuserve.COM (Iain Ferguson):
Schemers Inc also offers an introductory CS text (The Schemer's Guide --
TSG) aimed at the high school, junior college, university freshman market
that uses Scheme as its vehicular language.
Use of memory:
From Terry Kaufman <71020.1774@CompuServe.COM>, the implementor:
[text deleted]
Only on the IBM is memory somewhat limited for garbage collecting due
to the fact that it does not use expanded or extended memory. Note,
however, that the statement in BYTE magazine that only 24K bytes are
available is false. In fact, the garbage collected workspace is 24K
PAIRS and more if the editor is not used. [text deleted] On our other
platforms, the only limitation is the amount of main memory available.
As its name suggests, EdScheme is aimed primarily at the educational
users; therefore, one concern that is very important to us is to keep
the software small enough to be runnable from a floppy disk and with
only a modest amount of memory.
From 70262.630@compuserve.COM (Iain Ferguson):
One of EdScheme's virtues is its runnability from a floppy on
computers that have only modest amounts of memory available.
About the editor/evaluator:
From max@nic.gac.edu (Max Hailperin):
[text deleted] The degree of integration seems to be limited only in that
you can only evaluate something from the editor as part of returning to
scheme read/eval/print loop, as opposed to being able to evaluate something
but stay in the editor. This isn't so terrible, it's the way MIT
Scheme used to work a decade ago and I was pretty comfortable with it
then (though I admit to prefering the current setup).
From Terry Kaufman <71020.1774@CompuServe.COM>, the implementor:
Most of our users point out that one of the most attractive features of
EdScheme is the ease of use of the editor, and how well integrated it
is into the system as a whole.
The language:
From Terry Kaufman <71020.1774@CompuServe.COM>, the implementor:
[text deleted] two modes of operation: an Educational mode and
a Standard Scheme mode. The Educational mode is designed for
use in introductory CS courses since it mirrors what appears in "The
Schemer's Guide" textbook and includes thorough checking of function
arguments. The Standard Scheme mode is faster and corresponds more
closely to the IEEE Standard, and is provided for more advanced
schemers.
From max@nic.gac.edu (Max Hailperin)
My impression was that even with "standard mode" on, it wasn't
exceptionally close to compliant with R^nRS or IEEE standards.
From bh@anarres.berkeley.EDU (Brian Harvey):
[text deleted] I reviewed the book for a potential publisher and reviewed
the software along with it. Here is what I said to them about EdScheme:
Good points:
* printable environments (avoiding circularity problems)
and therefore printable procedures. This is great! It's
a big help in debugging as well as in explaining things.
This is my favorite EdScheme feature.
* Turtle graphics. This should make the language more fun
and more accessible to visual thinkers.
Bad points:
* Incompatibility with R3RS (the Scheme standard document):
[text deleted]
+ lower and upper case distinguished in symbols
+ delay doesn't memoize
+ many missing essential procedures:
eqv? append memq assq max min complex? abs char?
string-length procedure? map cxxr.
+ NOT doesn't accept non-#t/#f args
+ COND doesn't accept one-expression clauses
(COND (3)) should return 3
+ (lambda (a b . args) body) syntax
* Incompatibility with Abelson and Sussman terminology.
Although the standard doesn't say one way or the other,
A&S want (atom? '()) to be true, not false. Also, it would
simplify life if () and #f were the same thing, which is
permitted by the standard. That's controversial, though.
Things I have mixed feelings about:
* The fact that procedures are not a separate type. I think it's
great that procedures are PRINTABLE like lists, but really they
should be atomic (that is, (ATOM? FIRST) should be true), and
you shouldn't be able to modify them with set-car! and so on.
* The red/black stuff. [Things that are meant to represent
executable process are in black; "data" are in red.]
This provides, somewhat artificially,
a way to talk about things like the evaluation of numbers and
quote forms, and that's good. But the cost is that it hides
a key idea, the fact that programs ARE just data. This gets
awkward when the text ends up saying "Scheme blackens the red
FD" and things like that. In practice, 99% of the time, all
that happens is that the user types in black and Scheme types
in red, and I bet many students don't understand the colors
any more deeply than that.
EdScheme for teaching:
From max@nic.gac.edu (Max Hailperin):
[] one quite striking fact is that it color codes its user
interaction, with three seperate (configurable) colors for unevaluated
forms, evaluated forms, and other output (e.g. error messages). This
ties in with the book, where the color distinction is made to make the
substitution model of evaluation make sense even with things like
symbols and lists being substituted in (so you can tell what is
already evaluated and not evaluate it again).
From bh@anarres.berkeley.EDU (Brian Harvey)
[Things I have mixed feelings about:]
* The red/black stuff. [Things that are meant to represent
executable process are in black; "data" are in red.]
This provides, somewhat artificially,
a way to talk about things like the evaluation of numbers and
quote forms, and that's good. But the cost is that it hides
a key idea, the fact that programs ARE just data. This gets
awkward when the text ends up saying "Scheme blackens the red
FD" and things like that. In practice, 99% of the time, all
that happens is that the user types in black and Scheme types
in red, and I bet many students don't understand the colors
any more deeply than that.
From 70262.630@compuserve.COM (Iain Ferguson)
[text deleted] color-coding provides the teacher with a
superlative tool for explaining how it is that Scheme procedures can
input and output other Scheme procedures.
In particular, it enables the teacher to clarify the crucial point that
while the (black) expression '(lambda (x) x)' is NOT a procedure, the
(red) result of evaluating it IS. [text deleted] Armed with a clear and
deep understanding, my ninth grade students (aged 15) manipulate higher
order functions with ease.
As background, Schemers Inc. was formed by some high school teachers
who are trying to change the way CS is taught in the schools. Their
book "The Schemer's Guide" has many strong points, and I would
definitely recommend its consideration for its intended audience; further,
it would even be at home in some post-secondary settings, particularly
those desiring a more gentle introduction than, e.g., Abelson and
Sussman's "Structure and Interpretation of Computer Programs."
--
- hal