Re: Semantics and abstract syntax of lambdas
On Mon, Dec 8, 2008 at 4:08 AM, Yuh-Ruey Chen maian...@gmail.com wrote:
Jon Zeppieri wrote:
So, unless people want to expand the expression grammar significantly,
I think the expression body is a nonstarter.
How feasible would it be to make JS a pure expression language? That is,
can the language be modified to allow things like:
x = if (a)
b;
else
c;
first_test_prop = for (let p in o)
if (/^test/.test(p)/) {
p; break;
}
There's a simpler way to expand the expression language dramatically.
I'm not sure why so few languages include it, and I'd be curious if it
has been considered for Harmony.
The technique is to include an expression form which contains a
sequence of statements followed by an expression. In Scala, the
syntax looks like this:
{ statement1; statement2; result_expression }
So you can do things like:
{ val x = 1; val y = 2; x+y }
The result would be 3. I'm not sure what the best syntax would be for
JavaScript, but surely there is room somewhere.
A light syntax for this kind of expression would immediately solve the
issue with lambdas that result in expressions. This, in turn,
honestly seems important for lambdas to really be convenient to use.
(Granted, lambdas being convenient is much less important than having
them available at all.)
There are side benefits to this expression form, too. It means you
can much more frequently replace a function call by the function's
contents, even when the function appears in an expression-only
context. For example, you can more frequently inline the g() in
f(g()). This makes programmers more dextrous, because their rewrites
can be more localized. Further, it has obvious application for an
optimizing compiler such as GWT's
-Lex
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 3:19 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
Just to clarify some speculation, the syntax I proposed ({||}) was
solely inspired by Smalltalk and tempered by the parsing realities
of a C-like syntax. Any similarities to Ruby constructs are probably
examples of parallel evolution under similar environmental pressures.
I suspect that designers of other languages with C-like syntax
(C# comes to mind with its () = expr lambda syntax) did not
have the experience or goal of using closures to create control
abstractions (which often requires passing multi-statement closures)
and so arrived at a more function-like concise closure syntax.
I can share some history for the = form. It's disconcerting that
everyone associates it with C#, because they are open about copying
the syntax from Scala. Scala's designer, Martin Odersky, most
definitely had in mind that people could use functions for control
flow, and in fact he treats it as the primary way to do control flow
in Scala. I believe Martin got this syntax most directly from ML's
fn expressions. He noticed that you don't really need the keyword.
The development for ML-Scala-C# actually looks a lot like is
happening in ES discussions. Once a function literal syntax is
available, people really want to use it, and the syntax is pressured
to get shorter and even to get its keyword dropped in favor of
symbols.
On this list, the = form has so far been dismissed due to parsing
concerns. If that's the only reason, let me try and allay that worry
and put that horse back in the race. Scala also has a comma operator,
but it still manages to parse the = syntax. They way it does it is
to initially parse an expression and then, if it sees a =,
reinterpret what it has seen so far as a parameter list. It's an
unusual parsing strategy, but it works well and the issue is
localized.
IMHO, x = x+1 really looks like a function literal, so that's the
color I'd paint the bike shed. I agree with Allen and others, though,
that any version that drops the keyword will make the form more useful
in practice.
-Lex
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Semantics and abstract syntax of lambdas
Lex Spoon wrote:
On Mon, Dec 8, 2008 at 4:08 AM, Yuh-Ruey Chen maian...@gmail.com wrote:
Jon Zeppieri wrote:
So, unless people want to expand the expression grammar significantly,
I think the expression body is a nonstarter.
How feasible would it be to make JS a pure expression language? That is,
can the language be modified to allow things like:
x = if (a)
b;
else
c;
first_test_prop = for (let p in o)
if (/^test/.test(p)/) {
p; break;
}
There's a simpler way to expand the expression language dramatically.
I'm not sure why so few languages include it, and I'd be curious if it
has been considered for Harmony.
The technique is to include an expression form which contains a
sequence of statements followed by an expression. In Scala, the
syntax looks like this:
{ statement1; statement2; result_expression }
So you can do things like:
{ val x = 1; val y = 2; x+y }
The result would be 3. I'm not sure what the best syntax would be for
JavaScript, but surely there is room somewhere.
Unfortunately, { in expression context is taken by the object literal.
However, I think {{ would be feasible. That is, if the parser is in
the expression context, if it encounters two '{' tokens in a row, it
could treat it as you defined above, e.g.
val = {{ val x = 1; val y = 2; x + y }}
A light syntax for this kind of expression would immediately solve the
issue with lambdas that result in expressions. This, in turn,
honestly seems important for lambdas to really be convenient to use.
(Granted, lambdas being convenient is much less important than having
them available at all.)
Do you have an explicit syntax in mind?
I can turn this around and say that with really convenient lambdas,
expressions of the form you discuss would be trivial, e.g.
val = fn { val x = 1; val y = 2; x + y }()
There are side benefits to this expression form, too. It means you
can much more frequently replace a function call by the function's
contents, even when the function appears in an expression-only
context. For example, you can more frequently inline the g() in
f(g()). This makes programmers more dextrous, because their rewrites
can be more localized. Further, it has obvious application for an
optimizing compiler such as GWT's
Very true, and one of the reasons I dislike the distinction between
statements and expressions.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
