Fold Must Fold!

The Fate Of LAMBDA in PLT Scheme v300
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

This from the PLT Scheme mailing list. Clearly Guido's visionary thinking is having repercussions outside the world of Python. I, for one, welcome this change that can only benefit the Scheme language.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Way to go!

While at that, cant we also remove this pesky TCO requirement, and add more nice Shift+digit symbols to the syntax?

We have a quorum!

Anton already requested the removal of proper tail recursion. Clearly this shows that a majority of users are in favor. The Scheme community better listen, or else they'll end up losing market share to better-designed languages like Java and C++.

Is abstraction too abstract?

That version of the thread is on ll-discuss, for anyone who wants to follow this breaking news in all possible venues. Someone also thoughtfully cross-posted the original announcement to c.l.scheme, c.l.python, and c.l.functional. With this kind of dissemination, we'll be rid of all these warts on the language landscape in no time! Lambda — what were we thinking?

It's amazing how the differen

It's amazing how the different threads all seem to converge, independently, to the same ideas. On PLT, LL1, and the newsgroups, people have all posted about how we should get rid of DEFINE and just have GOTO. I dunno about the others, but I was unaware of the other crossposts when I replied...

Which once again goes to show that all roads lead to Fortran...

XFortran? Semantic Fortran?

I agree wholeheartedly, but we should not forget the lessons learned the hard way... The new, improved Fortran must come with an XML syntax to improve its penetration into the corporate market. No, XML is too old and unfashionable already! What about OWL? Can we DEFINE the semantics of GOTO without falling back to those c-words (contaminations?)?

April the first

This is April the first, isn't it?

Steve Leach (Spice Dev Team)

Not so sir!

It's a post about the removal of lambda and fold from PLT Scheme. Any resemblance to a period of time suggests you are suffering from a severe form of synesthesia!

Let the record show...

It should be known that this article ">was posted on Guido van Rossum's weblog on March 10th.

So, if you're taking this as an April Fool's joke, ummm... you may be in for a surprise. Unless that Guido is even meta-cleverer than we expect.

not unless

you can prove it using RuleML.


You're all a bunch of snobby mathematician-wannabes who wouldn't know a real program if it rose up sharply and kicked you in the groin and your delusions of understanding real programming tools like Python by reduction to the lambda-calculus would be embarrassing enough even without spewing this ridicule onto the people who are using them to write actual programs, people whose lives you perversely want to live vicariously instead of programming yourselves.

Shame on all of you.

April fools!

Frequency of folds

For fun I grep'd some source code on my computer to see how frequently folds are used in various languages. This is very unscientific and based on essentially find ~ -name "*.lisp" | xargs grep ... | wc -l. My regexps might also be bad too so I included them in the table. Here are the results:

language      total LOC      folds    LOC/fold    grep arguments
erlang        1,443,151       1338        1078    -e 'foldl(' -e 'foldr('
scheme          397,470        120        3312    '(fold[lr ]'
common lisp   1,483,287        352        4213    -i -e '(reduce ' -e '(reduce$' -e "#'reduce" -e "(function reduce)"
elisp         1,265,752         15       84383    -e "(reduce " -e "#'reduce" -e "(function reduce)"

Update: Fixed lots of wild inaccuracies and removed incorrect summaries. Interpret at own risk :-)


Theoretically, nothing changed since assembly so I never got what the OO or functional fuss was about anyway. What now is a fold?

I say "Kiss my Turing Machine, PLT."

The name "lambda"

Why drop LAMBDA? Most Scheme users are unfamiliar with Alonzo Church ... so the name is confusing

Would it really be so bad to replace "lambda" w/ "fun"? "proc" might even be better considering pervasiveness of side-effects in scheme. I guess I should be thankful, newbies aren't exposed to "catamorphisms" too

instance SoftFluffyThing IO where...

Many computing terms are needlessly confusing and offputting for newbies.

Clearly what's needed is a focus group, with healthily balanced representation from all ages, classes, genders, creeds and ethnicities, to determine the least exclusionary nomenclature for common computing concepts.

Mature enough now that it needs to be rechristened from...


Or maybe put to catch music

just don't over-achieve:


Ok, I'm definetely dropping PLT-Scheme and Python as some of my fav dev tools!

i think i'm going back to good ol' procedural pascal or C++ perhaps... at least, they don't try to pretend they are highly dynamic, exciting tools...

Other Scheme changes

The new Green Scheme specification requires that objects be recycled rather than sent to the garbage collector. Lists with no references will now be attached to other lists deemed "appropriate" by Randomized Inference (see "Randomized Inference and Form 1040" - Dewey, Cheatham & Howe, et al. - 2005).

The new "head recursion" optimization will speed up functions that call themselves immediately without any prior tests.

The LET function has been under considerable debate in recent years as it is a bit of a misnomer. Any values bound in LET are forced upon the poor, unsuspecting variables who have no say in the matter. You aren't "letting" x = 5, you are forcing x to be 5. From now on, however, variables in a LET function are permitted to decline the new bindings at their discretion. If a binding must be guaranteed, you can use the FORCE function, which has the same semantics as the old LET, but you must first submit a request in triplicate to Guy Steele before using FORCE in a function.

Finally, after numerous complaints about so many parentheses, Scheme will introduce a new syntax where s-exprs are delimted by special tags enclosed in <>'s, with a special /> notation for the end of a list. For example:

<define><foo bar baz/><when><= bar baz/><display>"Yes"</display></when></define>

come now, not proper syntax

Really now, how can you call this a usable language, it doesn't even begin to leverage the expressiveness and flexibility of the data model.

  <binding-declarations scope="lexical">
    <binding symbol="foo" />
    <binding symbol="bar" />
    <binding symbol="baz" />
    <condition type="equality">
	<argument><retrieve-binding symbol="foo" /></argument>
	<argument><retrieve-binding symbol="bar" /></argument>
	<stream id="output" type="device">
	  <device-binding "devices://output/standard" />
	<stream-write stream="output">Yes</stream-write>

That's more like it.


The angle brackets cause my eyes to burn
First left, then right they want my head to turn
In verbose pairs of tags my data rest
Yet I still think parentheses the best


see what Dave Moon has in mind (search for Dave Moon: Arc Syntax)

Another suggestion

Down with FUNARGS, I say!
Paul Steckler