
List out of Lambda - motter
http://stevelosh.com/blog/2013/03/list-out-of-lambda
======
TeeWEE
For people who are interested. The theoretical foundations for this is lambda-
calculus created by Alonso Church.

Encoding integers with lambda is called the curch encoding:
<http://en.wikipedia.org/wiki/Church_numerals>

Functional programming in general is built upon the foundations laid out by
him.

Actually the domainname of hackernews (ycombinator) has a lot todo with lambda
calculus.

~~~
kenko
Losh doesn't use Church numerals, though, he represents numbers as lists. The
fact that lists are also represented as functions is a diversion; his number
three doesn't represent a function f -> x -> x that returns the threefold
composition of its first argument applied to its second.

~~~
ufo
I didn't get too much into the original article but my impression is that he
is using Scot encoding (essentially a 1-to1 translation of pattern matching)
instead of church encoding (somethign equivalent to folds).

Scott encoding doesn't get much publicity but its perfectly valid and much
more intuitive, IMO.

~~~
tome
Also this encoding is cool:

[http://okmij.org/ftp/tagless-final/course/Boehm-
Berarducci.h...](http://okmij.org/ftp/tagless-final/course/Boehm-
Berarducci.html)

------
GhotiFish

       "If you ignore the practical issues of computers like size, weight, cost, heat, 
        and so on, what do you really need in a programming language?"
    

One instruction

<https://en.wikipedia.org/wiki/One_instruction_set_computer>

~~~
smosher
You could have run with a one-point basis:
[https://en.wikipedia.org/wiki/Combinatory_logic#One-
point_ba...](https://en.wikipedia.org/wiki/Combinatory_logic#One-point_basis)

------
Millennium
Turing-completeness, of course. After that, it's all a matter of allowing you
to stay as focused as possible on the task at hand: some reasonable way to
express your chosen paradigm, library support for things ancillary to your
actual task, and some measure of support in the tools you find useful.

~~~
sfvisser
> Turing-completeness, of course.

Lots of useful programs can be written without turing completeness. It can be
useful, but only for a limited problem domain.

~~~
peter-fogg
It actually can have some benefits -- a language without any unbounded loops
or recursion isn't Turing-complete, but you do get a static guarantee of
termination. NASA, for example, writes much of their C code only with bounded
recursion. So they can't compute some things, but they can be sure that the
Mars lander never gets stuck in an infinite loop.

~~~
arianvanp
have you got any sources telling about this? I can't seem to find any. Would
be a nice read

~~~
Bjartr
Here's the official NASA JPL C coding standard

<http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf>

Page 10 describes loop bounds and recursion limitations.

------
Cushman
It's always cool to see an accessible demo of the lambda calculus, but to
nitpick... Isn't it cheating a bit to say this doesn't use Object when, in
JavaScript, the persistent _arguments_ object exists and is even explicitly
accessible? You're just hiding Object instantiation behind function calls, and
using syntactic sugar to access the local object.

I'm not totally sold that objects are a "bigger" language feature than
closures, conceptually.

~~~
aethertap
I'm having to reach back into the dustbin of my mind, but I seem to recall
implementing an object system using only closures at one point. As I recall,
it had all of the "normal" features of objects - inheritance, member
variables, methods, etc. It was done with closures and the members were
accessed in a message-passing style (in scheme, (myobject 'show) for example).

Based on that, I think that closures and objects are probably equivalent in
their expressive ability. Could be wrong though, like I said it was a long
time ago.

~~~
acjohnson55
Inheritance can be a bit tricky to fit in, as I recall, but it's quite elegant
to implement basic classes and objects with just closures.

~~~
pjscott
A very simple and elegant way to handle inheritance is to give each object a
pointer to another object -- let's call it "prototype" -- and delegate any
failed member variable or method lookups to the prototype. This is how
JavaScript's object system works.

------
mjt0229
It's better to think of map without thinking of looping. I think its a good
idea to think of it as converting a container of A to a container of B. It
doesn't matter how it happens, and the container might be empty, or only big
enough only to hold 1 item. Loop is beside the point.

------
McUsr
Seriously, what I need in a programming language depends on what I intend to
achieve with it.

I use blocks in Objective-C and "closures" in Applescript.

    
    
        to lambda(aStatment)
        	script intern
        		say aStatment
        	end script
        end lambda
        set a to lambda("applescript…")
        set b to lambda("knows how to …")
        set c to lambda("make a closure if not a lambda…")
        tell a to run
        tell b to run
        tell c to run

------
tardigrade
Solid intro into the lambda calculus. Wasn't so into the js examples, but
after reading the other comments, I can totally see how a
functional/mathematical syntax would have been very disorienting for someone
not familiar with the lambda calc. Since those people are obviously the target
audience, js seems fitting.

------
cycomachead
Having used scheme before, and gone through some of SICP, it was neat to see
the topic expressed in JS. I think it came through fine, though I'll always
have a love for Scheme!

------
tapichu
I'm a bit turned off by the syntax, but lambda calculus is always fun

------
justatdotin
great read, thanks for sharing.

------
fyi80
I get that JavaScript is a popular language, but burying a fundamental concept
under a cluttered and confusing syntax like JavaScript, when it's much cleaner
to explain the math using sensibly notation.

Ugh. It's nice that Steve is reaching down to his audience, but it would be
nice for the audience to step out of their muddy sandbox once in a while.

~~~
tmhedberg
Agreed. I can't understand how something like

    
    
        function(x) {return function(f) {return f(x);};}
    

can be considered easier to comprehend than

    
    
        λx. λf. f x

~~~
munificent
The grouping of expressions is clearer to many readers in the JS example.
Unless you've spent a decent amount of time grokking the lambda calculus, the
second line could be any of:

    
    
        (λx. (λf. f)) x
        (λx. (λf. f) x)
        (λx. (λf. f x))
    

The lambda calculus notation is weird. Using "." to separate parameter and
body is unusual. The scope of the body isn't obvious.

JS is painfully verbose, but it's a verbose syntax _many_ people have already
put the time in to internalize.

~~~
tome
Put the brackets in the lambda syntax then. It would be unambiguous and still
clearer than the Javascript syntax.

