Re: Allen's lambda syntax proposal
^ also has a slight resemblance to the greek lambda, which is the reason Haskell uses \. As an aside, the circumflex is actually the precursor to lambda: We end this introduction by telling what seems to be the story how the letter 'λ' was chosen to denote function abstraction. In Principia Mathematica the notation for the function f with f(x) = 2x + 1 is ^ 2x + 1. Church originally intended to use the notation ^ x.2x+1. The typesetter could not position the hat on top of the x and placed it in front of it, resulting in ^x.2x + 1. Then another typesetter changed it into λx.2x + 1. -- H. Barendregt, The Impact of the Lambda Calculus In Logic and Computer Science [1] Dave [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.7908 ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Origins of lambda notation (was: Allen's lambda syntax proposal)
Dave Herman wrote:
In Principia Mathematica the notation for the function f with f(x) = 2x + 1 is
^
2x + 1.
[...]
The typesetter could not position the hat on top of the x and placed it
in front of it, resulting in ^x.2x + 1.
That's not quite right. In Principia Mathematica, x̂ was used for
class abstraction. For example x̂.x = y or x̂(x = y) would mean the
singleton class, in this case also a set, {y}. Gottlob Frege had
earlier used a half-ring or reversed-c above, e.g. x͗(x = y), for
essentially the same thing [Frege, 1902].
Since this is not the same as functional abstraction (but was similar
in the sense of being a variable-binding operator), Church deliberately
made the change to using a prefix operator; that step was not due to
typesetting considerations. As I posted before,
Felice Cardone, J. Roger Hindley,
History of Lambda-calculus and Combinatory Logic
2006, Swansea University Mathematics Department
Research Report No. MRRS-05-06.
http://www-maths.swan.ac.uk/staff/jrh/papers/JRHHislamWeb.pdf
# (By the way, why did Church choose the notation λ? In [Church, 1964, §2]
# he stated clearly that it came from the notation x̂ used for
# class-abstraction by Whitehead and Russell, by first modifying x̂ to
# ∧x to distinguish function-abstraction from class-abstraction, and
# then changing ∧ to λ for ease of printing. This origin was also
# reported in [Rosser, 1984, p.338]. On the other hand, in his later years
# Church told two enquirers that the choice was more accidental: a symbol
# was needed and λ just happened to be chosen.)
[Church, 1964] A. Church, 7 July 1964. Unpublished letter to Harald Dickson.
[Rosser, 1984] J. B. Rosser. Highlights of the history of the lambda
calculus. Annals of the History of Computing, 6:337–349, 1984.
[Frege, 1902] G. Frege, 1902. Letter to Russell. Reproduced in
Van Heijenoort, J. From Frege to Gödel: A Source Book in Mathematical
Logic, 1879-1931. AuthorHouse, December 6, 1999. ISBN 158348597X.
[If your email client doesn't display the above correctly:
x̂ is an x with a hat operator (similar to a circumflex) above it.
x͗ is an x with a reversed 'c', or half-ring open on the left, above it.
∧ is an upward-pointing wedge.
λ is a lowercase Greek lambda.]
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 17, 2008 at 9:53 PM, Yuh-Ruey Chen maian...@gmail.com wrote: Lex Spoon wrote: 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. I don't think anyone is suggesting that it would be too difficult to parse for bottom-up parsers. It's just that it makes it difficult for a certain common class of bottom-up parsers, namely the LALR(k) for fixed k parser generators, to parse. Good point. Actually, though, the same sort of approach should still work. The grammar for a = entry would be something like: atomic_expression = atomic_expression Then, the rule that assembles this parse tree into a real AST would analyze the expression on the left and either convert it to a parse tree, or emit a retroactive parse error. I know this initially violates some design sense--it does mine!--because normally a parser rule reuses subexpressions without change. However, in this case it works out well, and so I think the rule of thumb is misleading. This implementation technique should be simple, localized, easy to understand, and as a result robust. Lex ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 17, 2008, at 1:42 PM, Lex Spoon wrote:
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.
It's for Ecma solidarity -- we are indirectly boosting another Ecma
standard (C# is ECMA-334, IIRC), albeit at the expense of Scala :-P.
Ok, enough of that (we really do not try to align Ecma language
standards, which include Eiffel!). Thanks for the precedent correction.
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.
I called the = syntax no-go for JS in
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008352.html
cites two general arguments.
First, parsing top-down and then revising the AST based on right
context is do-able -- but the This can get ugly remark is meant to
suggest that it's costly compared to choosing a grammar that avoids
the ambiguity.
On the plus side, destructuring in JS1.7, proposed for Harmony to
broad agreement, requires similar revision:
[p, q] = [q, p];
swaps p and q, but it starts like
[p, q];
(and of course could be nested anywhere an assignment expression could
occur).
Let's say we can overcome this objection, by selling the benefit to
the users over the cost to implementors (and users, in minor code
footprint; slippery slope hazard here, otherwise it's not a big cost).
I'm not confident this assumption will hold in committee -- need to
get Waldemar's reaction, at least -- but for now let's just say :-).
The second argument is that the issue may not be localized, especially
in light of automatic semicolon insertion. A counter-example adapted
from the The trouble with ambiguous grammars thread:
a = a ? f : x++
(0);
A function expression in JS today is a primary expression, e.g.
var f = function (a) { return a ? f : x++; }
(0);
so lambda users might expect the same precedence.
If the grammar is something like this:
AssignmentExpression:
...
|identifier '=' AssignmentExpression
|'(' parameters ')' '=' AssignmentExpression
(which AFAICT from web C# 3.0 grammars is what C# does) then we may be
ok. We'd need to check carefully.
Mono C# seems to have to bend over backwards to parse C# lambdas:
http://tirania.org/blog/archive/2007/Feb-15.html
but I don't see why a bottom-up parser can't decide quite late,
compared to a top-down parser, that it has a lambda parameter list and
not a parenthesized expression.
Perhaps we dismissed the = syntax too quickly, but we need a checked
bottom-up grammar. It's not enough to assert locality, unfortunately,
given the existing grammar and the complexity of automatic semicolon
insertion.
/be___
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: Allen's lambda syntax proposal
Breton Slivka wrote: On Sat, Dec 6, 2008 at 9:57 AM, Michael Day [EMAIL PROTECTED] wrote: (1) Expression lambdas: lambdas whose body is an expression. var x = lambda(y, z) y + z Solves the problem with completion leakage, solves the nested return/break/continue issue. However, quite limited in usage, and makes it difficult to use lambdas to replace functions as they can't contain loop statements. (Hello, recursion! :) [snip] 2) It would be really nice to have a callable value that was garaunteed not to have side effects. a lambda with an expression body might not be that. Nevertheless, this would enable a parallelized array map function that's safe to use. In the absence of real multithreading, this kind of parallelism would be a boon for applications like 3d games, or image processing. This little comment got lost in the recent deluge of emails, but I too would really like some mechanism to avoid or see if a function causes side effects (and not just mutability). ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Yuh-Ruey Chen wrote: Breton Slivka wrote: On Sat, Dec 6, 2008 at 9:57 AM, Michael Day [EMAIL PROTECTED] wrote: (1) Expression lambdas: lambdas whose body is an expression. var x = lambda(y, z) y + z Solves the problem with completion leakage, solves the nested return/break/continue issue. However, quite limited in usage, and makes it difficult to use lambdas to replace functions as they can't contain loop statements. (Hello, recursion! :) [snip] 2) It would be really nice to have a callable value that was garaunteed not to have side effects. a lambda with an expression body might not be that. Nevertheless, this would enable a parallelized array map function that's safe to use. In the absence of real multithreading, this kind of parallelism would be a boon for applications like 3d games, or image processing. This little comment got lost in the recent deluge of emails, but I too would really like some mechanism to avoid or see if a function causes side effects (and not just mutability). That's unfeasibly difficult in full ECMAScript. Perhaps you could do it starting with one of the secure subsets (which have immutable globals and immutable prototypes of built-in types, for instance). -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Peter Michaux wrote: On Sat, Dec 6, 2008 at 7:51 PM, David-Sarah Hopwood [EMAIL PROTECTED] wrote: The keyword 'function' shouldn't be used for this because a lambda is not a function. However, const name(formals) ... let name(formals) ... could be sugar for const name = lambda(formals) ...; Does const have var or let scoping...or is it even a declaration at all? When 'let' and 'const' were proposed to be added to ES3.1, 'const' would have been a declaration with the same scoping as 'let'. This part of the ES3.1 proposal wasn't controversial, I think. Although it is bulky it might be better to write const var and const let. A variable being constant or not is orthogonal to its scoping and should be controlled independently. That would be the case if the scoping of 'let' wasn't a strict improvement on, and intended replacement for, that of 'var'. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
David-Sarah Hopwood wrote: Jon Zeppieri wrote: On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote: I don't get it. What issue is raised by return-to-label that isn't already raised by exceptions? [...] Also, what was the performance issue? The (minor) performance issue is that if there is a lambda that returns from a given function, all calls within that function body must check for an escape, even if the lambda is never passed to them or otherwise accessible to them. Similarly for calls within the scope of a labelled statement or iteration that contains a lambda with a corresponding 'break' or 'continue'. Please disregard this -- I had overlooked a way to make the performance of escape continuations identical to that of exceptions. No explicit per-call checks are needed; the jump to the break/continue/return target can be handled using the same mechanism as try/catch handlers, with the same possible optimizations. In the case where the control abstraction is built-in or its implementation is inlined, the performance can be the same as conventional break/continue/return. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-06, at 00:23EST, David-Sarah Hopwood wrote:
P T Withington wrote:
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3.
I think this is unambiguous, but I don't like it because it has no
symbol or combination of symbols that is specific to a lambda.
( {( can occur as the start of a block.)
^{(a, b) a +b}
Perhaps? An expression cannot start with `{(`, a statement cannot
start with `^`.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Alex Russell wrote:
Indeed, it can look like an expression to begin a name assignment:
var thinger = {(foo+bar): ... };
Has a syntax like this been shot down yet?:
var thinger = {{ foo, bar }: ... };
Since objects (much less literals) aren't used as keys in hashes
often, this strikes me as being somewhat less ambiguous. The short (no
args) version might then be:
var thinger = {: ... };
Arguments against?
I think that would require LALR(k) for bottom-up parsers, which we're
trying to avoid mandating.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Alex Russell wrote:
On Dec 5, 2008, at 9:23 PM, David-Sarah Hopwood wrote:
P T Withington wrote:
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3.
I think this is unambiguous, but I don't like it because it has no
symbol or combination of symbols that is specific to a lambda.
( {( can occur as the start of a block.)
Indeed, it can look like an expression to begin a name assignment:
var thinger = {(foo+bar): ... };
No, property names in object literals are required to be a single
IdentifierName, StringLiteral or NumericLiteral.
Has a syntax like this been shot down yet?:
var thinger = {{ foo, bar }: ... };
Since objects (much less literals) aren't used as keys in hashes often,
this strikes me as being somewhat less ambiguous. The short (no args)
version might then be:
var thinger = {: ... };
Arguments against?
What is the advantage of this syntax over ^(a, b) {a+b}, for example?
Ditto for P T Withington's proposal of ^{(a, b) a+b}.
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
This is ambiguous
{(a, b)
a + b}
is
{(a,b);
a+b
}
unless use no line break restrict and it is difficult to parse
P T Withington wrote:
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3.
I think this is unambiguous, but I don't like it because it has no
symbol or combination of symbols that is specific to a lambda.
( {( can occur as the start of a block.)
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote: I don't get it. What issue is raised by return-to-label that isn't already raised by exceptions? They're practically the same thing, only return-to-label is *easier* to analyze statically, because 'return' can only jump to a label that is lexically (not just dynamically) in scope. If you want to call a function and make sure control flow does not escape, then in the face of exceptions alone you can wrap it in try/ catch. However, with multi-level returning lambdas, if you are passed a function then you have no way to prevent it from returning early, since it could be a lambda in the lexical scope of your caller. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote: I don't get it. What issue is raised by return-to-label that isn't already raised by exceptions? They're practically the same thing, only return-to-label is *easier* to analyze statically, because 'return' can only jump to a label that is lexically (not just dynamically) in scope. If you want to call a function and make sure control flow does not escape, then in the face of exceptions alone you can wrap it in try/catch. However, with multi-level returning lambdas, if you are passed a function then you have no way to prevent it from returning early, since it could be a lambda in the lexical scope of your caller. The strawman contains the following text: Unwinding the execution context may pass through finally blocks, which execute and may perform their own control effects, effectively canceling the unwinding. So, you have a dynamic-wind-like mechanism, if you need it. Also, what was the performance issue? -Jon ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 6, 2008, at 9:57 AM, Jon Zeppieri wrote: On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote: I don't get it. What issue is raised by return-to-label that isn't already raised by exceptions? They're practically the same thing, only return-to-label is *easier* to analyze statically, because 'return' can only jump to a label that is lexically (not just dynamically) in scope. If you want to call a function and make sure control flow does not escape, then in the face of exceptions alone you can wrap it in try/catch. However, with multi-level returning lambdas, if you are passed a function then you have no way to prevent it from returning early, since it could be a lambda in the lexical scope of your caller. The strawman contains the following text: Unwinding the execution context may pass through finally blocks, which execute and may perform their own control effects, effectively canceling the unwinding. So, you have a dynamic-wind-like mechanism, if you need it. I guess then the damage can be contained, but it's unusual to use a mechanism like this for normal control flow rather than just exceptional conditions. Also, what was the performance issue? It turns return inside a lambda into a construct that has to unwind the stack (and apparently run finally handlers), which makes its cost more like the cost of throwing an exception than the cost of a normal return. In most implementations, throwing an exception is much more expensive. Actually, it could be worse than throwing an exception, since if you can't actually unwind the call stack until you find whether the lambda's containing function is currently on the stack. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Sat, Dec 6, 2008 at 2:03 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 9:57 AM, Jon Zeppieri wrote: On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote: I don't get it. What issue is raised by return-to-label that isn't already raised by exceptions? They're practically the same thing, only return-to-label is *easier* to analyze statically, because 'return' can only jump to a label that is lexically (not just dynamically) in scope. If you want to call a function and make sure control flow does not escape, then in the face of exceptions alone you can wrap it in try/catch. However, with multi-level returning lambdas, if you are passed a function then you have no way to prevent it from returning early, since it could be a lambda in the lexical scope of your caller. The strawman contains the following text: Unwinding the execution context may pass through finally blocks, which execute and may perform their own control effects, effectively canceling the unwinding. So, you have a dynamic-wind-like mechanism, if you need it. I guess then the damage can be contained, but it's unusual to use a mechanism like this for normal control flow rather than just exceptional conditions. I'd say that under the proposed semantics, return from lambda isn't normal control flow; it's a (potentially) non-local jump. Normal return inside a lambda is just falling off the end. Also, what was the performance issue? It turns return inside a lambda into a construct that has to unwind the stack (and apparently run finally handlers), which makes its cost more like the cost of throwing an exception than the cost of a normal return. Yes, because it is very similar to throwing an exception. Would you prefer that return inside lambda instead return from the lambda's own activation? That could be done, with some violence to TCP. In the most common case, however -- namely, return from function, which, under Dave's proposal, desugars to a return from lambda -- couldn't the additional cost be optimized away easily? You can determine statically that the jump doesn't unwind the stack, so the cost of returning should remain the same. In most implementations, throwing an exception is much more expensive. Actually, it could be worse than throwing an exception, since if you can't actually unwind the call stack until you find whether the lambda's containing function is currently on the stack. Okay, but you only incur this expense when you actually take the non-local exit. There is no reason why normal returns should be more expensive. -Jon ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Eric Suen wrote:
This is ambiguous
{(a, b)
a + b}
is
{(a,b);
a+b
}
This example isn't ambiguous, because an ExpressionStatement cannot start
with '{', therefore this is a block. However the fact that a lambda
starting an ExpressionStatement would have to be parenthesized is a
valid argument against this syntax, and also against {|a, b| a+b}.
unless use no line break restrict and it is difficult to parse
It's not actually difficult to parse (since an object literal cannot
have '(' after the '{'), but I don't think it has any advantages over
syntaxes starting with '^' or '\'.
('^' is back on the table given that the semicolon insertion hazard
that caused us to be suspicious of it, already exists when a line
starts with '(', for example.)
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
But in page:
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
lambda is not just a expression, it could be a Declaration.
If lambda is only a expression, that is why I suggest in post:
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008382.html
This is ambiguous
{(a, b)
a + b}
is
{(a,b);
a+b
}
This example isn't ambiguous, because an ExpressionStatement cannot start
with '{', therefore this is a block. However the fact that a lambda
starting an ExpressionStatement would have to be parenthesized is a
valid argument against this syntax, and also against {|a, b| a+b}.
unless use no line break restrict and it is difficult to parse
It's not actually difficult to parse (since an object literal cannot
have '(' after the '{'), but I don't think it has any advantages over
syntaxes starting with '^' or '\'.
('^' is back on the table given that the semicolon insertion hazard
that caused us to be suspicious of it, already exists when a line
starts with '(', for example.)
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Eric Suen wrote:
But in page:
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
lambda is not just a expression, it could be a Declaration.
If lambda is only a expression, that is why I suggest in post:
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008382.html
# No, \ worse than '^' or '', why not use
#
# function ^ Identifier ( parameters ) block for declaration
#
# and use
#
# ^ IdentifierOpt ( parameters ) block for expression
#
# ExpressionStatement ::= [lookahead !{ {, function, ^ }] CommaExpression
The keyword 'function' shouldn't be used for this because a lambda is
not a function. However,
const name(formals) ...
let name(formals) ...
could be sugar for
const name = lambda(formals) ...;
let name = lambda(formals) ...;
(replacing 'lambda' with whatever symbol or keyword is chosen). Then there
is no need to change the negative lookahead in ExpressionStatement.
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 6, 2008, at 9:19 PM, Peter Michaux wrote: On Sat, Dec 6, 2008 at 7:51 PM, David-Sarah Hopwood [EMAIL PROTECTED] wrote: The keyword 'function' shouldn't be used for this because a lambda is not a function. However, const name(formals) ... let name(formals) ... could be sugar for const name = lambda(formals) ...; Does const have var or let scoping...or is it even a declaration at all? Although it is bulky it might be better to write const var No, const var is an oxymoron. and const let. A variable being constant or not is orthogonal to its scoping and should be controlled independently. The preferred approach is to make let and const have the same binding scope, namely block, and leave var alone. let name = lambda(formals) ...; I mentioned this a while back. I think it might be a good idea. Scheme has (define foo (lambda (a b) 1)) (define (foo a b) 1) which could be translated to ES var foo = lambda(a, b) 1; var foo(a, b) 1; I still think this is bad form. A compound that does not create a variable that *must* denote the defined function some time later (via eval, arguments aliasing, hidden assignment if this is global code, etc.) misstates what is usefully meant by the proposed syntax. JS is not Scheme, and while you could argue assignment is like set! the binding forms (including var extensions, but especially function, const, and let) should have more definite and (under a strict mode or future version) immutable meaning. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Hi Brendan, This is the other hazard with lambdas. The program equivalences Tennent's Correspondence Principle enables are good for refactoring, but bad for thinkos like the above. It seems like most of the problems come from lambdas being able to contain statements as well as expressions. If there were only lambda expressions, I think they would be much easier to reason about, but currently there is no way to embed loops in expressions, right? Cheers, Michael -- Print XML with Prince! http://www.princexml.com ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 4, 2008, at 10:27 PM, Brendan Eich wrote:
On Dec 4, 2008, at 10:12 PM, Brendan Eich wrote:
On Dec 4, 2008, at 7:45 PM, Michael Day wrote:
Hi Brendan,
The main contention about lambdas ignoring syntax is whether the
completion-value creates a hazard that needs to be treated
somehow, or even judged as fatal to the proposal.
Completion value, like the last thing to be evaluated in the
lambda? What exactly is the nature of the hazard?
Functional programming favors using completion values -- function
call results propagate back up naturally this way. Chaining,
filters, etc. all work the way you want. Here's the Y combinator:
const fact = lambda(proc) {
return lambda (n) { (n = 1) ? 1 : n * proc(n-1); }
D'oh -- I wrote return incorrectly there. That means, by Tennent's
Correspondence Principle, that if the above were embedded in a
function, the return would force control flow to return from the
function as well as the outer lambda (the one assigned to const
fact), and the return value would be the inner lambda.
This is the other hazard with lambdas. The program equivalences
Tennent's Correspondence Principle enables are good for
refactoring, but bad for thinkos like the above.
(Honest, I didn't do it on purpose!)
What exactly does return from a lambda mean? Let's say I do this:
function F(x) { return lambda(n) { return x + n; } }
function G(h) { return h(1) +1; }
var H = F(1);
G(H);
What is the value of the last expression and why?
Regards,
Maciej
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Allen's lambda syntax proposal
From: Brendan Eich [mailto:[EMAIL PROTECTED] The return hazard exists in Smalltalk too. What's different here that makes you choose differently? Of course, there are more choices than Tennent-to-the-max lambdas or-else classes-as-sugar. The difference is in the foundation language we are starting with. Because of the central role of c-style syntactic control constructs in JavaScript it is unlikely that lambda-based control abstractions will ever be as important in JavaScript as they are in Smalltalk. On the other hand, object literals are core to JavaScript as they are the only mechanism in the current language for declaratively defining a new kind of object. Using JavaScript, every significant application probably needs to define new object abstractions but far fewer apps need to define new control abstractions. If it is necessary to make a choice I'm inclined to prioritize enhancing object literals to make them be a better object/class abstraction mechanisms over enhancing lambdas to make them a better control abstraction mechanism. The return hazard is not a significant problem in Smalltalk. This is probably because of the pervasive use of blocks (closures) for all control structures including the simplest if statements. Every Smalltalk programmer learns at the outset that the lexical occurrence of a ^ (ie, return) anywhere in a method (even with within a nested block) means to return from that method. They generally learn this even before they learn that full semantics of [ ] (ie, lambda). So, there is really never any confusion about whether a ^ was intended to mean return from the block as opposed to return from a method. Occasionally, (actually pretty rarely) situations arise where it would be convenient to explicitly express returning from a block evaluation rather than the method. However, I've never seen a situations where that result couldn't be achieved by restructuring the method so the return case falls off the bottom. Various people have toyed with creating some sort of explicit local block return syntax for Smalltalk (for example ^^) but there are significant complications (since Smalltalk only has block based conditionals the local return would really be a situation of an inner block forcing a return from an outer block) and the need is quite limited. Finally, if restructuring the block doesn't solve the problem, Smalltalk's very flexible exception handling abstractions can probably be used to accomplish a similar result. Don't get me wrong, I like the semantics of break/continue/return that have been proposed for JavaScript lambdas but given our legacy I can see the return hazard being a real problem. And if it is a choice between enhanced object literals and control abstracting lambdas I'd probably go with the object literals. Allen ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Thank you for useful links and explanations. Correct me if I am wrong
but in the current form lambda is a facility that duplicates a function.
More than that it reminds my old languages that had separate keywords
for functions (our lambda?) and procedures (our function?).
Writing code I frequently need small functions (or lambdas). The smaller
the code the better --- it allows to be concise and does not obscure the
intent. That's why I prefer to use lambda's proposed by Oliver Steele
(http://osteele.com/sources/javascript/functional/), which have a lot of
problems being a pure JavaScript implementation. Writing a factorial
using a linear recursion combinator with lambdas:
var fact1 = linrec(= 1, 1, [n - 1], m * n[0]);
is simple and more readable than the equivalent:
var fact2 = linrec(
function(n){ return n = 1; },
function(){ return 1; },
function(n){ return [n - 1]; },
function(m, n){ return m * n[0]; });
I typed 200% more text, and the readability went down by the same 200%
--- because I added 200% of the technical noise not relevant to the
algorithm itself. Anything that improves on that is good in my book.
Lambdas are good:
var fact3 = linrec(
lambda(n) n = 1,
lambda() 1,
lambda(n) [n - 1],
lambda(m, n) m * n[0]);
Shortcuts for lambdas are better:
var fact4 = linrec(\(n) n = 1, \() 1, \(n) [n - 1], \(m, n) m * n[0]);
I perceive them as less noisy.
The link you gave features long lambdas and I don't see what they buy
vs. the regular functions. This is the example from that page:
lambda(i) {
if (!isNumeric(i))
// etc.
else if (i 0)
// etc.
else if (i params.length)
params[i][0]()
else {
i -= params.length;
if (i rest.length)
rest[i]
else
// etc.
}
}
Written as function it is not that long or less clear:
function(i) {
if (!isNumeric(i))
// etc.
else if (i 0)
// etc.
else if (i params.length)
return params[i][0]()
else {
i -= params.length;
if (i rest.length)
return rest[i]
else
// etc.
}
}
My point is we gain more by concentrating on small light-weight snippets
than on one more way to code a big function.
So concentrating on small snippets:
1) Reducing technicalities and the boilerplate improves the clarity of
the code.
1a) I don't mind if lambdas don't have their own this, arguments, or
a scope --- from my experience they are rarely used in small snippets.
1b) I am all for skipping return --- it reduces the boilerplate for
small snippets.
2) Named lambdas, and parameter defaults are of little value. Use
functions if you truly need a named functionality. Otherwise assign it
to a variable and pass around (rarely needed).
3) Losing the keyword lambda in favor of a small shortcut (e.g., \)
will be of great value --- less noise, less boilerplate, less typing,
less opportunities to mistype.
I suggest paring down lambda by shedding names, default parameters,
and possibly the keyword lambda itself --- it reduces complexity, no
chance for ambiguity, easier to implement, easier to use.
Thanks,
Eugene
Brendan Eich wrote:
On Dec 4, 2008, at 5:44 PM, Eugene Lazutkin wrote:
If you started to recap the history of this discussion, could you (or
anybody else in the know) verbalize following things:
1) What is the difference between the function and the lambda? I am not
talking about their syntax, I want to understand the semantic
difference, if there is any.
Please read
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
2) Why is it important for a lambda to have an optional name?
It may not be.
What's
wrong with using a function, if we want a name? IMHO lambda should have
the minimalistic syntax.
Minimalistic does not define itself. The question is what is the
minimal syntax given various constraints.
Church's Lambdas take one argument only. One can curry by hand. Why
isn't that the minimum minimum?
3) Why is it important to be able to specify parameter defaults in
lambda? Again, it looks like an extra sugar to me that can be covered by
a function with parameter defaults.
See
https://mail.mozilla.org/pipermail/es-discuss/2008-October/007715.html
Also consider that default parameters are a convenience we want lambdas
to have if we believe functions should be avoided for much lambda-coding
by hand. The countervailing argument is that lambdas have unintended
completion value hazards, but Schemers and others don't worry about
these and would prefer not to have to run back to functions and lose
Tennent's Correspondence Principle every time default parameters beckon.
The reason I ask is a lot of discussion is going around but if it has a
name and but if it has a default. If it doesn't have a name I would
be satisfied personally with \(a, b) {...} --- it doesn't clash with
anything. Or even with \(a, b) expr.
You're right to question name to rescue \, but trying to minimize
lambdas won't save all the proposed
Re: Allen's lambda syntax proposal
On Dec 5, 2008, at 12:49 PM, Allen Wirfs-Brock wrote:
From: Brendan Eich [mailto:[EMAIL PROTECTED]
The return hazard exists in Smalltalk too. What's different here that
makes you choose differently? Of course, there are more choices than
Tennent-to-the-max lambdas or-else classes-as-sugar.
The difference is in the foundation language we are starting with.
Because of the central role of c-style syntactic control constructs
in JavaScript it is unlikely that lambda-based control abstractions
will ever be as important in JavaScript as they are in Smalltalk.
Agreed so far. The long-term plan here would be macros. Post-Harmony
at this point.
[snip] If it is necessary to make a choice I'm inclined to
prioritize enhancing object literals to make them be a better
object/class abstraction mechanisms over enhancing lambdas to make
them a better control abstraction mechanism.
I question the need to make a choice (yet).
I'm actually concerned about usability of lambdas as anything similar
to functions. Say they're added, and they prove popular for control
abstractions and other purposes, including better functions. Then
not only will completion-value leaks bite people -- misplaced return
probably will too, if better functions involves porting existing
code from function to lambda.
This is all speculation, but here's my non-speculative claim: lambda
syntax should not look so much like function syntax if return within
the body behaves completely differently. We would want syntax very
different from function (i.e., not lambda (args) {body} -- sorry,
Peter Michaux). Or else we should revisit the wisdom of applying TCP
to lambdas.
[Smalltalk observations snipped -- thanks for those, they make sense
but I want to keep pushing on what doesn't work in the current
strawman: wiki space.]
Don't get me wrong, I like the semantics of break/continue/return
that have been proposed for JavaScript lambdas but given our legacy
I can see the return hazard being a real problem.
I agree if lambda looks like function or is sold as a better
function. If it looks more like a block, or something else, that
might mitigate the return hazard. Michael Day wondered if we confined
the body to an expression language -- that would eliminate the return
hazard.
And if it is a choice between enhanced object literals and control
abstracting lambdas I'd probably go with the object literals.
No false dilemmas yet, please!
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
This is all speculation, but here's my non-speculative claim: lambda
syntax should not look so much like function syntax if return within the
body behaves completely differently. We would want syntax very different
from function (i.e., not lambda (args) {body} -- sorry, Peter Michaux).
Or else we should revisit the wisdom of applying TCP to lambdas.
I'm unconvinced that TCP needs to apply to statements; it seems like a
more valuable property when applied to expressions, even though
JavaScript is not referentially transparent to begin with.
Anyway, these three options look good to me:
(1) Expression lambdas: lambdas whose body is an expression.
var x = lambda(y, z) y + z
Solves the problem with completion leakage, solves the nested
return/break/continue issue. However, quite limited in usage, and makes
it difficult to use lambdas to replace functions as they can't contain
loop statements. (Hello, recursion! :)
(2) Function lambdas: objects just like functions, except no this or
arguments, and perhaps some guarantees about tail calls?
var x = lambda(y, z) { return y + z }
This seems the easiest for programmers to understand, and avoids the
return/break issues. It violates TCP for statements, but I don't think
that really matters in practice; after all, so do functions.
(3) Parametric blocks: where a block, possibly taking arguments, can be
passed around as an object. The key use-case for this seems to be
creating new control abstractions. I would argue that blocks should not
be usable as expressions, and the completion value cannot be captured
(unless using eval) for consistency with existing statement behaviour.
var a = block { ... statements ... }
var b = block(x, y) { ... statements using x and y ... }
call b(1, 2); // this is a statement, not an expression
Unfortunately, object literals also look like blocks, and there is no
perfect syntax for this that fits neatly into the existing language.
without using bulky keywords. While this option preserves TCP, I don't
think JavaScript really needs this feature, and the power/complexity
ratio doesn't measure up.
I agree if lambda looks like function or is sold as a better function.
If it looks more like a block, or something else, that might mitigate
the return hazard. Michael Day wondered if we confined the body to an
expression language -- that would eliminate the return hazard.
I like options (1) and (2) above. The current proposal on the wiki feels
like all three options mashed together, and I find it difficult make
sense of it as a basic construct.
Cheers,
Michael
--
Print XML with Prince!
http://www.princexml.com
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Why not using two version, one is for definition like:
Lambda name (a,b,c) {
}
and for expression, you can use both, like:
a = lambda (a,b,c) {
}
and
a = (a,b,c) {
}
Yes, it doesn't contain a lambda expression, just like:
a = x
/x/i
is not same as:
a = x;
/x/i
they both right but has different meaning...
Okay -- so we agree. In that case, it's clear that your proposed syntax:
(a,b,c) {...}
has the same problem, right? Any valid ES3 infix operator will have
the same problem, if we use it as a prefix lambda operator.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen's lambda syntax proposal
My example:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
is not a syntax error, but it also (unfortunately) doesn't contain a
lambda expression. Or am I missing something?
Or a bit more obvious than the use of the comma-operator:
As soon as named lambdas are introduced (the weak spot on the \
proposal), you'll get big problems with the ^ proposal, too.
Consider the following snippet which is valid Javascript code, but
certainly not a lambda expression.
var f = function (){return 8;}
var x = 5
^f(x) { x=x*x }
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 3, 2008, at 6:30 PM, Brendan Eich wrote:
On Dec 3, 2008, at 6:18 PM, Maciej Stachowiak wrote:
x = x
+x
That is equivalent to
x = x + x;
so the case with ^ should not differ. (Were you testing in an
interactive REPL?)
I didn't test, I just knew this case must be disambiguated somehow and
didn't test which way. I don't think it matters much which way, since
you can avoid any such problems in your own code by using semicolons
for line endings.
That the case Peter showed:
x = x
^(){}
cannot be parsed as a bitwise-xor expression doesn't help in
general, if we do not want to mandate bottom-up parsing (we don't).
I think it would be fine for this case to be a syntax error.
Regards,
Maciej
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 4, 2008, at 7:18 AM, Michael wrote:
Would this form also be ambiguous and/or too difficult to parse?
{= 9*9}()
{a = a+b}(12)
{(a,b) = a+b}(12,6)
I imagine it would be problematic for a top-down parser because you
may have to parse an unbounded number of characters to determine if
the initial parameter list is in fact a parameter list or a comma
expression.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 7:25 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
Okay -- so we agree. In that case, it's clear that your proposed syntax:
(a,b,c) {...}
has the same problem, right? Any valid ES3 infix operator will have
the same problem, if we use it as a prefix lambda operator.
Welcome to the syntax races. lambda takes an early lead, but drops back
because of too much weight. For a while, it's neck and neck between || and
^, with \ following closely and fn, , and other trailing. Many old
timers (including your commentator) are rooting for || because of its
previous historic performances. But || trips up over ambiguities not
present on its original track. ^ is now in the lead. Oh no! It trips on a
different ambiguity. This track seems riddled with more ambiguities than any
of these contenders have ever trained on. Seeing ^ stumble, and other
contenders saddled with binary operatorness, drop back and concede. \
has taken the lead
--
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/4 Mark S. Miller [EMAIL PROTECTED]: Welcome to the syntax races. lambda takes an early lead, but drops back because of too much weight. For a while, it's neck and neck between || and ^, with \ following closely and fn, , and other trailing. Many old timers (including your commentator) are rooting for || because of its previous historic performances. But || trips up over ambiguities not present on its original track. ^ is now in the lead. Oh no! It trips on a different ambiguity. This track seems riddled with more ambiguities than any of these contenders have ever trained on. Seeing ^ stumble, and other contenders saddled with binary operatorness, drop back and concede. \ has taken the lead I have my money on lambda. I'm thinking it has the endurance necessary. It has already lasted longer in history than all the others. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 4, 2008, at 10:28 AM, Maciej Stachowiak wrote:
On Dec 4, 2008, at 7:18 AM, Michael wrote:
Would this form also be ambiguous and/or too difficult to parse?
{= 9*9}()
{a = a+b}(12)
{(a,b) = a+b}(12,6)
I imagine it would be problematic for a top-down parser because you
may have to parse an unbounded number of characters to determine if
the initial parameter list is in fact a parameter list or a comma
expression.
Right -- especially if one includes destructuring parameters.
Typically a top-down cover grammar is parsed, and then disamiguated
based on right context after the AST is built, with any adjustments to
the AST encoding made retrospectively. This can get ugly.
Worse, as Waldemar pointed out, you can end up with a failure to
backtrack and find the valid sentential form that a bottom up parser
would find via shifting and reducing.
Combined, this says to me that the C# syntax is no-go for JS.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-04, at 15:23EST, David-Sarah Hopwood wrote: Arguably, the problem here is that semicolon insertion is and always was a bad idea. whinge That and not requiring whitespace around operators, thus taking away a huge domain of possible multi-symbol names (such as := for initialization/assignment to preclude the =/== trap, or say, )\ for λ, and forcing camelCasing or carpal_tunnel_syndrome upon everyone who prefers descriptive-symbol-names...) /whinge ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Thu, Dec 4, 2008 at 3:23 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
Jon Zeppieri wrote:
And, if it is on the same line, it's still bad for a top-down parser:
^(x) {
x = x * x
^(a,b,c,d,e,f,g) {x}
}
Same result as above.
Actually, I think we're both wrong. If I'm reading the spec
correctly, no semicolon would be inserted, and the whole thing would
be a syntax error. The offending token here is '{', but it's not
separated from the previous token -- namely, ')' -- by at least one
LineTerminator.
At any rate, it's a problem.
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Mark S. Miller wrote: [...] \ has taken the lead There's still #, @, and ` (and of course keywords like lambda and fn). None of these are as mnemonic as \, but they leave \ as a purely lexical escape character. It's quite ironic that we are still limited, as Church was, in which characters we can use for the modern equivalent of typographical reasons. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
David-Sarah Hopwood wrote:
Jon Zeppieri wrote:
[...]
The opening brace will need to be on the same line as the formals,
otherwise the syntax is ambiguous:
^(x) {
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
}
Strictly speaking, the syntax is not ambiguous; it just is not parsed
how you might expect. The semicolons would be inserted in this example
as follows:
^(x) {
x = (x * x)^(a, b, c, d, e, f, g);
{ x; }
};
Arguably, the problem here is that semicolon insertion is and always
was a bad idea.
And, if it is on the same line, it's still bad for a top-down parser:
^(x) {
x = x * x
^(a,b,c,d,e,f,g) {x}
}
Same result as above.
Sorry, not the same result. This would be formally a syntax error,
although note that some implementations do perform semicolon insertion
even at non-line-boundaries.
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 4, 2008, at 12:52 PM, David-Sarah Hopwood wrote: Sorry, not the same result. This would be formally a syntax error, although note that some implementations do perform semicolon insertion even at non-line-boundaries. Yes, that bothers me (I'm feeling guilty here: I could use a bugzilla.mozilla.org bug on file). But is it required for web interop? If IE JScript does it and has since the old days, then the default answer has to be yes, and we should think about specifying the de- facto standard. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 4, 2008, at 2:31 PM, Breton Slivka wrote: I admit this seems ludicrous at its face, but admittedly I have not really seen the arguments against λ as an abbreviated lambda syntax yet. Not compatibly: ES3 already allows Unicode identifiers, including Greek Lambda. Other Mathematical Lambda characters are not in the BMP: http://www.mail-archive.com/[EMAIL PROTECTED]/msg15581.html It's still too hard to type. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
[oops, sent from the wrong address...]
2008/12/4 Breton Slivka [EMAIL PROTECTED]:
this may be a stupid question, but why? Is it really so impossible to
have λ(a,b,c){} ?
Last time I brought this up, Brendan made fun of me on a podcast. :(
You guys seem to have no trouble typing it. It's not that much trouble
to remap a key, and you can always keep lambda(a,b,c){} as a more
verbose but more accessable alternative. IDEs could make a macro out
of it so you wouldn't even have to bother with going to the trouble of
remapping.
Exactly what I wrote then.
I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
Well aside from the random guy doesn't know how to map a key problem
(which is perfectly true), I could see some character set issues in
the field.
On Thu, Dec 4, 2008 at 5:35 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Dec 4, 2008, at 2:31 PM, Breton Slivka wrote:
I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
Not compatibly: ES3 already allows Unicode identifiers, including Greek
Lambda.
Also including the word 'lambda' -- but that hasn't stopped it from
being seriously considered.
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Fri, Dec 5, 2008 at 9:35 AM, Brendan Eich [EMAIL PROTECTED] wrote: On Dec 4, 2008, at 2:31 PM, Breton Slivka wrote: I admit this seems ludicrous at its face, but admittedly I have not really seen the arguments against λ as an abbreviated lambda syntax yet. Not compatibly: ES3 already allows Unicode identifiers, including Greek Lambda. Other Mathematical Lambda characters are not in the BMP: http://www.mail-archive.com/[EMAIL PROTECTED]/msg15581.html It's still too hard to type. /be http://picasaweb.google.com/eileen.world.traveler/EileenBestOfGreece#5139474493916668850 ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Allen's lambda syntax proposal
For some reason I'm reminded of this quote:
APL, in which you can write a program to simulate shuffling a deck of cards
and then dealing them out to several players in four characters, none of
which appear on a standard keyboard. David Given
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jon Zeppieri
Sent: Thursday, December 04, 2008 4:46 PM
To: es-discuss@mozilla.org
Subject: Re: Allen's lambda syntax proposal
[oops, sent from the wrong address...]
2008/12/4 Breton Slivka [EMAIL PROTECTED]:
this may be a stupid question, but why? Is it really so impossible to
have λ(a,b,c){} ?
Last time I brought this up, Brendan made fun of me on a podcast. :(
You guys seem to have no trouble typing it. It's not that much trouble
to remap a key, and you can always keep lambda(a,b,c){} as a more
verbose but more accessable alternative. IDEs could make a macro out
of it so you wouldn't even have to bother with going to the trouble of
remapping.
Exactly what I wrote then.
I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
Well aside from the random guy doesn't know how to map a key problem
(which is perfectly true), I could see some character set issues in
the field.
On Thu, Dec 4, 2008 at 5:35 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Dec 4, 2008, at 2:31 PM, Breton Slivka wrote:
I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
Not compatibly: ES3 already allows Unicode identifiers, including Greek
Lambda.
Also including the word 'lambda' -- but that hasn't stopped it from
being seriously considered.
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/11/29 Brendan Eich [EMAIL PROTECTED]: At the TC39 meeting two weeks ago in Kona, we had a brief bikeshedding discussion about lambda syntax and why it matters. Who would have thought a discussion about lambda syntax in JavaScript would go over 120 posts while a simultaneous thread about class syntax has had little attention outside a handful of posters? Would this have been reverse 10 years ago? Sign of the paradigm shift? Maybe folks want an immutable cons cells too? Modern attention span? Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Thu, Dec 4, 2008 at 6:10 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Dec 4, 2008, at 2:45 PM, Jon Zeppieri wrote:
2008/12/4 Breton Slivka [EMAIL PROTECTED]:
this may be a stupid question, but why? Is it really so impossible to
have λ(a,b,c){} ?
Last time I brought this up, Brendan made fun of me on a podcast. :(
Not you personally! I hope that was at least a :-/ emoticon...
Oops. You see the typographical limitations we're still saddled with?
The mock-wounded :( and the actually-wounded :( aren't slated to have
distinct code points until Unicode 17.
If we have to go to one character, though, I'd rather we use an ASCII
punctuation character, for the reasons given (hard to type, slight
incompatibility). But you λ fans need to help me here: how does one type λ
on a Mac laptop? How about on a standard Windows machine? Pick a Linux and
lay the clues on there, too.
I'm a lot more likely to do this within emacs (or an editor, in
general) than at the system / window system level. Anyhow, ASCII
punctuation is great, if we can settle on a candidate.
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Brendan Eich wrote: If we have to go to one character, though, I'd rather we use an ASCII punctuation character, for the reasons given (hard to type, slight incompatibility). But you λ fans need to help me here: how does one type λ on a Mac laptop? How about on a standard Windows machine? Pick a Linux and lay the clues on there, too. you can add a greek keyboard to your input methods, and set up a kb shortcut to switch easily. like, for mac osx: system preferences, international, input menu. enable greek keyboard. enable show input menu in menu bar. click on keyboard shortcuts. in input menu, enable select the next input source, assign it a shortcut that doesn't conflict with anything you use, like maybe option-space. then, to type lambda, type option-space until you're at the greek flag, then type lowercase-L (on u.s. qwerty), windows is pretty similar to osx, it's in regional and language options I think modern linux is also similar, but I'm not near one at the moment. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 4, 2008, at 5:44 PM, Eugene Lazutkin wrote:
If you started to recap the history of this discussion, could you (or
anybody else in the know) verbalize following things:
1) What is the difference between the function and the lambda? I am
not
talking about their syntax, I want to understand the semantic
difference, if there is any.
Please read
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
2) Why is it important for a lambda to have an optional name?
It may not be.
What's
wrong with using a function, if we want a name? IMHO lambda should
have
the minimalistic syntax.
Minimalistic does not define itself. The question is what is the
minimal syntax given various constraints.
Church's Lambdas take one argument only. One can curry by hand. Why
isn't that the minimum minimum?
3) Why is it important to be able to specify parameter defaults in
lambda? Again, it looks like an extra sugar to me that can be
covered by
a function with parameter defaults.
See
https://mail.mozilla.org/pipermail/es-discuss/2008-October/007715.html
Also consider that default parameters are a convenience we want
lambdas to have if we believe functions should be avoided for much
lambda-coding by hand. The countervailing argument is that lambdas
have unintended completion value hazards, but Schemers and others
don't worry about these and would prefer not to have to run back to
functions and lose Tennent's Correspondence Principle every time
default parameters beckon.
The reason I ask is a lot of discussion is going around but if it
has a
name and but if it has a default. If it doesn't have a name I would
be satisfied personally with \(a, b) {...} --- it doesn't clash with
anything. Or even with \(a, b) expr.
You're right to question name to rescue \, but trying to minimize
lambdas won't save all the proposed syntaxes. We're making progress in
finding some to be in trouble, if not fatally flawed.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
I thought this might be the answer. It's clearly too much to ask of all lambda-coders and would-be lambda-coders in the world. My two cents, perhaps I'm wrong and the Schemers and others will switch their kbd configs. Or the code generators will rise and exterminate lambda-coding humans. But I doubt it. /be On Dec 4, 2008, at 5:44 PM, Felix wrote: Brendan Eich wrote: If we have to go to one character, though, I'd rather we use an ASCII punctuation character, for the reasons given (hard to type, slight incompatibility). But you λ fans need to help me here: how does one type λ on a Mac laptop? How about on a standard Windows machine? Pick a Linux and lay the clues on there, too. you can add a greek keyboard to your input methods, and set up a kb shortcut to switch easily. like, for mac osx: system preferences, international, input menu. enable greek keyboard. enable show input menu in menu bar. click on keyboard shortcuts. in input menu, enable select the next input source, assign it a shortcut that doesn't conflict with anything you use, like maybe option-space. then, to type lambda, type option-space until you're at the greek flag, then type lowercase-L (on u.s. qwerty), windows is pretty similar to osx, it's in regional and language options I think modern linux is also similar, but I'm not near one at the moment. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Fri, Dec 5, 2008 at 1:10 PM, Brendan Eich [EMAIL PROTECTED] wrote: I thought this might be the answer. It's clearly too much to ask of all lambda-coders and would-be lambda-coders in the world. My two cents, perhaps I'm wrong and the Schemers and others will switch their kbd configs. Or the code generators will rise and exterminate lambda-coding humans. But I doubt it. /be approaching it from the other side of the question, it seems that people with german keyboards would have a similarly difficult time with the pipe character. example: http://forums.macosxhints.com/archive/index.php/t-29410.html It's the same issue with possibly any of the other symbols that have been discussed for the syntax. It doesn't really matter what you pick. If it's not lambda, you're inconveniencing someone. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 4, 2008, at 6:39 PM, Breton Slivka wrote: On Fri, Dec 5, 2008 at 1:10 PM, Brendan Eich [EMAIL PROTECTED] wrote: I thought this might be the answer. It's clearly too much to ask of all lambda-coders and would-be lambda-coders in the world. My two cents, perhaps I'm wrong and the Schemers and others will switch their kbd configs. Or the code generators will rise and exterminate lambda-coding humans. But I doubt it. /be That's why you'd map it to l tab in your ide. I don't have an ide -- March has some, but they bode ill :-P. Seriously, of course most users could figure out how to inject a Greek Lambda, but add up all that effort imposed on probably thousands to millions. It's an imposition. It is not a cost free good. Why is it so important to use a non-ASCII character? Also, you wouldn't be inconveniencing all lambda coders in the world. Only the ones without greek keyboards. Are there just not enough greek javascripters to matter? Heh. While I would like to think so, I doubt it. But you never know... /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Hi Brendan, Please read http://wiki.ecmascript.org/doku.php?id=strawman:lambdas There is a lot of discussion over whether it is necessary to introduce syntax sugar instead of a lambda keyword, but is there any remaining controversy over the semantics of lambdas in JavaScript, or is that considered settled at this point? (To throw some more kerosene on the syntax fire, I would point out that fun for function nicely resembles var for variable: var x = fun y z = y + z; but it's not big deal :) Best regards, Michael -- Print XML with Prince! http://www.princexml.com ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
No, \ worse than '^' or '', why not use
function ^ Identifier ( parameters ) block for declaration
and use
^ IdentifierOpt ( parameters ) block for expression
ExpressionStatement ::= [lookahead !{ {, function, ^ }] CommaExpression
Okay -- so we agree. In that case, it's clear that your proposed syntax:
(a,b,c) {...}
has the same problem, right? Any valid ES3 infix operator will have
the same problem, if we use it as a prefix lambda operator.
Welcome to the syntax races. lambda takes an early lead, but drops back
because of too much weight. For a while, it's neck and neck between || and
^, with \ following closely and fn, , and other trailing. Many old
timers (including your commentator) are rooting for || because of its
previous historic performances. But || trips up over ambiguities not
present on its original track. ^ is now in the lead. Oh no! It trips on a
different ambiguity. This track seems riddled with more ambiguities than any
of these contenders have ever trained on. Seeing ^ stumble, and other
contenders saddled with binary operatorness, drop back and concede. \
has taken the lead
--
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Hi Brendan, The main contention about lambdas ignoring syntax is whether the completion-value creates a hazard that needs to be treated somehow, or even judged as fatal to the proposal. Completion value, like the last thing to be evaluated in the lambda? What exactly is the nature of the hazard? (To throw some more kerosene on the syntax fire, I would point out that fun for function nicely resembles var for variable: var x = fun y z = y + z; but it's not big deal :) Not bad but you lost the necessary (destructuring, default parameters) parenthesized formal list. Right, an arguments list should still look like an arguments list: var x = fun (y, z) = y + z or with an identifier: var x = fun fact(n) = (x 2 ? 1 : n * fact(n-1)) I toyed with 'fun' instead of 'function' in 1995 but it would have been a misfit in the Java-esque/C-like keyword set, even with 'var' included. In an alternate universe, you might have used 'method' for functions with a 'this' value, saving two characters and the name function for real functions :) Cheers, Michael -- Print XML with Prince! http://www.princexml.com ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 4, 2008, at 7:45 PM, Michael Day wrote:
Hi Brendan,
The main contention about lambdas ignoring syntax is whether the
completion-value creates a hazard that needs to be treated somehow,
or even judged as fatal to the proposal.
Completion value, like the last thing to be evaluated in the lambda?
What exactly is the nature of the hazard?
Functional programming favors using completion values -- function call
results propagate back up naturally this way. Chaining, filters, etc.
all work the way you want. Here's the Y combinator:
const fact = lambda(proc) {
return lambda (n) { (n = 1) ? 1 : n * proc(n-1); }
}
const Y = lambda(outer) {
const inner = lambda (proc) {
outer(lambda (arg) { proc(proc)(arg); });
}
inner(inner);
}
print(5! is + Y(fact)(5));
Adding return keywords just adds overhead, noise. One might even want
to get rid of the curly braces around lambda bodies, but the only way
to do it in the ES grammar and avoid ambiguity is to replace braces
with mandatory parentheses.
On the other hand, much JS on the web is imperative, and a lot uses a
mixed functional/imperative style. Often the last value in a function
is not the return value you want callers to be able to get, and with
functions all is well: falling off the end returns undefined.
But with lambdas, falling off the end returns the last statement's
completion value. This means people will have to write
lambda (secret) { compute(secret); void 0; }
and similar. Of course too few will remember to do this, so implicit
return values will tend to leak.
How severe a problem this might be is arguable, but we don't want to
gamble. We want user feedback based on trial implementations, and
other convincing evidence for or against.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
In feature(ES4), ES may have OptionalParameter, that will cause trouble
{ |a ,b = 1 | c | d | e | f }
is
{ (|a ,b = 1 |) c | d | e | f }
or
{ (|a ,b = 1 | c) | d | e | f }
Regards,
Eric Suen
- Original Message -
From: Yuh-Ruey Chen [EMAIL PROTECTED]
To: Brendan Eich [EMAIL PROTECTED]
Cc: Eric Suen [EMAIL PROTECTED]; Maciej Stachowiak
[EMAIL PROTECTED]; es-discuss
es-discuss@mozilla.org
Sent: Wednesday, December 03, 2008 8:56 PM
Subject: Re: Allen's lambda syntax proposal
Brendan Eich wrote:
C# uses (a, b, c) = ... but in JS the comma operator makes that nasty
to parse top-down. I think the only candidates have to be of the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the Smalltalky
{ |a, b, c| ... }
At this point we need a bake-off, or a convincing argument against the
unusual vertical bar usage.
Here's a possible technical issue that might not apply to ES: Ruby
blocks params can't have default arguments according to
http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :
The new syntax allows to specify default values for block arguments,
since
{|a,b=1| ... }
is said to be impossible with Ruby's current LALR(1) parser, built
with bison.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-02, at 20:32EST, Peter Michaux wrote: I keep a list of all the X-ES3 compilers I encounter in the middle of the following page http://peter.michaux.ca/articles/compiling-down-to-javascript-1-5 Clarification on: OpenLaszlo is the opposite direction: JavaScript compiled into Flash. OL compiles an XML language to a subset of ECMAScript4 (or ECMAScript3 with the more mainstream parts of ES4: classes, type declarations, parameter defaults, rest args, etc.) and has multiple back-ends that compile that ECMAScript4 subset to (for example) JavaScript, ActionScript 2, or ActionScript 3. So, in a sense, we use Javascript as both an intermediate language and as an assembly language. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/2 Brendan Eich [EMAIL PROTECTED]:
I think the only candidates have to be of the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have noted),
Was there a problem with \ other than the fact that it can't easily be
turned into a binding form, à la
\userFn() {...}
... due to the \u ambiguity? Because the Smalltalk-like syntax
doesn't have an obvious binding form either.
{ userFn |a, b, c| ... }
is potentially already valid ES3, depending on the contents of '...' .
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
In that case, you have to rewrite the grammar from:
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn]
to
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn,noOR]
Make it necessary complicated.
In feature(ES4), ES may have OptionalParameter, that will cause trouble
{ |a ,b = 1 | c | d | e | f }
is
{ (|a ,b = 1 |) c | d | e | f }
or
{ (|a ,b = 1 | c) | d | e | f }
Regards,
Eric Suen
That should be a syntax error. Parenthesis should be required in that
case to avoid ambiguity: {|a, b = (1 | c)| ... }
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Despite my nostalgic longing for Smalltalk, I agree ;). But since the
purpose is to be friendlier to control abstraction patterns, it remains
important to have a *very* lightweight syntax for the no-parameter (thunk)
case. The parameter list between the ^ and the { should be optional.
Btw, I see no reason to allow a name after the ^, so I agree the name issue
by itself doesn't argue against \. But my eyes just like ^ better.
2008/12/3 Brendan Eich [EMAIL PROTECTED]
Good point -- you scored a direct hit on the Smalltalk-homage battleship
here, IMHO.
/be
On Dec 3, 2008, at 9:11 AM, Eric Suen wrote:
In that case, you have to rewrite the grammar from:
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn]
to
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn,noOR]
Make it necessary complicated.
In feature(ES4), ES may have OptionalParameter, that will cause trouble
{ |a ,b = 1 | c | d | e | f }
is
{ (|a ,b = 1 |) c | d | e | f }
or
{ (|a ,b = 1 | c) | d | e | f }
Regards,
Eric Suen
That should be a syntax error. Parenthesis should be required in that
case to avoid ambiguity: {|a, b = (1 | c)| ... }
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Brendan Eich wrote:
Allen Wirfs-Brock put his proposal, which will not shock you who know
Smalltalk or Allen, on the whiteboard:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Can't resist a historical note (which I haven't seen mentioned, but
perhaps I missed something): the Clipper language[1] in its version 5.0,
circa 1990, used this exact syntax for its code block data type, which
were in fact lexically scoped lambdas.[2]
Not surprisingly, Clipper adapted its code block syntax from Smalltalk.
Curly brackets were used instead of Smalltalk's square brackets,
presumably to fit better with existing Clipper syntax, which used curly
brackets for array definitions like {1,2,3} and square brackets for
array subscripts like x[2].
Googling for clipper code block turns up various pages with example
uses. Unfortunately, the examples that come up are all quite simple
ones, but code blocks, being lambdas, were capable of much more.
Anton
[1] Clipper was originally a compiler for Ashton-Tate's dBASE database
system/language, and was developed by the now-defunct Nantucket
Corporation. It was ultimately sold to Computer Associates.
[2] The terminology surrounding lambdas was unfamiliar to most Clipper
programmers at the time - the Clipper community referred to captured
lexical variables as detached locals. Googling for that exact term
will turn up various examples of its use in the context of Clipper and
its descendants such as Harbour and xHarbour.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/3 Michael [EMAIL PROTECTED]:
If I understand the proposals correctly, then of the following e4x:
Why do you mention e4x? I'm not familiar with it but thought it only
adds XML literals to the language.
Peter
var doc = {{|a,b,c|...}(d,e,f)}
var doc = {^(a,b,c){...}(d,e,f)}
var doc = {{||...}()}
var doc = {^(){...}()}
I honestly don't see the clarity of one over the other especially if someone
writes larger, asinine e4x.
At least with the vertical bars it has similarities/inspiration from other
languages as mentioned. This may be important for those migrating
from one of those languages. When I first saw ^(){...}, the vision that came
to my head was the pointer operator in Visual C++
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 3, 2008, at 10:45 AM, Steven Johnson wrote: On 12/2/08 7:11 PM, Neil Mix [EMAIL PROTECTED] wrote: How's this for a strawman: the choice is to follow either Objective-C or Smalltalk. Given that Objective-C and JS share syntactical roots in C, it makes more sense to follow the Objective-C precedent. I find Objective-C's syntax to be its weakest point, so I'm not sure I think either one of these is a good idea. My question is whether a new keyword (or token) is needed for lambda at all. Can't the existing function keyword be repurposed here? How? ES3 already defines function expressions as well as definitions. They are not the lambdas we seek. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/3 P T Withington [EMAIL PROTECTED]:
- prefix ^ might be confused with the infix operator of the same name
With semicolon insertion, isn't this a bigger problem?
The opening brace will need to be on the same line as the formals,
otherwise the syntax is ambiguous:
^(x) {
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
}
And, if it is on the same line, it's still bad for a top-down parser:
^(x) {
x = x * x
^(a,b,c,d,e,f,g) {x}
}
Will semicolon insertion be illegal inside a lambda body?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 2, 2008, at 6:57 PM, Brendan Eich wrote:
This loses almost all connection with the rest of the language.
Arguments are passed in a comma separated list. Wrapped in
parentheses. The Smalltalk hommage loses the parens but keeps the
commas. Any other separator is just wrong, sorry.
C# uses (a, b, c) = ... but in JS the comma operator makes that
nasty to parse top-down. I think the only candidates have to be of
the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the Smalltalky
{ |a, b, c| ... }
At this point we need a bake-off, or a convincing argument against
the unusual vertical bar usage.
As a potential intuition pump, here's an example of some existing
built-in JS control structures, and how one would write the equivalent
with either form of lambda syntax. I am assuming the ^ version allows
omitting the parameter list when empty. They are formatted to look as
much as practical like the standard syntax.
if (x 3) {
handleSmallNum(x);
} else {
handleLargeNum(x);
}
if_ (^{x 3}, ^{
handleSmallNum(x);
}, ^{
handleLargeNum(x);
});
if_ ({ || x 3}, { ||
handleSmallNum(x);
}, { ||
handleLargeNum(x);
});
while (x != null) {
x.process();
x = x.next();
}
while_ (^{x != null}, ^{
x.process();
x = x.next();
});
while_ ({ || x != null}, { ||
x.process();
x = x.next();
});
for (var i = 1; i 10; i++) {
total += vec[i];
}
for_ (^{var i = 1}, ^{i 10}, ^{i++}, ^{
total += vec[i];
});
for_ ({ || var i = 1}, { || i 10}, { || i++}, { ||
total += vec[i];
});
for (var prop in obj) {
props.push(prop);
}
forIn_ (obj, ^(prop) {
props.push(prop);
});
forIn_ (obj, { |prop|
props.push(prop);
});
Here's examples with some built in JS functions that take function
arguments:
arr.sort(function (a, b) { return a*a b*b; });
arr.sort(^(a, b) { a*a b*b });
arr.sort({ |a, b| a*a b*b });
arr.map(function (x) { return x * (x - 1); });
arr.map(^(x) { x * (x-1)});
arr.map({ |x| x * (x-1) });
function doubleBs(str) {
return str.replace(/b*/, function (substr) { return substr +
substr; });
}
function doubleBs(str) {
str.replace(/b*/, ^(substr) { substr + substr });
}
function doubleBs(str) {
str.replace(/b*/, { |substr| substr + substr });
}
I like the ^ solution better because:
1) It makes parameter lists look like function parameter lists and
call argument lists.
2) It separates the parameter from the body more clearly, which seems
more readable, especially when there lambda is passed to something
that also takes other arguments.
3) ^{ ... } seems like a less visually noisy way to express a 0-
argument thunk than { || ... }
Regards,
Maciej
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Summary of what I've read:
The syntax \(){} has a named lambda problem if the lambda name starts
with a 'u'. Depending on whitespace between the backslash and the
identifier seems like it will cause bugs
\u03c0(){}
\ u03c0(){}
The syntax ^(){} has a semicolon insertion ambiguity. What does the
following mean?
x = x
^(){}
The {||} syntax has an optional parameters problem. What does the
following mean?
{|a, b = 1 | c | d}
The other suggestion which seems to be on the table has been a new
keyword lambda or something shorter.
lambda() {}
lmbd() {}
ld() {}
Any parsing problems are already ones programmers know how to work
around. The only whinge has been that lambda is too long. Changing
from the 6 character lambda keyword to something shorter would work
technically. I think just a one character keyword would be too short
as they are commonly used for loop variables. I think the sometimes
used fn can't be used because function is already taken. Both
lmbd or ld are abbreviations which are not in the character of ES
language keywords. var is the only keyword abbreviation in ES3. All
other keywords are complete words and the word for the concept desired
here is lambda.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Yuh-Ruey Chen wrote:
Brendan Eich wrote:
C# uses (a, b, c) = ... but in JS the comma operator makes that
nasty to parse top-down. I think the only candidates have to be of
the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the Smalltalky
{ |a, b, c| ... }
At this point we need a bake-off, or a convincing argument against
the unusual vertical bar usage.
Here's a possible technical issue that might not apply to ES: Ruby
blocks params can't have default arguments according to
http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :
The new syntax allows to specify default values for block
arguments, since
{|a,b=1| ... }
is said to be impossible with Ruby's current LALR(1) parser, built
with bison.
That Ruby 1.9 page also lists yet another possible syntax:
-(a, b, ...) {...}
Using Maciej's examples:
if_ (-{x 3}, -{
handleSmallNum(x);
}, -{
handleLargeNum(x);
});
while_ (-{x != null}, -{
x.process();
x = x.next();
});
for_ (-{var i = 1}, -{i 10}, -{i++}, -{
total += vec[i];
});
forIn_ (obj, -(prop) {
props.push(prop);
});
arr.sort(-(a, b) { a*a b*b });
arr.map(-(x) { x * (x-1)});
function doubleBs(str) {
str.replace(/b*/, -(substr) { substr + substr });
}
The control abstractions just don't look right, regardless of which
lambda syntax we choose. I'd rather wait for a more powerful macro
system, instead of choosing the syntax based off how it would look in
control abstractions.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/3 Yuh-Ruey Chen [EMAIL PROTECTED]: The control abstractions just don't look right, regardless of which lambda syntax we choose. I'd rather wait for a more powerful macro system, instead of choosing the syntax based off how it would look in control abstractions. I agree completely. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Allen's lambda syntax proposal
This may be a stupid question, but is the current let expression syntax defined in JavaScript 1.7 too fundamentally different from the sought out lambda expression to be repurposed? Or would this wreak havoc on current uses? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich Sent: Wednesday, December 03, 2008 12:52 PM To: Steven Johnson Cc: Neil Mix; Maciej Stachowiak; Eric Suen; es-discuss Subject: Re: Allen's lambda syntax proposal On Dec 3, 2008, at 10:45 AM, Steven Johnson wrote: On 12/2/08 7:11 PM, Neil Mix [EMAIL PROTECTED] wrote: How's this for a strawman: the choice is to follow either Objective-C or Smalltalk. Given that Objective-C and JS share syntactical roots in C, it makes more sense to follow the Objective-C precedent. I find Objective-C's syntax to be its weakest point, so I'm not sure I think either one of these is a good idea. My question is whether a new keyword (or token) is needed for lambda at all. Can't the existing function keyword be repurposed here? How? ES3 already defines function expressions as well as definitions. They are not the lambdas we seek. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Thu, Dec 4, 2008 at 9:28 AM, Michael [EMAIL PROTECTED] wrote: This may be a stupid question, but is the current let expression syntax defined in JavaScript 1.7 too fundamentally different from the sought out lambda expression to be repurposed? Or would this wreak havoc on current uses? I had kind of a similar thought about let statements. Would it be possible to simply turn a let statement into an assignable/callable value? Would that just break too many things? would it get us at least close to the lambda functionality we seek? ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
First, let expressions as implemented in JS1.7 are ambiguous in a bottom up grammar. See https://mail.mozilla.org/pipermail/es-discuss/2008-October/007890.html Second, let statements and expressions in JS1.7 are evaluated when reached. They are not implicitly quoted for later application. Third, let is the wrong keyword if there's no need to bind a name -- as there indeed is no need with many (most?) lambda use-cases. /be On Dec 3, 2008, at 3:26 PM, Breton Slivka wrote: On Thu, Dec 4, 2008 at 9:28 AM, Michael [EMAIL PROTECTED] wrote: This may be a stupid question, but is the current let expression syntax defined in JavaScript 1.7 too fundamentally different from the sought out lambda expression to be repurposed? Or would this wreak havoc on current uses? I had kind of a similar thought about let statements. Would it be possible to simply turn a let statement into an assignable/callable value? Would that just break too many things? would it get us at least close to the lambda functionality we seek? ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 3, 2008, at 4:06 PM, Sam Ruby wrote: 2008/11/30 Brendan Eich [EMAIL PROTECTED]: At the TC39 meeting two weeks ago in Kona, we had a brief bikeshedding discussion about lambda syntax and why it matters. Has anybody given any thought to the C# (ECMA TC49) syntax? Yes, it has come up on this list. Head of thread message is: https://mail.mozilla.org/pipermail/es-discuss/2007-March/003893.html In JS, the C# syntax creates an ambiguity with the comma expression in the n-ary n 1 case. Bottom-up parsers can cope; top-down have a harder time changing their minds about what they are parsing when the see the = after the parameter list. It can be handled either way, though. Having had several threads over a couple of years on this, my impression is almost no one has championed an infix syntax such as C#'s. The prefix crowd is split between those wanting lambda vs. a one- char punctuator. The postfix (not accurate but you know what I mean) position favors the Smalltalk homage. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 3, 2008, at 6:18 PM, Maciej Stachowiak wrote:
x = x
+x
That is equivalent to
x = x + x;
so the case with ^ should not differ. (Were you testing in an
interactive REPL?)
That the case Peter showed:
x = x
^(){}
cannot be parsed as a bitwise-xor expression doesn't help in general,
if we do not want to mandate bottom-up parsing (we don't).
/be___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 12/03/2008 06:18 PM, Maciej Stachowiak wrote:
On Dec 3, 2008, at 1:23 PM, Peter Michaux wrote:
x = x
^(){}
I think this has only one possible meaning: an expression statement
consisting of an assignment of x to itself, followed by an expression
statement that creates an empty no-argument closure. Do you see another
possible meaning?
According to the wording in E-262, that's a syntax error, and your
second example:
x = x
+x
Is equivalent to |x = x + x| because, when at the 2nd |x|, the next
token is valid.
--
Blake Kaplan
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 9:36 PM, Eric Suen [EMAIL PROTECTED] wrote:
No,
^(x) is not a legal expression, so you don't have to make
block in same line, no semicolon insertion will happens here.
You're looking at the wrong part of the example. Sorry -- the
wrapper lambda is superfluous, and I should have left it out for
clarity.
Using the GNU bracing style:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
The above parses as an xor expression followed by a block, like so:
x = x * x ^ (a,b,c,d,e,f,g)
{
x
}
... which is odd, to be sure, but perfectly legal.
The second example:
x = x * x
^(a,b,c,d,e,f,g) {x}
is not ambiguous, but it's unsuitable for top-down parsing. (I tried
to underscore the point by using a long list of formals.) The parser
has to get to the opening brace before it can determine that it isn't
dealing with an xor expression.
-Jon
see this post:
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008296.html
- Original Message -
From: Jon Zeppieri [EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: P T Withington [EMAIL PROTECTED]
Cc: es-discuss [EMAIL PROTECTED]
Sent: Thursday, December 04, 2008 3:09 AM
Subject: Re: Allen's lambda syntax proposal
2008/12/3 P T Withington [EMAIL PROTECTED]:
- prefix ^ might be confused with the infix operator of the same name
With semicolon insertion, isn't this a bigger problem?
The opening brace will need to be on the same line as the formals,
otherwise the syntax is ambiguous:
^(x) {
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
}
And, if it is on the same line, it's still bad for a top-down parser:
^(x) {
x = x * x
^(a,b,c,d,e,f,g) {x}
}
Will semicolon insertion be illegal inside a lambda body?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Because it is a xor expression, for lambda, it will be
x = x * x ^ ^ (a,b,c,d,e,f,g)
{
x
}
it is same for regexp,
x = x / x /i
is not regexp, but
x = x / /x/i
is regexp
seems that ^ will confuse lots of people
- Original Message -
From: Jon Zeppieri [EMAIL PROTECTED]
To: Eric Suen [EMAIL PROTECTED]
Cc: Jon Zeppieri [EMAIL PROTECTED]; es-discuss
es-discuss@mozilla.org
Sent: Thursday, December 04, 2008 10:45 AM
Subject: Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 9:36 PM, Eric Suen [EMAIL PROTECTED] wrote:
No,
^(x) is not a legal expression, so you don't have to make
block in same line, no semicolon insertion will happens here.
You're looking at the wrong part of the example. Sorry -- the
wrapper lambda is superfluous, and I should have left it out for
clarity.
Using the GNU bracing style:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
The above parses as an xor expression followed by a block, like so:
x = x * x ^ (a,b,c,d,e,f,g)
{
x
}
... which is odd, to be sure, but perfectly legal.
The second example:
x = x * x
^(a,b,c,d,e,f,g) {x}
is not ambiguous, but it's unsuitable for top-down parsing. (I tried
to underscore the point by using a long list of formals.) The parser
has to get to the opening brace before it can determine that it isn't
dealing with an xor expression.
-Jon
see this post:
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008296.html
- Original Message -
From: Jon Zeppieri [EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: P T Withington [EMAIL PROTECTED]
Cc: es-discuss [EMAIL PROTECTED]
Sent: Thursday, December 04, 2008 3:09 AM
Subject: Re: Allen's lambda syntax proposal
2008/12/3 P T Withington [EMAIL PROTECTED]:
- prefix ^ might be confused with the infix operator of the same name
With semicolon insertion, isn't this a bigger problem?
The opening brace will need to be on the same line as the formals,
otherwise the syntax is ambiguous:
^(x) {
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
}
And, if it is on the same line, it's still bad for a top-down parser:
^(x) {
x = x * x
^(a,b,c,d,e,f,g) {x}
}
Will semicolon insertion be illegal inside a lambda body?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
It even can be writen as:
Lambda ::= '' IdentifierOpt ParametersOpt Block
IdentifierOpt ::= %Empty
| PropertyIdentifier
ParametersOpt ::= %Empty
| '(' Parameters ')'
I suggest following grammar:
Lambda ::= '' '(' Parameters ')' Block
| '' Block //if no parameters
I can comfire that this rule is no problem for a LALR(k) parser,
ES4 is not LALR(1) anyway. and I think ^ is not good for eyes, it
is too small and may confused with ~. look more like C/C++ style
a = { ... }
a = (a,b) { ... }
Yuh-Ruey Chen wrote:
Brendan Eich wrote:
C# uses (a, b, c) = ... but in JS the comma operator makes that
nasty to parse top-down. I think the only candidates have to be of
the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the Smalltalky
{ |a, b, c| ... }
At this point we need a bake-off, or a convincing argument against
the unusual vertical bar usage.
Here's a possible technical issue that might not apply to ES: Ruby
blocks params can't have default arguments according to
http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :
The new syntax allows to specify default values for block
arguments, since
{|a,b=1| ... }
is said to be impossible with Ruby's current LALR(1) parser, built
with bison.
That Ruby 1.9 page also lists yet another possible syntax:
-(a, b, ...) {...}
Using Maciej's examples:
if_ (-{x 3}, -{
handleSmallNum(x);
}, -{
handleLargeNum(x);
});
while_ (-{x != null}, -{
x.process();
x = x.next();
});
for_ (-{var i = 1}, -{i 10}, -{i++}, -{
total += vec[i];
});
forIn_ (obj, -(prop) {
props.push(prop);
});
arr.sort(-(a, b) { a*a b*b });
arr.map(-(x) { x * (x-1)});
function doubleBs(str) {
str.replace(/b*/, -(substr) { substr + substr });
}
The control abstractions just don't look right, regardless of which
lambda syntax we choose. I'd rather wait for a more powerful macro
system, instead of choosing the syntax based off how it would look in
control abstractions.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 9:52 PM, Eric Suen [EMAIL PROTECTED] wrote:
Because it is a xor expression, for lambda, it will be
x = x * x ^ ^ (a,b,c,d,e,f,g)
{
x
}
I don't understand what you're getting at. That's a syntax error. My example:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
is not a syntax error, but it also (unfortunately) doesn't contain a
lambda expression. Or am I missing something?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Yes, it doesn't contain a lambda expression, just like:
a = x
/x/i
is not same as:
a = x;
/x/i
they both right but has different meaning...
Because it is a xor expression, for lambda, it will be
x = x * x ^ ^ (a,b,c,d,e,f,g)
{
x
}
I don't understand what you're getting at. That's a syntax error. My
example:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
is not a syntax error, but it also (unfortunately) doesn't contain a
lambda expression. Or am I missing something?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 7:16 PM, Eric Suen [EMAIL PROTECTED] wrote: Yes, it doesn't contain a lambda expression, just like: a = x /x/i is not same as: a = x; /x/i they both right but has different meaning... Is adding more confusion like this in the language desirable? Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 10:16 PM, Eric Suen [EMAIL PROTECTED] wrote:
Yes, it doesn't contain a lambda expression, just like:
a = x
/x/i
is not same as:
a = x;
/x/i
they both right but has different meaning...
Okay -- so we agree. In that case, it's clear that your proposed syntax:
(a,b,c) {...}
has the same problem, right? Any valid ES3 infix operator will have
the same problem, if we use it as a prefix lambda operator.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 2, 2008, at 5:31 AM, Aaron Gray wrote:
i still prefer 'lambda (a,b,c) { ... }' as it is readable to the
uninitiated and can then at least give a handle for someone to lookup.
I think the truly uninitiated would not find lambda any more obvious
in meaning than \ or ||.
Regards,
Maciej
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 2, 2008, at 5:03 AM, Eric Suen wrote:
What about:
.(a,b,c) {}
or
..(a,b,c) {}
or
...(a,b,c) {}
As long as we're giving the bikeshed a few more coats of paint,
Objective-C is adding block-like closures with ^ as the prefix, so we
could take inspiration from that:
^(a, b, c) { ... }
I'm not sure if this would introduce ambiguities in the grammar since
^ is already an operator; I tend to think not, because + and -
manage to be both unary and binary operators without ambiguity. ^
also has a slight resemblance to the greek lambda, which is the reason
Haskell uses \. This could support named lambdas without risk of
clashing with the \u escape.
Regards,
Maciej
Regards,
Eric Suen
- Original Message -
From: Allen Wirfs-Brock
[EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: Maciej Stachowiak
[EMAIL PROTECTED]; Brendan
Eich [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 6:32 AM
Subject: RE: Allen's lambda syntax proposal
{|a,b,c| ...} or
\(a,b,c) {...} or
{\(a,b,c) ...}
I could be happy with any of them and can find pros and cons with
each. I
think the high order bit should be that a concise closure syntax is
possible
and desirable. If we agree on that then we just need to pick one.
The use of \ slightly bothers me because it is takes a character
that now is
exclusively used in the lexical (token) grammar ( Unicode escapes,
string
escapes, line continuations) and gives it syntactic significance.
This is
probably not a fatal flaw but it would mean that the lexical uses
of \ become
less visually distinctive.
Whether someone prefers the parameters inside or outside the braces
may be
another symptom of whether they are focusing on control abstraction
or
functional abstraction. With control abstraction you use closures
as blocks
of code that form pieces of the abstraction so it may seems natural
from that
perspective for the braces to surround the entire block. This is
closer to
the syntactic feel of the built-in control statements. If you are
building
functional abstractions then you are probably thinking about the
closures as
functions so placing the formals before the body seems natural.
It's fairly common with control abstractions to use 0 argument
closures so the
readability of {||...}, \(){...}, and {\()...} are probably also
worth
considering. Ideally a 0 argument closure would be written as
{...} but
resolution of the syntactic ambiguities between object literal and
such
closures (particularly in the presence of statement labels) seems too
difficult to contend with.
My focus on supporting control abstraction may be mute. While
Smalltalk and
Ruby show that power of such abstraction mechanisms it takes more
than just a
concise block-like closure notation to achieve it. The complexity
of the BGGA
Java closure proposal (and the associated controversy) shows how
hard it can
be to fully support control abstraction using C syntax (and, of
course, Java
semantics).
Allen
-Original Message-
From: [EMAIL PROTECTED]
[mailto:es-discuss-
[EMAIL PROTECTED] On Behalf Of Maciej
Stachowiak
Sent: Monday, December 01, 2008 12:59 PM
To: Brendan Eich
Cc: [EMAIL PROTECTED]
Subject: Re: Allen's lambda syntax proposal
On Nov 29, 2008, at 10:30 PM, Brendan Eich wrote:
At the TC39 meeting two weeks ago in Kona, we had a brief
bikeshedding discussion about lambda syntax and why it matters.
Observation: blocks in Smalltalk being lightweight means users
don't
mind writing them for control abstractions, compared to JS
functions
in ES3. In Smalltalk, ignoring JS, it's hard to beat [ and ] as
overhead, although one must count the message selector and its
punctuation too.
Allen Wirfs-Brock put his proposal, which will not shock you who
know Smalltalk or Allen, on the whiteboard:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I like the brevity, but having the formals inside the block and in
||
delimiters seems like it will look weird in an ECMAScript program.
For
function declarations the parameters go in parentheses, and for
calls
(presumably also for lambda calls), the arguments go in parens. If
brevity is important, why not lift the lambda syntax from modern
pure
functional languages:
\(a, b, c) { ... }
That's backslash as a lambda operator. This has one more character
than your version, but will make formals and parameters look the
same
for functions, lambdas, and calls, and will avoid putting the
formals
inside the body which I think is confusing and visually hard to
scan.
Regards,
Maciej
___
Es-discuss mailing list
[EMAIL PROTECTED]
https://mail.mozilla.org/listinfo/es-discuss
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-02, at 11:48EST, Maciej Stachowiak wrote:
As long as we're giving the bikeshed a few more coats of paint,
Objective-C is adding block-like closures with ^ as the prefix, so
we could take inspiration from that:
^(a, b, c) { ... }
That's cute. Mnemonic for Λ (capital λ), also 'pointer-ish',
implying an object reference.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 2, 2008, at 5:31 AM, Aaron Gray wrote:
i still prefer 'lambda (a,b,c) { ... }' as it is readable to the
uninitiated and can then at least give a handle for someone to lookup.
I think the truly uninitiated would not find lambda any more obvious in
meaning than \ or ||.
People can google lambda they cannot google \, or ||. Also keywords
seem better suited to Javascript syntax.
Aaron
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
'~' is ambiguities usless you using two NO_LINE_BREAK like:
'~' NO_LINE_BREAK (...) NO_LINE_BREAK {...}
'.' may not looks good, but it does not introduce new token
like '\' or 'lambda'
Regards,
Eric Suen
- Original Message -
From: Maciej Stachowiak [EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: Eric Suen [EMAIL PROTECTED]
Cc: Brendan Eich [EMAIL PROTECTED];
es-discuss [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2008 12:48 AM
Subject: Re: Allen's lambda syntax proposal
On Dec 2, 2008, at 5:03 AM, Eric Suen wrote:
What about:
.(a,b,c) {}
or
..(a,b,c) {}
or
...(a,b,c) {}
As long as we're giving the bikeshed a few more coats of paint, Objective-C
is adding block-like closures with ^ as the prefix, so we could take
inspiration from that:
^(a, b, c) { ... }
I'm not sure if this would introduce ambiguities in the grammar since ^ is
already an operator; I tend to think not, because + and - manage to be
both unary and binary operators without ambiguity. ^ also has a slight
resemblance to the greek lambda, which is the reason Haskell uses \. This
could support named lambdas without risk of clashing with the \u escape.
Regards,
Maciej
Regards,
Eric Suen
- Original Message -
From: Allen Wirfs-Brock
[EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: Maciej Stachowiak
[EMAIL PROTECTED];
Brendan
Eich
[EMAIL PROTECTED]
Cc:
[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 6:32 AM
Subject: RE: Allen's lambda syntax proposal
{|a,b,c| ...} or
\(a,b,c) {...} or
{\(a,b,c) ...}
I could be happy with any of them and can find pros and cons with each. I
think the high order bit should be that a concise closure syntax is
possible
and desirable. If we agree on that then we just need to pick one.
The use of \ slightly bothers me because it is takes a character that now
is
exclusively used in the lexical (token) grammar ( Unicode escapes, string
escapes, line continuations) and gives it syntactic significance. This is
probably not a fatal flaw but it would mean that the lexical uses of \
become
less visually distinctive.
Whether someone prefers the parameters inside or outside the braces may be
another symptom of whether they are focusing on control abstraction or
functional abstraction. With control abstraction you use closures as
blocks
of code that form pieces of the abstraction so it may seems natural from
that
perspective for the braces to surround the entire block. This is closer
to
the syntactic feel of the built-in control statements. If you are building
functional abstractions then you are probably thinking about the closures
as
functions so placing the formals before the body seems natural.
It's fairly common with control abstractions to use 0 argument closures so
the
readability of {||...}, \(){...}, and {\()...} are probably also worth
considering. Ideally a 0 argument closure would be written as {...} but
resolution of the syntactic ambiguities between object literal and such
closures (particularly in the presence of statement labels) seems too
difficult to contend with.
My focus on supporting control abstraction may be mute. While Smalltalk
and
Ruby show that power of such abstraction mechanisms it takes more than
just
a
concise block-like closure notation to achieve it. The complexity of the
BGGA
Java closure proposal (and the associated controversy) shows how hard it
can
be to fully support control abstraction using C syntax (and, of course,
Java
semantics).
Allen
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:es-discuss-
[EMAIL PROTECTED] On
Behalf Of Maciej
Stachowiak
Sent: Monday, December 01, 2008 12:59 PM
To: Brendan Eich
Cc:
[EMAIL PROTECTED]
Subject: Re: Allen's lambda syntax proposal
On Nov 29, 2008, at 10:30 PM, Brendan Eich wrote:
At the TC39 meeting two weeks ago in Kona, we had a brief
bikeshedding discussion about lambda syntax and why it matters.
Observation: blocks in Smalltalk being lightweight means users don't
mind writing them for control abstractions, compared to JS functions
in ES3. In Smalltalk, ignoring JS, it's hard to beat [ and ] as
overhead, although one must count the message selector and its
punctuation too.
Allen Wirfs-Brock put his proposal, which will not shock you who
know Smalltalk or Allen, on the whiteboard:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I like the brevity, but having the formals inside the block and in ||
delimiters seems like it will look weird in an ECMAScript program. For
function declarations the parameters go in parentheses, and for calls
(presumably also for lambda calls), the arguments go in parens. If
brevity is important, why not lift the lambda syntax from modern pure
functional languages:
\(a, b, c) { ... }
That's
Re: Allen's lambda syntax proposal
On 1 Dec, 2008, at 10:18 PM, Peter Michaux wrote:
One problem is if the argument list needs to take two lambdas, then
where would the second lambda go? One inside the arguments list and
one after? Why is one lambda more important or deserving of a special
place compared with the other lambda?
I've been writing JS a long time and I don't frequently find myself
wanting to pass more than one function/lambda to another function. On
the (very) rare occasion when I do, I suspect I'm not calling a
control-structure-like function. Then I'd be comfortable passing two
lambdas as arguments.
Since the goal seems to be allowing control structures like Smalltalk
(yay!), how about specifying that one lambda that follows a function
invocation is passed as the final argument to the invocation. You can
write the invocation:
withNode(node, {|n| ... })
and I'll write it as:
withNode(node)
{ |n|
...
}
Some API designers won't like the trailing lambda syntax and some
will. Then we end up with inconsistent APIs.
I think if lambdas can be specified outside the parameter list, API
designers will feel pressure from those who use their APIs to adopt
the trailing lambda style. This would only be a significant issue when
the API is expecting a single lambda.
And regarding using the full term lambda in the syntax, I think I'm
not alone that I'd have a hard time adopting lambdas over functions
without a significant improvement in syntax -- and changing the name
from function to lambda isn't significant. Especially considering that
the initial implementations of lambdas might not hold a significant
performance improvement over functions.
Of course, it would also be super cool if I could write something like:
{ |n|
hide: function()
{
n.style.display='none';
},
show: function()
{
n.style.display='';
},
etc...
}
Of course if I didn't have to pay the cost of instantiating a new
function for every object instance, that would make something like
this worthwhile.
Jeff
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/2 Jeff Watkins [EMAIL PROTECTED]: Since the goal seems to be allowing control structures like Smalltalk (yay!), how about specifying that one lambda that follows a function invocation is passed as the final argument to the invocation. Brendan seemed to reject the idea that this could be passed as the first argument to a constructor, so that this could be explicitly named, on the grounds that the parameter lists would not match. I agree that parameter lists should match. I was just asking. https://mail.mozilla.org/pipermail/es-discuss/2008-November/008203.html If a trailing block outside the parameter list is passed as the last argument, then what happens when there is a rest parameter as the last argument in the parameter list? It gets a bit messy to determine if the last argument passed in was the last argument of some rest parameters or an optional trailing lambda. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Tue, Dec 2, 2008 at 10:36 AM, Aaron Gray [EMAIL PROTECTED]
wrote:
On Dec 2, 2008, at 5:31 AM, Aaron Gray wrote:
i still prefer 'lambda (a,b,c) { ... }' as it is readable to the
uninitiated and can then at least give a handle for someone to lookup.
I think the truly uninitiated would not find lambda any more obvious in
meaning than \ or ||.
People can google lambda they cannot google \, or ||. Also keywords
seem better suited to Javascript syntax.
Aaron
Is the argument that the uninitiated should be able understand complex code
concepts via a google search of the thing that they don't understand?
There are already all kinds of things that one couldn't understand via a
simple google search for something in the code, and which people of various
levels of experience might experience: Object literals come to mind or ||
and as guard/default, ? as ternary if, or even ++ or %= and there
are plenty more things which might or might not have a readily identifiable
thing to allow someone to google for like default values, coercion rules, or
scoping concepts.
Google is an excellent tool, but I don't think that it's necessarily a great
way to interpret code into something understandable to the uninitiated.
Doesn't seem like a good deciding factor.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Peter Michaux wrote: 2008/12/2 Jeff Watkins [EMAIL PROTECTED]: Since the goal seems to be allowing control structures like Smalltalk (yay!), how about specifying that one lambda that follows a function invocation is passed as the final argument to the invocation. Brendan seemed to reject the idea that this could be passed as the first argument to a constructor, so that this could be explicitly named, on the grounds that the parameter lists would not match. I agree that parameter lists should match. I was just asking. https://mail.mozilla.org/pipermail/es-discuss/2008-November/008203.html If a trailing block outside the parameter list is passed as the last argument, then what happens when there is a rest parameter as the last argument in the parameter list? It gets a bit messy to determine if the last argument passed in was the last argument of some rest parameters or an optional trailing lambda. Will ES-Harmony have labelled arguments? If it does then both of these problems go away, since the block argument can have a standard label, and similarly for the this argument. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Maciej Stachowiak wrote:
As long as we're giving the bikeshed a few more coats of paint,
Objective-C is adding block-like closures with ^ as the prefix, so we
could take inspiration from that:
^(a, b, c) { ... }
I'm not sure if this would introduce ambiguities in the grammar since
^ is already an operator; I tend to think not, because + and -
manage to be both unary and binary operators without ambiguity.
Correct, it would be grammatically unambiguous. It might still be
mildly confusing, though (unlike unary minus, which is related to
subtraction by -x = 0-x, lambda abstraction is unrelated to bitwise
exclusive-or). But any notation for lambdas is likely to be mildly
confusing to the uninitiated.
^ also has a slight resemblance to the greek lambda, which is the
reason Haskell uses \.
^ also has some historical relevance:
Felice Cardone, J. Roger Hindley,
History of Lambda-calculus and Combinatory Logic
2006, Swansea University Mathematics Department
Research Report No. MRRS-05-06.
http://www-maths.swan.ac.uk/staff/jrh/papers/JRHHislamWeb.pdf
# (By the way, why did Church choose the notation λ? In [Church, 1964, §2]
# he stated clearly that it came from the notation x̂ used for
# class-abstraction by Whitehead and Russell, by first modifying x̂ to
# ∧x to distinguish function-abstraction from class-abstraction, and
# then changing ∧ to λ for ease of printing. This origin was also
# reported in [Rosser, 1984, p.338]. On the other hand, in his later years
# Church told two enquirers that the choice was more accidental: a symbol
# was needed and λ just happened to be chosen.)
[Church, 1964] A. Church, 7 July 1964. Unpublished letter to Harald Dickson.
[Rosser, 1984] J. B. Rosser. Highlights of the history of the lambda
calculus. Annals of the History of Computing, 6:337–349, 1984.
[If your email client doesn't display the above correctly:
x̂ is an x with a hat operator (similar to a circumflex) above it.
∧ is an upward-pointing wedge.
λ is a lowercase Greek lambda.]
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
I've been casually following this discussion, and I can't help but rail
against the inherent limitations of ES's C heritage.
From the control abstraction standpoint, although {||...} gets close to
that goal, the discrepancy from true {...} control syntax stands out
like a sore thumb to me. And others have already pointed out the rest
params issue. I think it would be best to just stick with the functional
standpoint - lambdas as lightweight functions. Solving the control
abstraction should be dealt with in another less hacky way. There are
languages that can integrate lambdas easily with control abstraction;
unfortunately, ES is not one of them.
(As a side note, sometimes I wonder if all this talk about sugar is
moot, because I suspect more and more languages will start compiling
down to ES.)
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Tue, Dec 2, 2008 at 4:08 PM, Yuh-Ruey Chen [EMAIL PROTECTED] wrote: (As a side note, sometimes I wonder if all this talk about sugar is moot, because I suspect more and more languages will start compiling down to ES.) I keep a list of all the X-ES3 compilers I encounter in the middle of the following page http://peter.michaux.ca/articles/compiling-down-to-javascript-1-5 This list has grown quite long with the majority of popular and revered languages included. I wonder how many companies are using these technologies and if that group is growing very quickly. ES is good enough for most developers that I think the attraction is low given the extra difficulties in development process and compiled code speed (i.e. trampolines for tail calls are slow.) If ES is the byte code of the browser then the better ES is, the better the compiled code can be. Tail calls and continuations would be valuable additions to ES. Threads are probably a trickier issue. If these features cannot be added to ES directly then it would be great if ES ran on a VM which exposed these features. Then all languages could compile to that VM's byte code. I vaguely recall a web page where Brendan Eich listed some of these features as part of JavaScript 3 (perhaps ES5). I can't find the page at the moment. The really unfortunate part is the time lines to reach such goals are likely very long...available in 95% of browsers in the year 2020? Who knows? Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 2, 2008, at 6:26 PM, Eric Suen wrote:
I really don't think prefix is neccessary, what about:
(a;b;c) {...}
or
(a:b:c) {...}
2nd one may have problem with '::' or TypedIdentifier in ES4.
This loses almost all connection with the rest of the language.
Arguments are passed in a comma separated list. Wrapped in
parentheses. The Smalltalk hommage loses the parens but keeps the
commas. Any other separator is just wrong, sorry.
C# uses (a, b, c) = ... but in JS the comma operator makes that nasty
to parse top-down. I think the only candidates have to be of the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the Smalltalky
{ |a, b, c| ... }
At this point we need a bake-off, or a convincing argument against the
unusual vertical bar usage.
/be
Regards,
Eric Suen
- Original Message -
From: Maciej Stachowiak
[EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: Brendan Eich [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 4:59 AM
Subject: Re: Allen's lambda syntax proposal
On Nov 29, 2008, at 10:30 PM, Brendan Eich wrote:
At the TC39 meeting two weeks ago in Kona, we had a brief
bikeshedding
discussion about lambda syntax and why it matters. Observation:
blocks in
Smalltalk being lightweight means users don't mind writing them
for control
abstractions, compared to JS functions in ES3. In Smalltalk,
ignoring JS,
it's hard to beat [ and ] as overhead, although one must count
the message
selector and its punctuation too.
Allen Wirfs-Brock put his proposal, which will not shock you who
know
Smalltalk or Allen, on the whiteboard:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I like the brevity, but having the formals inside the block and in ||
delimiters seems like it will look weird in an ECMAScript program.
For
function declarations the parameters go in parentheses, and for calls
(presumably also for lambda calls), the arguments go in parens. If
brevity is
important, why not lift the lambda syntax from modern pure
functional
languages:
\(a, b, c) { ... }
That's backslash as a lambda operator. This has one more character
than your
version, but will make formals and parameters look the same for
functions,
lambdas, and calls, and will avoid putting the formals inside the
body which
I think is confusing and visually hard to scan.
Regards,
Maciej
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Tue, Dec 2, 2008 at 7:11 PM, Neil Mix [EMAIL PROTECTED] wrote: How's this for a strawman: the choice is to follow either Objective-C or Smalltalk. Or Scheme which, after all, was the first Lisp with lexical scoping and first-class lambdas. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I only
use it half as often as I should.
Chris
___
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 2:06 AM, Chris Pine [EMAIL PROTECTED] wrote:
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I only use it
half as often as I should.
What is to be made of that last sentence? If you have a choice between
the following, The lambda version is still shorter.
function() {}
lambda() {}
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Peter Michaux wrote:
On Mon, Dec 1, 2008 at 2:06 AM, Chris Pine [EMAIL PROTECTED] wrote:
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I only use it
half as often as I should.
What is to be made of that last sentence? If you have a choice between
the following, The lambda version is still shorter.
function() {}
lambda() {}
{||}
Not from where I'm sitting... 'lambda' is shorter than 'function', but
'{||}' is shortest of all... or perhaps I don't understand you?
Chris
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-11-30, at 01:30EST, Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I would rather have a more literate syntax, lest we degenerate to
where practically any comic book blasphemy is a valid program.
(BTW, I'm pretty sure I have that same Byte issue, in a similar box,
with a similar musty smell, _and_ the blue book. Back then,
worrying that 'line noise' or the death throes of your modem hanging
up would write code for you was a legitimate concern. Today, it is
just my old eyes that might gloss over `{||` and wonder why the `var`s
in that block are not visible in the enclosing function...)
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-01, at 11:30EST, Mark S. Miller wrote:
On Mon, Dec 1, 2008 at 7:31 AM, P T Withington [EMAIL PROTECTED] wrote:
On 2008-11-30, at 01:30EST, Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I would rather have a more literate syntax, lest we degenerate to
where
practically any comic book blasphemy is a valid program.
(BTW, I'm pretty sure I have that same Byte issue, in a similar
box, with a
similar musty smell, _and_ the blue book. Back then, worrying
that 'line
noise' or the death throes of your modem hanging up would write
code for you
was a legitimate concern. Today, it is just my old eyes that might
gloss
over `{||` and wonder why the `var`s in that block are not visible
in the
enclosing function...)
Since it's a lambda, the 'var's will be visible in the enclosing
function.
Eh? So:
function () {
var foo = 42;
{|| var foo = 3; }
return foo;
}
and:
function () {
var foo = 42;
{ var foo = 3; }
return foo;
}
Give the same answer?
The point of having a very compact syntax for lambda is too make it
pleasant
to write control abstractions, as one does casually in Smalltalk.
With the
verbose lambda spelling, people will avoid those, or invent macro
systems
(as Scheme programmers do) mostly so they can avoid seeing all those
extra
lambda letters in the code.
Think of lambdas as blocks plus a bit more, rather than function
minus a
bit. Viewed this way, their block-like syntax is a virtue.
I agree with the goal of compactness. I just don't like it to be too
compact. Call me a curmudgeon. I don't like that `not` is spelt `!`
or that it is so easy to make a one-letter misspelling of `eql` and
end up with `setq` either.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
