Newsgroups: comp.lang.scheme
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: bh@anarres.berkeley.EDU (Brian Harvey)
Subject: EdScheme
Message-ID: <9106041329.AA02962@anarres.Berkeley.EDU>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Date: 4 Jun 91 13:29:26 GMT
Lines: 61

The people who wrote EdScheme (assuming we're talking about the same
thing--this one is from Florida) also wrote a book, _The_Schemer's_Guide_,
meant to introduce Scheme in precollege education.  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).
	  Despite the new compatibility mode, many issues are not
	  addressed.  Among these:

		+ lower and upper case distinguished in symbols
		+ delay doesn't memoize
		+ many missing essential procedures:
			eqv? append memq assq max min complex? (and other
			numeric type predicates; note that these are
			required even if the types are not supported)
			abs char? string-length procedure? map
			cadr (and cddr and friends)
		    (maybe more; I didn't try everything)
		+ 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 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.

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