Lambda: the Ultimate Design Flaw

[Daniel Silva]

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/p...il/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 misunderstandin g
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]

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/p...il/008382.html

April Fool's Day again, eh?

--
Erik Max Francis && ma*@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]

Daniel Silva wrote:

At*any*rate,*FO LD*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]

Daniel Silva wrote:

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 drop LAMBDA?

Why not? Isn't all code eventually anonymous and relocatable?

[Torsten Bronger]

Hallöchen!

Daniel Silva <ds****@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/p...il/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?th read=98196>.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Jeremy Bowers]

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/p...il/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]

Jeremy Bowers wrote:

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.pytho n 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

[François Pinard]

[Sunnan]

[...] for Pythons ideal of having one canonical, explicit way to
program.

No doubt it once was true, but I guess this ideal has been abandoned a
few years ago.

My honest feeling is that it would be a mis-representation of Python,
assertng today that this is still one of the Python's ideals.

--
François Pinard http://pinard.progiciels-bpi.ca

[Joe Marshall]

Jeremy Bowers <je**@jerf.or g> writes:

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/p...il/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.