Live data from Hacker News

List out of Lambda

stevelosh.com

21–30 of 49 posts

Re: List out of Lambda

#21

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.

If you're soft real-time so that performance is a correctness issue you need more than Turing-completeness. I don't know off the top of my head if there's a name for a constant-slowdown universal computer or if such a thing is possible.

Re: List out of Lambda

#22

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.

"some measure of support" like a way of interacting with the outside world. The pure SKI calculus is Turing complete, but no amount of library code (also written in the pure SKI calculus) or syntactic sugar for expressing your favorite paradigm will let you write cat(1) in it.

Re: List out of Lambda

#23
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.

Re: List out of Lambda

#24
post #18

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.

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

Not everyone is used to read that math notation. Is like say: "Why put it in JS instead of assembler?". JS is probably the most universal language out there (at least in terms of widespread).

I prefer this stuff in python. Less syntax, more clear. But then, is the same thing: You imagine your (math) syntax is better, I think is python, somebody will complain why not haskell, but js is more practical. Or, is just the one the OP like. That is probably the only and best reason.

Re: List out of Lambda

#25
post #18

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.

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

In current Firefox nightlies (and soon everywhere (i.e. Firefox AND Chrome)) it's just:

    x => f => f(x)
http://wiki.ecmascript.org/doku.php?id=harmony:arrow_functio...

Re: List out of Lambda

#26
post #23

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

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.

Re: List out of Lambda

#27
post #23

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

This celebrated discussion goes into some nice detail about object-closure equivalence:

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

If you're too impatient, here's the punchline:

  The venerable master Qc Na was walking with his student, Anton.  Hoping to
  prompt the master into a discussion, Anton said "Master, I have heard that
  objects are a very good thing - is this true?"  Qc Na looked pityingly at
  his student and replied, "Foolish pupil - objects are merely a poor man's
  closures."

    Chastised, Anton took his leave from his master and returned to his cell,
  intent on studying closures.  He carefully read the entire "Lambda: The
  Ultimate..." series of papers and its cousins, and implemented a small
  Scheme interpreter with a closure-based object system.  He learned much, and
  looked forward to informing his master of his progress.

    On his next walk with Qc Na, Anton attempted to impress his master by
  saying "Master, I have diligently studied the matter, and now understand
  that objects are truly a poor man's closures."  Qc Na responded by hitting
  Anton with his stick, saying "When will you learn? Closures are a poor man's
  object."  At that moment, Anton became enlightened.

Re: List out of Lambda

#28
post #24

Earlier quoted context omitted.

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

Not everyone is used to read that math notation. Is like say: "Why put it in JS instead of assembler?". JS is probably the most universal language out there (at least in terms of widespread). I prefer this stuff in python. Less syntax, more clear. But then, is the same thing: You imagine your (math) syntax is better, I think is python, somebody will complain why not haskell, but js is more practical. Or, is just the…

> Not everyone is used to read that math notation.

Agreed, but it doesn't take more than a couple of sentences to describe the entire syntax of the λ-calculus. It's not hard to pick it up even if you've never encountered it before.

Contrast that with JavaScript, where even as someone who has written my fair share of it, my eyes tend to glaze over when they hit a string of `});}))());};`. Yet people happily write that sort of thing, then turn around and complain about nested parentheses in Lisp!

Re: List out of Lambda

#30
post #19
post #2

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.

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.

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.

Post reply on HN