[plt-scheme] upcoming change in PLT Scheme v300

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