Origins of lambda notation (was: Allen's lambda syntax proposal)

[David-Sarah Hopwood]

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.


# (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

[Dave Herman]

"^" 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

Re: Allen's lambda syntax proposal

[Brendan Eich]

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

[Lex Spoon]

On Wed, Dec 17, 2008 at 9:53 PM, Yuh-Ruey Chen  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

[Yuh-Ruey Chen]

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.

Personally, since I'm not responsible for any ES/JS implementation, I
don't care about this difficulty, but a quick search for "ecmascript
lalr" reveals that there are such existing parsers.

P.S. Take everything I say with a grain of salt, since I'm not really an
expert on parsing.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Lex Spoon]

On Mon, Dec 1, 2008 at 3:19 PM, Allen Wirfs-Brock
 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

[David-Sarah Hopwood]

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

[P T Withington]

On 2008-12-08, at 00:59EST, David-Sarah Hopwood wrote:


What is the advantage of this syntax over ^(a, b) {a+b}, for example?


I prefer the above, if it were unambiguous.


Ditto for P T Withington's proposal of ^{(a, b) a+b}.


The above, I think, is.  Because it is currently invalid.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Brendan Eich]

The auditors idea is good; we've talked about it in the context of  
Harmony.


Of course, ES4 had optional types, but over time ES4 lost the idea of  
a normative optional static checker. It's not clear on the web *when*  
you check. Cormac Flanagan proposed checking "when it seemed like a  
good time" -- when script and page loads stabilized into some web app  
cohort of sources that seemed not to be loading more code at the moment.


Optional offline static analyses can be powerful tools. They don't  
even need soundness to be useful -- Mozilla's experience in C++ bears  
this out (http://blog.mozilla.com/tglek/). The same trade-offs may  
apply to a Harmonious optional annotation system, if it's used well in  
real code.


/be

On Dec 8, 2008, at 8:36 AM, Mark S. Miller wrote:


On Mon, Dec 8, 2008 at 7:20 AM, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
On Mon, Dec 8, 2008 at 4:01 AM, Yuh-Ruey Chen <[EMAIL PROTECTED]>  
wrote:

> Breton Slivka wrote:
>> 2) It would be really nice to have a callable value that was
>> garaunteed not to have side effects.
>
> 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).

Without a static type system, there's very little you can do.
Sure, you could abandon the proof requirement and turn it into an
assertion, so that if F is annotated as "mutation-free" and if, at
runtime, it tries to perform an assignment, an exception is thrown.
But this doesn't work so well for other computational effects.
Throwing an exception itself is an effect, and it would be pointless
to throw an exception when your code illegally attempts... to throw an
exception.

Non-termination is an effect, and it's notoriously immune to runtime  
checks.


I/O effects are possibly the most interesting from a practical
perspective, but they're outside the scope of the ES standard.

E's auditors   are a mostly non-static approach that can verify many properties,  
including side effects per se including IO effects, but not  
including throws and non-termination. Joe-E's similar, but non- 
extensible and static auditor system , has been used to verify some nice purity properties.


I am not ready to propose any such thing for Harmony at this time.

--
   Cheers,
   --MarkM
___
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

[Mark S. Miller]

On Mon, Dec 8, 2008 at 7:20 AM, Jon Zeppieri <[EMAIL PROTECTED]> wrote:

> On Mon, Dec 8, 2008 at 4:01 AM, Yuh-Ruey Chen <[EMAIL PROTECTED]> wrote:
> > Breton Slivka wrote:
> >> 2) It would be really nice to have a callable value that was
> >> garaunteed not to have side effects.
> >
> > 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).
>
> Without a static type system, there's very little you can do.
> Sure, you could abandon the proof requirement and turn it into an
> assertion, so that if F is annotated as "mutation-free" and if, at
> runtime, it tries to perform an assignment, an exception is thrown.
> But this doesn't work so well for other computational effects.
> Throwing an exception itself is an effect, and it would be pointless
> to throw an exception when your code illegally attempts... to throw an
> exception.
>
> Non-termination is an effect, and it's notoriously immune to runtime
> checks.
>
> I/O effects are possibly the most interesting from a practical
> perspective, but they're outside the scope of the ES standard.
>

E's auditors  <
http://wiki.erights.org/wiki/Guard-based_auditing> are a mostly non-static
approach that can verify many properties, including side effects per se
including IO effects, but not including throws and non-termination. Joe-E's
similar, but non-extensible and static auditor system <
http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf>, has been used to
verify some nice purity properties.

I am not ready to propose any such thing for Harmony at this time.

-- 
   Cheers,
   --MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Jon Zeppieri]

On Mon, Dec 8, 2008 at 4:01 AM, Yuh-Ruey Chen <[EMAIL PROTECTED]> 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).


Without a static type system, there's very little you can do.  For
example, let's say you wanted a guarantee that a call to some function
F doesn't mutate any variables.  A simple analysis can determine
(conservatively) that F's own code doesn't perform any assignments,
but the problem is that you also have to prove the same property for
the entire possible call tree rooted at F.  So, if F is passed a
function and (potentially) calls it, that function has to be proven
pure, as well.

Sure, you could abandon the proof requirement and turn it into an
assertion, so that if F is annotated as "mutation-free" and if, at
runtime, it tries to perform an assignment, an exception is thrown.
But this doesn't work so well for other computational effects.
Throwing an exception itself is an effect, and it would be pointless
to throw an exception when your code illegally attempts... to throw an
exception.

Non-termination is an effect, and it's notoriously immune to runtime checks.

I/O effects are possibly the most interesting from a practical
perspective, but they're outside the scope of the ES standard.

-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Yuh-Ruey Chen]

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

[David-Sarah Hopwood]

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

[Yuh-Ruey Chen]

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]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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?

Regards

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.)

--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


- --
Alex Russell
[EMAIL PROTECTED]
[EMAIL PROTECTED] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFJPJWhz3jiQlnDlyMRApB7AKC4b0P/dw07uo1vpgPkl/wBbC6z4ACg4tnK
SC5TGDclT3euwl/h9YWpJa4=
=6c8Y
-END PGP SIGNATURE-
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[P T Withington]

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

[David-Sarah Hopwood]

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

[David-Sarah Hopwood]

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

[Brendan Eich]

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

[Peter Michaux]

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"
and "const let". A variable being constant or not is orthogonal to its
scoping and should be controlled independently.

>  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;

Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[David-Sarah Hopwood]

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

[Eric Suen]

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

[David-Sarah Hopwood]

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'.

Exceptions, OTOH, are implementable without an explicit check on each
function call.

Just this performance issue on its own wouldn't be significant -- it
might matter in a language that is otherwise highly optimizable, but
not in ECMAScript. I'll address the safety issue separately.

-- 
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]

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

[Jon Zeppieri]

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

[Maciej Stachowiak]

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

[Jon Zeppieri]

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

[Maciej Stachowiak]

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

[Eric Suen]

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

[Jon Zeppieri]

On Fri, Dec 5, 2008 at 11:07 PM, David-Sarah Hopwood
<[EMAIL PROTECTED]> wrote:
> Maciej Stachowiak wrote:
>> On Dec 5, 2008, at 10:00 AM, Jon Zeppieri wrote:
>>
>>> A label is an escape continuation.  Once control has returned past the
>>> point where the continuation was captured, it's dead, and it can't be
>>> resumed.
>>
>> So return from a lambda is sometimes but not always a runtime error?
>
> That in itself does not seem much of a problem (it doesn't seem to be
> in Smalltalk or E).
>
>> Other times it can return through multiple levels of function calls
>> without raising an exception? That seems pretty bad for ease of
>> understanding and for performance of implementations.
>
> I agree, although I would express this as a safety issue: the safety
> hazard is that you may call a lambda without expecting it to perform
> a jump within the calling scope. The performance issue is that *all*
> calls that are within the scope of a labelled statement or loop must
> check for an escape.

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.


>
> There is a possibility for solving both of these issues while still
> allowing all of the suggested uses of lambdas. It involves permitting
> a given call to perform an escape (that is, break, continue or return)
> only if it is explicitly marked as being able to do so. If an unmarked
> call would escape, then it instead throws an exception.
>
> For example (syntax intended only as a strawman; I know it is
> incompatible to add an 'escape' keyword):
>
>  CallExpression :
>...
>'escape' CallExpression Arguments
>
> Then a user-defined 'while' could be written as:
>
>  const _while = \(cond, body) {
>// escapes from 'cond' are intentionally disallowed;
>// only 'body' can escape.
>if (cond()) { escape body(); escape while(cond, body); }
>  };
>

Can the call to cond throw?  If so, what did you gain from this?

-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Breton Slivka]

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! :)


This idea appeals to me for a couple reasons:

1) I have occassionally found myself using and repeating fairly
complex expressions in the conditions of if statements. Functions
would work, but I tend to avoid them out of a (possibly misplaced?)
Perception that refactoring the expressions isn't quite worth the
performance cost of an extra function call. This is bad code practice
I will admit, but if there were something that didn't have quite the
performance cost, and could promote DRYness in expressions, that would
be great.

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.




2008/12/6 David-Sarah Hopwood <[EMAIL PROTECTED]>:

> To type λ, I usually have to cut-and-paste it from somewhere else,
> which is quite inconvenient. But more importantly, having a
> non-US-ASCII character in the basic syntax means that parsing is
> dependent on recognising character encoding accurately. In practice,
> that is very hit-and-miss, with files' encoding often being labelled
> or guessed incorrectly. Currently, the effects of this are restricted
> to programs that use non-US-ASCII characters in strings without
> escaping, and therefore only the files containing such programs have
> to be labelled accurately.
>
> (I wish it weren't so, and often the reason why it is so is inexcusably
> poor attention to standards by application writers, but we have to be
> realistic.)
>
> --
> David-Sarah Hopwood


I thought as such, fair enough. It was just naive and boundless
optimism that in 5-10 years time, this would cease to be an issue, but
this is magical thinking.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[David-Sarah Hopwood]

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

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> David-Sarah Hopwood wrote:
>> '-' and '/' already have a similar issue of possibly unexpected
>> parsing when they occur at the beginning of a line.
> 
> and '+', '++', '--', '(', and (for a different reason) 'function'.

Correction: not '++' or '--', because they are "restricted productions".

-- 
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]

David-Sarah Hopwood wrote:
> Peter Michaux wrote:
>> The syntax ^(){} has a semicolon insertion ambiguity. What does the
>> following mean?
>>
>>   x = x
>>   ^(){}
> 
> It's not ambiguous; it would mean "x = x^(){}", which is (in this case)
> a syntax error.
> 
> '-' and '/' already have a similar issue of possibly unexpected
> parsing when they occur at the beginning of a line.

and '+', '++', '--', '(', and (for a different reason) 'function'.

Actually, the case of '(' is arguably worse than '^', because '('
at the start of an ExpressionStatement is very common:

  x = x
  (foo)

(parsed as 'x = x(foo);', but intended to be 'x = x; (foo);').

> Note that programmers who never deliberately rely on semicolon insertion
> will not be surprised by this example; they will consider writing
> "x = x" without an terminating semicolon to have been their mistake.

-- 
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]

Peter Michaux wrote:
> The syntax ^(){} has a semicolon insertion ambiguity. What does the
> following mean?
> 
>   x = x
>   ^(){}

It's not ambiguous; it would mean "x = x^(){}", which is (in this case)
a syntax error.

'-' and '/' already have a similar issue of possibly unexpected
parsing when they occur at the beginning of a line. It's just that
it is rare to intend to start an ExpressionStatement with a unary
minus or a regexp literal, so this doesn't occur very often in
practice. It's not clear how often programmers will intend to start
an ExpressionStatement with a lambda, although I can see that this
might be more common.

Note that programmers who never deliberately rely on semicolon insertion
will not be surprised by this example; they will consider writing
"x = x" without an terminating semicolon to have been their mistake.

-- 
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]

Peter Michaux wrote:
> Summary of what I've read:
> 
> The syntax \(){} has a named lambda problem if the lambda name starts
> with a 'u'.

Why do we need named lambdas (or more precisely, why do we need them
to be named by the lambda syntax)? A lambda can always be named by
assigning it to a 'const' variable.

-- 
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]

Maciej Stachowiak wrote:
> On Dec 5, 2008, at 10:00 AM, Jon Zeppieri wrote:
> 
>> A label is an escape continuation.  Once control has returned past the
>> point where the continuation was captured, it's dead, and it can't be
>> resumed.
> 
> So return from a lambda is sometimes but not always a runtime error?

That in itself does not seem much of a problem (it doesn't seem to be
in Smalltalk or E).

> Other times it can return through multiple levels of function calls
> without raising an exception? That seems pretty bad for ease of
> understanding and for performance of implementations.

I agree, although I would express this as a safety issue: the safety
hazard is that you may call a lambda without expecting it to perform
a jump within the calling scope. The performance issue is that *all*
calls that are within the scope of a labelled statement or loop must
check for an escape.

There is a possibility for solving both of these issues while still
allowing all of the suggested uses of lambdas. It involves permitting
a given call to perform an escape (that is, break, continue or return)
only if it is explicitly marked as being able to do so. If an unmarked
call would escape, then it instead throws an exception.

For example (syntax intended only as a strawman; I know it is
incompatible to add an 'escape' keyword):

  CallExpression :
...
'escape' CallExpression Arguments

Then a user-defined 'while' could be written as:

  const _while = \(cond, body) {
// escapes from 'cond' are intentionally disallowed;
// only 'body' can escape.
if (cond()) { escape body(); escape while(cond, body); }
  };

and a use of '_while' would be:

  foo: escape _while(\{bar}, \{
...
if (baz) break foo;
  });

This doesn't impede the use of lambdas in control abstractions or
in desugaring, because those uses can easily call the lambda using
an 'escape' call. Nor does it impede "lambda as the new function",
because uses of lambda in place of function won't attempt to 'break',
'continue' or 'return' (and that can be made a static error in the
syntactic contexts where lambda is intended to replace functions,
such as in my suggestion for object literals).

It does introduce the syntactic inconvience of having to call control
abstractions using 'escape' (or whatever syntax is used for these
calls). For use of lambda to desugar built-in constructs, this is
not an issue.

If at some point macros were added (even a very limited form of
macros), then the syntactic inconvience could be alleviated, and
nothing would have to be changed in the semantics of lambda at
that point.

> If you do this:
> 
> [1 2 3].map(lambda (x) { return x + 1; })
> 
> I think it would be better for that to be a syntax error than to make
> the containing function return 2.

In my proposal above, that would be a dynamic error (the call to the
lambda from 'map' would throw an exception).

This case could in principle be detected statically; that is, passing
a lambda expression *directly* as an argument without using 'escape'
would be a static error.

Unfortunately it's not possible to detect all of the errors introduced
by this proposal statically, because the lambda could have been obtained
from anywhere, so without static typing (or making lambdas not-first-class,
which I don't recommend), it's not possible to know in all cases when a
lambda is being passed as an argument.

> It seems to me the current design prioritizes lambda as a desugaring
> construct or building block for imperative-style control flow, over use
> as an actual first-class function. I assume break and continue inside a
> lambda have similar issues.

They do, but the proposal above addresses 'break', 'continue' and 'return'
together.

It may be considered too complicated, too restrictive, or not sufficiently
easy to understand. I'm undecided about that, although it does solve both
the safety and performance objections to escape continuations, and the
semantics are easy to specify.

-- 
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]

Maciej Stachowiak wrote:
> 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?

The lambda would return from F (specifically, from the activation of F
in which the lambda was created), but since that activation of F has
already returned when the lambda is called, this is a dynamic error --
presumably, resulting in an exception.

What that example doesn't show it is whether the exception is thrown
only when the offending 'return' statement is executed, or when a
a lambda that *could* execute an offending return is entered.

Also note that this example could be affected by the resolution of
the "leakage" issue, if we decide for example that the syntax
'lambda(n) { return x + n; }' returns from the lambda rather than
the enclosing function (which it could do without necessarily
violating the Tennent Correspondence rationale for lambdas, as long
as there is another syntax that doesn't bind '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

[David-Sarah Hopwood]

Breton Slivka wrote:
> 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.
[...]
>> It's still too hard to type.
>
> http://picasaweb.google.com/eileen.world.traveler/EileenBestOfGreece#5139474493916668850

Using a Greek keyboard might, for the sake of argument, also be feasible
for users whose main language is English, but not for those who require
other keyboard layouts in order to type their main language.

-- 
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]

Breton Slivka wrote:
> On Fri, Dec 5, 2008 at 7:49 AM, David-Sarah Hopwood
> <[EMAIL PROTECTED]> wrote:
>> 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".
> 
> this may be a stupid question, but why? Is it really so impossible to
> have λ(a,b,c){}  ?
> You guys seem to have no trouble typing it.

To type λ, I usually have to cut-and-paste it from somewhere else,
which is quite inconvenient. But more importantly, having a
non-US-ASCII character in the basic syntax means that parsing is
dependent on recognising character encoding accurately. In practice,
that is very hit-and-miss, with files' encoding often being labelled
or guessed incorrectly. Currently, the effects of this are restricted
to programs that use non-US-ASCII characters in strings without
escaping, and therefore only the files containing such programs have
to be labelled accurately.

(I wish it weren't so, and often the reason why it is so is inexcusably
poor attention to standards by application writers, but we have to be
realistic.)

-- 
David-Sarah Hopwood

___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Brendan Eich]

On Dec 5, 2008, at 2:57 PM, Michael Day wrote:

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.


Good points.



Anyway, these three options look good to me:

(1) Expression lambdas: lambdas whose body is an expression.

var x = lambda(y, z) y + z


Would need parens around the body, if this is a primary expression,  
else reduce-reduce conflict.



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! :)


We could mandate tail recursive call sites in the spec so people could  
count on it cross-browser.


http://bugs.ecmascript.org/ticket/215
http://bugs.ecmascript.org/ticket/215 (not be necessary for expression- 
enclosed tail calls)



(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.


I must agree, since this looks like function syntax, with a new  
introductory keyword. TCP must yield.



(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.


Agreed. Past efforts to add just this kind of block have failed to get  
anywhere.



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.


Including Dave to get his thoughts, in case he is reading es-discuss  
in a digest or deferred fashion.


/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Michael Day]

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

[Brendan Eich]

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

[Eugene Lazutkin]

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 minimiz

RE: Allen's lambda syntax proposal

[Allen Wirfs-Brock]

>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

[Brendan Eich]

On Dec 5, 2008, at 11:47 AM, Allen Wirfs-Brock wrote:

Given, the nature of the language we have (as opposed to the  
language we wish we had) I might choose class-like abstractions  
based upon object literals over conflicting features for support  
concise expression of control abstraction.


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.


/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Allen's lambda syntax proposal

[Allen Wirfs-Brock]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:es-discuss-
>[EMAIL PROTECTED] On Behalf Of Mark Miller
>...
>In other words, "let" is the new "var", but "lambda" is less than the
>new "function" and more than the new block. That's why I argued
>against David-Sarah's otherwise very pleasant pattern for writing an
>enhanced object literal to express high integrity class-like
>abstractions.
>...

In which case perhaps we should abandon this style of lambda and work harder at 
developing a concise construct that is a reformed function.

I'll have to hunt down David-Sarah's proposal which I haven't seen as this is a 
direction for object literals is something I have also thought about and found 
attractive.

Given, the nature of the language we have (as opposed to the language we wish 
we had) I might choose class-like abstractions based upon object literals over 
conflicting features for support concise expression of control abstraction.

Allen
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Mark Miller]

On Fri, Dec 5, 2008 at 10:22 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> It seems to me the current design prioritizes lambda as a desugaring
> construct or building block for imperative-style control flow, over use as
> an actual first-class function. I assume break and continue inside a lambda
> have similar issues.


Yes. I was initially hopeful that lambdas would be usable in general
as a replacement for function, in much the same way that we are all
hopeful than const and let are usable as a replacement for var.
However, after talking about the hazards Waldemar raised of leaking
completion value, I think your statement above is accurate. It results
in the sugared language having the same two levels as in Smalltalk and
E: The "function" level[1], where a "return" is required in order to
provide a value to one's caller, and a "lambda" level, recommended for
use only for desugaring and control abstraction, where completion
values leak, and where "return" remains bound to the enclosing
"function".

In other words, "let" is the new "var", but "lambda" is less than the
new "function" and more than the new block. That's why I argued
against David-Sarah's otherwise very pleasant pattern for writing an
enhanced object literal to express high integrity class-like
abstractions.

[1] ES-Harmony's "function" like Smalltalk's method like E's "to"
ES-Harmony's "lambda" like Smalltalk's block "[" like E's "method".
ES-Harmony's "return" like Smalltalk's "^" like E's "return"

-- 
Text by me above is hereby placed in the public domain

Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Maciej Stachowiak]

On Dec 5, 2008, at 10:00 AM, Jon Zeppieri wrote:

On Fri, Dec 5, 2008 at 12:39 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:


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?


Based on the lambda and return-to-label strawmen, It's an error.  Dave
presents a desugaring of function to lambda, where each function body
is given a label at the bottom:

lambda(x0,...,xn,...$rest) {
   let $THIS = thisRegister;
   let arguments = makeAlias([[lambda() x1, lambda($x1) x1 = $x1],
  ...,
  [lambda() xn, lambda($xn) xn = $xn]],
 $rest);
   $RETURN: { Body; void 0 }
}


'return e' without a label desugars to:

  return : $RETURN e

But, from the return-to-label strawman:

"The dynamic return point associated with the label must still be live
when the return statement is invoked; otherwise it is a dynamic error,
i.e., an exception is raised."

A label is an escape continuation.  Once control has returned past the
point where the continuation was captured, it's dead, and it can't be
resumed.


So return from a lambda is sometimes but not always a runtime error?  
Other times it can return through multiple levels of function calls  
without raising an exception? That seems pretty bad for ease of  
understanding and for performance of implementations. If you do this:


[1 2 3].map(lambda (x) { return x + 1; })

I think it would be better for that to be a syntax error than to make  
the containing function return 2.


It seems to me the current design prioritizes lambda as a desugaring  
construct or building block for imperative-style control flow, over  
use as an actual first-class function. I assume break and continue  
inside a lambda have similar issues.


Regards,
Maciej


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Jon Zeppieri]

On Fri, Dec 5, 2008 at 12:39 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> 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?

Based on the lambda and return-to-label strawmen, It's an error.  Dave
presents a desugaring of function to lambda, where each function body
is given a label at the bottom:

lambda(x0,...,xn,...$rest) {
let $THIS = thisRegister;
let arguments = makeAlias([[lambda() x1, lambda($x1) x1 = $x1],
   ...,
   [lambda() xn, lambda($xn) xn = $xn]],
  $rest);
$RETURN: { Body; void 0 }
}


'return e' without a label desugars to:

   return : $RETURN e

But, from the return-to-label strawman:

"The dynamic return point associated with the label must still be live
when the return statement is invoked; otherwise it is a dynamic error,
i.e., an exception is raised."

A label is an escape continuation.  Once control has returned past the
point where the continuation was captured, it's dead, and it can't be
resumed.

-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Maciej Stachowiak]

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

[Michael Day]

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

[Brendan Eich]

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!)

/be


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Brendan Eich]

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

[Michael Day]

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

[Brendan Eich]

On Dec 4, 2008, at 7:09 PM, Michael Day wrote:


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?


I've created a bikeshedding monster, I admit. It was not entirely  
misdirection on my part :-P.


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.



(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.


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.


It's not bad, even now, but it may be that something shorter, or at  
least spelled different from any word derived from function (fun, fn)  
-- precisely because lambdas as proposed are not like functions in  
many ways: arguments, this, return, completion-value.


/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

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 operator"ness, 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

[Michael Day]

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

[Brendan Eich]

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 <>
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

[Breton Slivka]

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

[Breton Slivka]

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 <>
in your ide.

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?
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Brendan Eich]

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

[Brendan Eich]

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

[Felix]

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

[Eugene Lazutkin]

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.

2) Why is it important for a lambda to have an optional name? What's
wrong with using a function, if we want a name? IMHO lambda should have
the minimalistic syntax.

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.

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.

Thanks,

Eugene

Mark S. Miller wrote:
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 conte nders saddled with "binary 
operator"ness, drop back and concede. "\" has taken the lead


--
   Cheers,
   --MarkM




___
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

[Jon Zeppieri]

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

[Peter Michaux]

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

[Brendan Eich]

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...


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.


True enough. And 'lambda' is likelier to be in use in web JS as an  
identifier than λ, at a guess.


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.


/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Allen's lambda syntax proposal

[Michael]

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

[Breton Slivka]

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

[Jon Zeppieri]

[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

[Brendan Eich]

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

[Breton Slivka]

On Fri, Dec 5, 2008 at 7:49 AM, David-Sarah Hopwood
<[EMAIL PROTECTED]> wrote:
> 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

this may be a stupid question, but why? Is it really so impossible to
have λ(a,b,c){}  ?
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. Nearly all computers on the planet have a greek alphabet
installed on them. And keep in mind, we're not designing a language
for tomorrow. We're designing a language for 10 years from now. λ
could be way more convenient to enter by then, particularly if it's in
an upcoming spec for a programming language.

I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Brendan Eich]

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

[David-Sarah Hopwood]

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

[David-Sarah Hopwood]

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

[Jon Zeppieri]

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

[P T Withington]

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.



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...)


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[David-Sarah Hopwood]

Jon Zeppieri wrote:
> 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
>   }
> }

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.

> Will semicolon insertion be illegal inside a lambda body?

That's worth considering. It does not prevent lambdas from being used
to desugar other constructs, because semicolon insertion would be
performed on the original program before desugaring.

-- 
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]

Yuh-Ruey Chen wrote:
> Eric Suen wrote:
>> 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)| ... }

Yuck. The restrictions on 'in' are bad enough; this is essentially the
same kind of ambiguity in another context. Requiring expressions
containing '|' to be parenthesized would impose the same degree of
grammar complexity overhead again as that imposed by 'NoIn':

  ArgumentInitialiser :
= ExpressionNoBar
= ( Expression )

... unless all default argument initialisers have to be parenthesized,
but that is just ugly.

-- 
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]

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.

There's an ambiguity here that is independent of what kind of parser
is used (I don't know whether it is the same issue as in Ruby).
Consider:

  {|a=1|2, b|c}

Is the argument list (a = 1|2, b) with body {c}, or is it
(a = 1) with body {2, b|c}?

This ambiguity could be resolved by restricting expressions used as
default argument initialisers, but it is not clear why they should
be restricted, given that other possible concrete syntaxes for
lambda do not have this problem.

IMHO this does count as a "convincing argument against the unusual
vertical bar usage", if we want default arguments (and I think we do).

However, I'd like to suggest that it may be premature to be deciding
on the concrete syntax of lambda, without knowing its abstract syntax.
(The issue that MarkM raised about unintentionally leaking a value
that happens to be evaluated in tail position, for example, needs to
be dealt with at the abstract syntax level.) The same point applies
to the syntax of object literals.

That will require some notation for discussing abstract syntax, on
which I'll start another thread.

-- 
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Brendan Eich]

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

[Peter Michaux]

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 operator"ness, 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

[Mark S. Miller]

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 operator"ness, 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

[Maciej Stachowiak]

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

[Maciej Stachowiak]

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

[Michael]

Would this form also be ambiguous and/or too difficult to parse?

{=> 9*9}()
{a => a+b}(12)
{(a,b) => a+b}(12,6)


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[André Bargull]

On 12/4/2008 3:15 PM, 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.



And if you just execute the lambda expression? For example the following 
code is legal Javascript:


var a = b = 0;
{(a,b)
a+b}(10, 5)
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[P T Withington]

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

Allen's lambda syntax proposal

[André Bargull]

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

[Eric Suen]

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

Re: Allen's lambda syntax proposal

[Jon Zeppieri]

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

[Peter Michaux]

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

[Eric Suen]

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

[Jon Zeppieri]

On Wed, Dec 3, 2008 at 10:00 PM, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> 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.

Sorry -- I take that back.  It's not (or likely would not be) a syntax
error, but I still don't understand its relevance.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Jon Zeppieri]

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

[Eric Suen]

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

[Eric Suen]

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" 

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

[Jon Zeppieri]

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

[Eric Suen]

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