[plt-scheme] upcoming change in PLT Scheme v300

Is it just me, or did this message get sent a few hours early?

-----Original Message-----
From: plt-scheme-admin at list.cs.brown.edu
[mailto:plt-scheme-admin at list.cs.brown.edu] On Behalf Of Shriram
Krishnamurthi
Sent: Thursday, March 31, 2005 9:11 PM
To: plt-scheme at list.cs.brown.edu
Subject: [plt-scheme] upcoming change in PLT Scheme v300


  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

		The Fate Of LAMBDA in PLT Scheme v300
				  or
		   Lambda the Ultimate Design Flaw

About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp hackers who
missed them from their past experience.  To this collection, Scheme added a
lexically-scoped, properly-functioning LAMBDA.  But, despite of the PR value
of anything with Guy Steele's name associated with it, we think these
features should be cut from PLT Scheme v300.

We think dropping FILTER and MAP is pretty uncontroversial; (filter P
S) is almost always written clearer as a DO loop (plus the LAMBDA is slower
than the loop).  Even more so for (map F S).  In all cases, writing the
equivalent imperative program is clearly beneficial.

Why drop LAMBDA?  Most Scheme users are unfamiliar with Alonzo Church
(indeed, they don't even know that he was related to Guy Steele), so the
name is confusing; also, there is a widespread misunderstanding that LAMBDA
can do things that a nested function can't -- we still recall Dan Friedman's
Aha! after we showed him that there was no difference!  (However, he appears
to have since lapsed in his ways.) Even with a better name, we think having
the two choices side-by-side just requires programmers to think about their
program; not having the choice streamlines the thought process, and Scheme
is designed from the ground up to, as much as possible, keep programmers
from thinking at all.

So now FOLD.  This is actually the one we've always hated most, because,
apart from a few examples involving + or *, almost every time we see a FOLD
call with a non-trivial function argument, we have to grab pen and paper and
imagine the *result* of a function flowing back in as the *argument* to a
function.  Plus, there are *more* arguments coming in on the side!  This is
all absurdly complicated.  Because almost all the examples of FOLD we found
in practice could be written as a simple loop with an accumulator, this
style should be preferred, perhaps with us providing a simple helper
function to abstract away the boilerplate code.  At any rate, FOLD must
fold.

--The PLT Scheme Team