Expression closures - use-cases for shortcut lambda syntax (blocks)

Vassily Gavrilyak gavrilyak at gmail.com
Fri Mar 16 14:17:08 PDT 2007


Brendan: No, I didn't meant \(, I meant exactly (\
It looks like lambda, reads nicely and works good with current lexers (at
least for our code base with SpiderMonkey and MTASC)
All we did in jsscan.c is
      case '(':
        if (MatchChar(ts, '\\')) {
         UngetChar(ts,'(');
         tt = TOK_FUNCTION;
         tp->t_op=JSOP_NOP;
        } else {
         tt = TOK_LP
        }

Next about readability. My primary concern IS exactly readability, I never
mind typing additional characters.
But  I want to clearly show the intent in my code. I want to see word
'function' when it means exactly function.
And I want to read 'block'  when it means block.
so
function someFunction(){               // this is a FUNCTION
  using(File("hello". "r"), (\ file){     // this is a block that uses file.
       process(file);
  }) // file will be closed here.
}
We would be probably happier with clearer syntax (without \ and some
parenteses) but such "feature" can break
old code and introduce corner cases.

For me even using word 'block' will be good, but why we need more keywords
if we can do without them.

About C/C++/Java background. Well, everybody in our team has exactly this
background.
We dumped  all those 3 'bigs' in favor  of JS and never looked  back  since.

And everybody accepted the proposal to hack the lexers only to show the
clear intent in the code, so everybody will understand what's going on.
And we did it cause we have a lot of above provided use-cases in our code
(web and game development).
That was hard decision, cause nobody want to maintain foreign code base and
apply diffs with every version. But we did it and  now we are using
Spidermonkeys eval/uneval trick just to make legacy browsers be happy with
our code.
That's the only 'fork' we did, cause JS is just 'right' for us. We do not
want operators, overloading, multiply inheritance and any other 'cool' staff
(And that's with C++ background :-) ). But we need to write async code, use
non-GC resources and do transactions in database all the time. Java-way is
too complex and error prone here (from our past experience).

About project policy. Adobe project policy probably should disallow lambda
and use OO.
Our project policy disallowed  AS2 OO-extensions and favored lambda.
People are just different and projects are different and  that's ok.
Language should provide mechanism, not policy.  That's why JS won for  us.


Now, not everybody has C/C++ background. Ruby and Perl developers will be
just HAPPY with block syntax.
Ruby is success because of Rails. Please look at Rails examples and count
number of usage of blocks here.
Lots of Java/C# people escaped to Ruby (sadly, not to JS)  and are just
happy.
There are rumors that all ex-Perl hackers are becoming JS-hackers right now
and found a good language.
C# coders will follow shortly. They have using(resource) {} now and will
have blocks in 3.0.
Scala  have only one behavior pattern -  'loan', that looks exactly like
first thow use-cases for resource and
transaction management.

Maybe we can emulate some other language here, e.g Ruby with '|' instead of
\.
For us Haskell's lambda is nice enough.


To conclude:
-Proposal is about clarity, not terseness, please do not accept it as 'just
to save 6 keystrokes'
-Not everybody has C/C++/Java background. Lot of people have Perl, Ruby, PHP
background.
-Blocks with proposed syntax are simple to implement and do not break
current code.
-Provided use-cases are widespread in web-programming and are currently hard
to write and read clearly in ES3.
Blocks can fix this.

Thanks for all interested
Regards,
Vassily Gavrilyak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20070316/1a3b7019/attachment-0002.html 


More information about the Es4-discuss mailing list