[plt-scheme] upcoming change in PLT Scheme v300

He's posted from his Gmail account before.  If not here, at least on
the LL1 list.

Daniel

On Apr 1, 2005 12:42 AM, Corey Sweeney <corey.sweeney at gmail.com> wrote:
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> wait a second.  That came from shriram at gmail.com  shrirams email
> address is sk at cs.brown.edu.
> 
> Corey
> 
> On Mar 31, 2005 11:10 PM, Shriram Krishnamurthi <shriram at gmail.com> wrote:
> >   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
> >
> >
> 
>