The { and } around the || make it pretty clear the || is not a boolean. Also  you can put a space in {| |}. But mainly, as with any alternative bracketing system that uses an infix operator, we are relying on the leading { to make it clear that the immediately following delimiter, | in the proposal, cannot represent its usual infix role (| or ||).

/be

January 13, 2012 1:11 PM


yes, i had the same impression [thx to those who supplied code examples].

one problem i came across in this domain is that a block lambda with no arguments is visually identical to a boolean or ['||']. context, i believe, will clarify this; but from a purely visual perspective, two adjacent pipe characters are almost archetypal for the boolean or operator [if i can speak about archetypes in computer programming].

January 13, 2012 12:36 PM
FWIW, After working through the example gists that I created last night, my opinion changed about the look of Block Lambda's with pipes. As others on the list have said previously and is now very clear to me, pipes provide a very distinct visual cue "this is a block lambda, expect X to happen here" where the {(args) expr } gets lost; these visual cues are important when you're reading and writing "real world" programs in _javascript_.


Rick




 



_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
January 13, 2012 10:51 AM



I've updated a version of my ES.next Smalltalk collections implementation experiment to use block lambdas.

As you might expect, this new version is even closer in form to the original Smalltalk code.
In particularly, I was able to eliminate all the artifacts that needed to be introduced because of function expressions  don't have Tennent's Correspondence. 
In the source, I've tagged the lines where TCP is using /*TCP*/

Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
January 13, 2012 6:09 AM
hello world!



i think this would be very helpful too [although, sadly, since i am overcommitted as it is, it will not be me].

January 12, 2012 6:09 PM
On Jan 12, 2012, at 2:23 PM, François REMY wrote:

If not (as it seems to me), it means that a block lambda will not be used as a statement by itself. If it's the case, it should defined as an _expression_ only, where there's no anonymous block to conflict the syntax. That solution has been chosen for object notation in the past. That way,

  function() {
      {
          (a, b)
          a.add(b)
      }
  }

would still be an anonymous block where

  function() {
      asyncAction(..., { (a, b) a.add(b); } }
  }

would be a block lambda as an argument of an async function. No semantic change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!

I must say, the parens look much prettier to me, and they're of course more consistent with JS precedent.

It does help to write a reasonable chunk of code to compare syntaxes for uses of a feature "in the wild." Does some enterprising es-discusser wanna take a big JS program with a bunch of little anonymous functions, swap them out with block lambdas, and make two gists with the two different syntaxes? That'd be super helpful.

And since I still continue to hope we'll ditch the unprefixed anonymous block in some future revision of ES, that very small edge case could vanish at the same time.
I don't understand what you're referring to here -- what do you mean by "unprefixed anonymous block?"

Does it seems possible/acceptable?
Lovely.

Dave

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to