Lambda: the Ultimate Design Flaw
Daniel Silva
be of interest to c.l.s, c.l.f, and c.l.p:
http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html
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
Erik Max Francis
> Shriram Krishnamurthi has just announced the following elsewhere; it might
> be of interest to c.l.s, c.l.f, and c.l.p:
> http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html
April Fool's Day again, eh?
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
If you can't fight and you can't flee, flow.
-- Robert Elliot
alex goldman
> At any rate, FOLD must fold.
I personally think GOTO was unduly criticized by Dijkstra. With the benefit
of hindsight, we can see that giving up GOTO in favor of other primitives
failed to solve the decades-old software crisis.
Sunnan
> 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.
How about using srfi-42 instead of those nasty do loops?
It's pretty clean:
(list-ec (: a lis) (* a a))
is equivalent to
(map (lambda (a) (* a a)) lis)
Before I discovered srfi-42, my code often had hideous things like:
(append-map
(lambda (item)
(map
(lambda
(inner)
(* inner inner))
(cdr item)))
lis)
to return (1 4 9 16 25 36 49 64 81) for
a lis that's '((a 1 2 3) (b 4 5 6) (c 7 8 9))).
This becomes even neater:
(list-ec
(: item lis)
(: inner (cdr item))
(* inner inner))
Have a happy first of april!
Hans Oesterholt-Dijkema
> The Fate Of LAMBDA in PLT Scheme v300
> or
> Lambda the Ultimate Design Flaw
>
Why not? Isn't all code eventually anonymous and relocatable?
Torsten Bronger
Daniel Silva <dsi...@ccs.neu.edu> writes:
> Shriram Krishnamurthi has just announced the following elsewhere; it might
> be of interest to c.l.s, c.l.f, and c.l.p:
> http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html
>
>
> 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.
>
> [...]
The whole text seems to be a variant of
<http://www.artima.com/weblogs/viewpost.jsp?thread=98196>.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jeremy Bowers
> Daniel Silva wrote:
>
>> Shriram Krishnamurthi has just announced the following elsewhere; it might
>> be of interest to c.l.s, c.l.f, and c.l.p:
>> http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html
>
> April Fool's Day again, eh?
Yes and no. In the Python community, we're taking all of that pretty
seriously. The scheme community may not seriously be thinking of getting
rid of those things, but it's hardly impossible that some people think it
might be better off without it.
Sunnan
> Yes and no. In the Python community, we're taking all of that pretty
> seriously. The scheme community may not seriously be thinking of getting
> rid of those things, but it's hardly impossible that some people think it
> might be better off without it.
Lambda is a primitive in Scheme; in some implementations of scheme it's
used to implement things like temporary variables (let), sequences
(begin) and looping (named let/letrec).
Python has other ways of doing these things; and removing things that
has been obsoleted or superfluous makes sense, for Pythons ideal of
having one canonical, explicit way to program.
Having a few very abstract primitives that the rest of the language can
theoretically be built upon is one of the reasons why Scheme/Lisp can
work as a programmable programming language.
Scheme is like Go - a few abstract rules that can be combined in
endless, sprawling ways.
Python is like (hmm, better let some pythonista answer this. I'm
thinking of a game with a clear thematical connection (like Monopoly or
The Creature that Ate Sheboygan) and a few explicit rules that combine
in ways that is supposed to have a clear, readable, consistent result).
Maybe shogi?
(I don't usually read comp.lang.python and I really don't want to offend
anyone. My apologies if this post is either annoyingly obvious (and thus
contains only stuff that's been said a million times), or totally wrong.)
Sunnan
Joe Marshall
> On Thu, 31 Mar 2005 23:30:42 -0800, Erik Max Francis wrote:
>
>> Daniel Silva wrote:
>>
>>> Shriram Krishnamurthi has just announced the following elsewhere; it might
>>> be of interest to c.l.s, c.l.f, and c.l.p:
>>> http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html
>>
>> April Fool's Day again, eh?
>
> Yes and no. In the Python community, we're taking all of that pretty
> seriously.
The Python community takes many things pretty seriously. Whitespace
and Guido come to mind.
Brian Harvey
> 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.
This part isn't funny. I have a couple of colleagues who like to write
everything in the world as a FOLD call, and it gives me a headache.
Sunnan
Fold might be an acquired taste.
When I first found fold and friends in srfi-1, I went "yay! seems like a
way to remove plenty of lines from code" but even after that initial
joy, I had to go through a headache-inducing grokking session.
I don't use fold very much, but I think it's super cool.
The main thing that made me stick with scheme is that I hate
"boilerplate text", needless typing repetitions of forms and patterns.
fold abstracts a list recursion.
Adrian Kubala
Fold is better than general recursion because it provably terminates (on
finite lists anyways), and it's not any harder to understand once you
get used to it.
Ulrich Hobelmann
The fault of goto in imperative languages is that it has no
arguments, thus creating spaghetti of gotos and assignments.
Continuations rule!
Tom Breton
[...]
> 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.
Couldn't you leave it in for just another month? And during the
remaining month, we'll just call it the "APRIL FOLD".
--
Tom Breton, the calm-eyed visionary
Artie Gold
--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays
alex goldman
> Torsten Bronger wrote:
>> Hallöchen!
>>
>> Daniel Silva <dsi...@ccs.neu.edu> writes:
>>
>>
>>>Shriram Krishnamurthi has just announced the following elsewhere; it
>>>might be of interest to c.l.s, c.l.f, and c.l.p:
>>>http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html
>>>
>>>
>>> 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.
>>>
>>>[...]
>>
>>
>> The whole text seems to be a variant of
>> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>.
>>
>> Tschö,
>> Torsten.
>>
> Ya think? ;-)
>
> --ag
>
Wow, the original is much funnier than the "joke"! (Because it's meant
seriously)
"plus the lambda is slower than the list comprehension" - ROTFL!
Sunnan
> Torsten Bronger wrote:
>> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>.
>>
>> Tschö,
>> Torsten.
>>
> Ya think? ;-)
Heh. I was glad that Torsten pointed it out; I didn't get what was funny
about the joke until then.
T.D. Lassagne
sun...@handgranat.org says...
Please consider joining the International Sarcasm Society. Our motto is
"Like We Need YOUR Support".
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Sunnan
> Please consider joining the International Sarcasm Society. Our motto is
> "Like We Need YOUR Support".
I *recognize* sarcasm; I just don't think it's very funny. Now parody,
which this turned out to be, I can appreciate.
Frank Wilde
> alex goldman wrote:
>> I personally think GOTO was unduly criticized by Dijkstra. With the
>> benefit of hindsight, we can see that giving up GOTO in favor of
>> other primitives failed to solve the decades-old software crisis.
> The fault of goto in imperative languages is that it has no
> arguments, thus creating spaghetti of gotos and assignments.
>
> Continuations rule!
While continuations are a very interesting abstraction, the improvement
of structured programming was to be able to prove properties of your
programs in time linear to the size of the program instead of quadratic.
I don't see how giving arguments to the GOTO would help there.
Ciao,
Perle
Philippa Cowderoy
>> Continuations rule!
>
> While continuations are a very interesting abstraction, the improvement
> of structured programming was to be able to prove properties of your
> programs in time linear to the size of the program instead of quadratic.
> I don't see how giving arguments to the GOTO would help there.
>
By allowing you to build your own control structures, whose properties you
prove once before using them to prove properties in the programs that use
them.
There is no magic bullet. There are, however, plenty of bullets that
magically home in on feet when not used in exactly the right circumstances.