Hacker News new | comments | show | ask | jobs | submit login

...glorifying the correspondence principle, which Smalltalk and Lisp had before Ruby...

But Lisp doesn't need two different kinds of lambda (at least neither Common Lisp nor Scheme has anything like that).

I'd be interested to know exactly what about JavaScript forces it to need blocks to obey the CP, when Lisp doesn't need them - I haven't quite wrapped my head around that yet. Is it just the problems with 'return' and 'this'? Could that be fixed by instead adding Common Lisp's 'return-from', and fixing 'this' somehow, instead of by adding blocks?

Well, it does need two kinds of lambda, in a sense. In Lisp, something like with-file would be a macro, which solves the same problem that "blocks" are solving here.

Also, Lisp has (return-from) which lets you do a non-local return by specifying which enclosing function to return from by name.

In Common Lisp, LAMBDA doesn't automatically define a return point; you have to use BLOCK NIL (or some macro (like DO or LOOP) whose expansion includes a BLOCK NIL) in order to be able to use RETURN.

  > (defun foo ()
      (block nil
        (funcall (lambda () (return 3)))
  > (foo)
So the problem is that JavaScript's `function' always creates a return point.

Your example does not make much sense, because you can return-from foo in lambda, without enclosing it in a block.

The solution proposed by OP (distinguishing "lambda" callables from "block" callables) is in my opinion misguided, because it only solves a problem partially, in a confusing way and creates new, unnecessary entities. The return-from mechanism is simpler and more intuitive.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact