Re: Allen's lambda syntax proposal
In feature(ES4), ES may have OptionalParameter, that will cause trouble
{ |a ,b = 1 | c | d | e | f }
is
{ (|a ,b = 1 |) c | d | e | f }
or
{ (|a ,b = 1 | c) | d | e | f }
Regards,
Eric Suen
- Original Message -
From: Yuh-Ruey Chen [EMAIL PROTECTED]
To: Brendan Eich [EMAIL PROTECTED]
Cc: Eric Suen [EMAIL PROTECTED]; Maciej Stachowiak
[EMAIL PROTECTED]; es-discuss
es-discuss@mozilla.org
Sent: Wednesday, December 03, 2008 8:56 PM
Subject: Re: Allen's lambda syntax proposal
Brendan Eich wrote:
C# uses (a, b, c) = ... but in JS the comma operator makes that nasty
to parse top-down. I think the only candidates have to be of the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the Smalltalky
{ |a, b, c| ... }
At this point we need a bake-off, or a convincing argument against the
unusual vertical bar usage.
Here's a possible technical issue that might not apply to ES: Ruby
blocks params can't have default arguments according to
http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :
The new syntax allows to specify default values for block arguments,
since
{|a,b=1| ... }
is said to be impossible with Ruby's current LALR(1) parser, built
with bison.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-02, at 20:32EST, Peter Michaux wrote: I keep a list of all the X-ES3 compilers I encounter in the middle of the following page http://peter.michaux.ca/articles/compiling-down-to-javascript-1-5 Clarification on: OpenLaszlo is the opposite direction: JavaScript compiled into Flash. OL compiles an XML language to a subset of ECMAScript4 (or ECMAScript3 with the more mainstream parts of ES4: classes, type declarations, parameter defaults, rest args, etc.) and has multiple back-ends that compile that ECMAScript4 subset to (for example) JavaScript, ActionScript 2, or ActionScript 3. So, in a sense, we use Javascript as both an intermediate language and as an assembly language. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/2 Brendan Eich [EMAIL PROTECTED]:
I think the only candidates have to be of the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have noted),
Was there a problem with \ other than the fact that it can't easily be
turned into a binding form, à la
\userFn() {...}
... due to the \u ambiguity? Because the Smalltalk-like syntax
doesn't have an obvious binding form either.
{ userFn |a, b, c| ... }
is potentially already valid ES3, depending on the contents of '...' .
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
In that case, you have to rewrite the grammar from:
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn]
to
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn,noOR]
Make it necessary complicated.
In feature(ES4), ES may have OptionalParameter, that will cause trouble
{ |a ,b = 1 | c | d | e | f }
is
{ (|a ,b = 1 |) c | d | e | f }
or
{ (|a ,b = 1 | c) | d | e | f }
Regards,
Eric Suen
That should be a syntax error. Parenthesis should be required in that
case to avoid ambiguity: {|a, b = (1 | c)| ... }
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Despite my nostalgic longing for Smalltalk, I agree ;). But since the
purpose is to be friendlier to control abstraction patterns, it remains
important to have a *very* lightweight syntax for the no-parameter (thunk)
case. The parameter list between the ^ and the { should be optional.
Btw, I see no reason to allow a name after the ^, so I agree the name issue
by itself doesn't argue against \. But my eyes just like ^ better.
2008/12/3 Brendan Eich [EMAIL PROTECTED]
Good point -- you scored a direct hit on the Smalltalk-homage battleship
here, IMHO.
/be
On Dec 3, 2008, at 9:11 AM, Eric Suen wrote:
In that case, you have to rewrite the grammar from:
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn]
to
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn,noOR]
Make it necessary complicated.
In feature(ES4), ES may have OptionalParameter, that will cause trouble
{ |a ,b = 1 | c | d | e | f }
is
{ (|a ,b = 1 |) c | d | e | f }
or
{ (|a ,b = 1 | c) | d | e | f }
Regards,
Eric Suen
That should be a syntax error. Parenthesis should be required in that
case to avoid ambiguity: {|a, b = (1 | c)| ... }
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Brendan Eich wrote:
Allen Wirfs-Brock put his proposal, which will not shock you who know
Smalltalk or Allen, on the whiteboard:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Can't resist a historical note (which I haven't seen mentioned, but
perhaps I missed something): the Clipper language[1] in its version 5.0,
circa 1990, used this exact syntax for its code block data type, which
were in fact lexically scoped lambdas.[2]
Not surprisingly, Clipper adapted its code block syntax from Smalltalk.
Curly brackets were used instead of Smalltalk's square brackets,
presumably to fit better with existing Clipper syntax, which used curly
brackets for array definitions like {1,2,3} and square brackets for
array subscripts like x[2].
Googling for clipper code block turns up various pages with example
uses. Unfortunately, the examples that come up are all quite simple
ones, but code blocks, being lambdas, were capable of much more.
Anton
[1] Clipper was originally a compiler for Ashton-Tate's dBASE database
system/language, and was developed by the now-defunct Nantucket
Corporation. It was ultimately sold to Computer Associates.
[2] The terminology surrounding lambdas was unfamiliar to most Clipper
programmers at the time - the Clipper community referred to captured
lexical variables as detached locals. Googling for that exact term
will turn up various examples of its use in the context of Clipper and
its descendants such as Harbour and xHarbour.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/3 Michael [EMAIL PROTECTED]:
If I understand the proposals correctly, then of the following e4x:
Why do you mention e4x? I'm not familiar with it but thought it only
adds XML literals to the language.
Peter
var doc = {{|a,b,c|...}(d,e,f)}
var doc = {^(a,b,c){...}(d,e,f)}
var doc = {{||...}()}
var doc = {^(){...}()}
I honestly don't see the clarity of one over the other especially if someone
writes larger, asinine e4x.
At least with the vertical bars it has similarities/inspiration from other
languages as mentioned. This may be important for those migrating
from one of those languages. When I first saw ^(){...}, the vision that came
to my head was the pointer operator in Visual C++
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 3, 2008, at 10:45 AM, Steven Johnson wrote: On 12/2/08 7:11 PM, Neil Mix [EMAIL PROTECTED] wrote: How's this for a strawman: the choice is to follow either Objective-C or Smalltalk. Given that Objective-C and JS share syntactical roots in C, it makes more sense to follow the Objective-C precedent. I find Objective-C's syntax to be its weakest point, so I'm not sure I think either one of these is a good idea. My question is whether a new keyword (or token) is needed for lambda at all. Can't the existing function keyword be repurposed here? How? ES3 already defines function expressions as well as definitions. They are not the lambdas we seek. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/3 P T Withington [EMAIL PROTECTED]:
- prefix ^ might be confused with the infix operator of the same name
With semicolon insertion, isn't this a bigger problem?
The opening brace will need to be on the same line as the formals,
otherwise the syntax is ambiguous:
^(x) {
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
}
And, if it is on the same line, it's still bad for a top-down parser:
^(x) {
x = x * x
^(a,b,c,d,e,f,g) {x}
}
Will semicolon insertion be illegal inside a lambda body?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 2, 2008, at 6:57 PM, Brendan Eich wrote:
This loses almost all connection with the rest of the language.
Arguments are passed in a comma separated list. Wrapped in
parentheses. The Smalltalk hommage loses the parens but keeps the
commas. Any other separator is just wrong, sorry.
C# uses (a, b, c) = ... but in JS the comma operator makes that
nasty to parse top-down. I think the only candidates have to be of
the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the Smalltalky
{ |a, b, c| ... }
At this point we need a bake-off, or a convincing argument against
the unusual vertical bar usage.
As a potential intuition pump, here's an example of some existing
built-in JS control structures, and how one would write the equivalent
with either form of lambda syntax. I am assuming the ^ version allows
omitting the parameter list when empty. They are formatted to look as
much as practical like the standard syntax.
if (x 3) {
handleSmallNum(x);
} else {
handleLargeNum(x);
}
if_ (^{x 3}, ^{
handleSmallNum(x);
}, ^{
handleLargeNum(x);
});
if_ ({ || x 3}, { ||
handleSmallNum(x);
}, { ||
handleLargeNum(x);
});
while (x != null) {
x.process();
x = x.next();
}
while_ (^{x != null}, ^{
x.process();
x = x.next();
});
while_ ({ || x != null}, { ||
x.process();
x = x.next();
});
for (var i = 1; i 10; i++) {
total += vec[i];
}
for_ (^{var i = 1}, ^{i 10}, ^{i++}, ^{
total += vec[i];
});
for_ ({ || var i = 1}, { || i 10}, { || i++}, { ||
total += vec[i];
});
for (var prop in obj) {
props.push(prop);
}
forIn_ (obj, ^(prop) {
props.push(prop);
});
forIn_ (obj, { |prop|
props.push(prop);
});
Here's examples with some built in JS functions that take function
arguments:
arr.sort(function (a, b) { return a*a b*b; });
arr.sort(^(a, b) { a*a b*b });
arr.sort({ |a, b| a*a b*b });
arr.map(function (x) { return x * (x - 1); });
arr.map(^(x) { x * (x-1)});
arr.map({ |x| x * (x-1) });
function doubleBs(str) {
return str.replace(/b*/, function (substr) { return substr +
substr; });
}
function doubleBs(str) {
str.replace(/b*/, ^(substr) { substr + substr });
}
function doubleBs(str) {
str.replace(/b*/, { |substr| substr + substr });
}
I like the ^ solution better because:
1) It makes parameter lists look like function parameter lists and
call argument lists.
2) It separates the parameter from the body more clearly, which seems
more readable, especially when there lambda is passed to something
that also takes other arguments.
3) ^{ ... } seems like a less visually noisy way to express a 0-
argument thunk than { || ... }
Regards,
Maciej
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Revisiting Decimal (was: Prioritized list of Decimal method additions)
I saw the meeting minutes, and got a debrief from Allen yesterday. I'm still unclear on how to proceed with Decimal, even if the new target is Harmony. Waldemar's issues were raised and responded to prior to Kona: https://mail.mozilla.org/pipermail/es-discuss/2008-November/008074.html Quick summary: there are at least eight sections with typos and transcription errors. By transcription errors, I mean places where the prose doesn't match the output of the code that I posted previously. Those are embarrassing, but at this point moot. Pratap has already excised Decimal from the spec. What are we left with relative to the the following output from the code that I wrote? http://intertwingly.net/stories/2008/09/20/estest.html Relative to that output, I've heard two issues. The first was no user visible cohorts. The issue is Waldemar's insistence that ES is irretrievably broken if array lookup for x[1.10m] respects the trailing zero. IIRC, Brendan's position was a more pragmatic one, namely that small integers (like, say, up to 10**20th) are the only values for which toString must avoid both exponential notation and trailing zeros, other values shouldn't get in the way of doing the right thing. That would have been fine, but unfortunately he couldn't make the meeting (something I definitely understand). Mike and I weren't then, and still aren't happy about conceding to Waldemar's position on this one, but at Redmond we did with the understanding that with that concession, Decimal was in. The second was the duplication between Math.min and Decimal.min. I was operating under the if it ain't broken, don't fix it guidelines. To date, Math.min *always* returns a Number, never an Object. Waldemar apparently feels that people will call the wrong function. To me, this is a you say N-EEE-THER, I say N-EYE-THER issue. If the consensus is that Math.min should be changed and Decimal.min should be removed, that's a pretty quick fix. So now the question is: where are we now? - Sam Ruby On Sat, Sep 20, 2008 at 8:57 PM, Sam Ruby [EMAIL PROTECTED] wrote: Sam Ruby wrote: Previous discussions focused on operators and type/membership related builtin functions (i.e., typeof and instanceof). Here's a prioritized list of functions provided by IEEE 754-2008 and/or the decNumber implementation. The actual number of a and a- methods is fairly small, particularly once you remove ones that are available in ECMAScript via other means. Updated test results including these methods can be found here: http://intertwingly.net/stories/2008/09/20/estest.html - Sam Ruby - - - - - Absolute requirement, and must be implemented as an 'instance' method (for most of the others, the difference between a 'static' and 'instance' method is negotiable): * atoString Available as prefix or infix operators, or as builtin functions, may not need to be duplicated as named Decimal methods: * aadd * acompare * acopy * acopyNegate * adivide * aisFinite * aisNaN * amultiply * aremainder * asubtract Essential 754, not available as infix operator, so must be made available as a named method. For consistency with Math, abs, max, and min should be 'static' methods: * aquantize * acopyAbs[called abs] * amax * amin Very useful functions which are not in 754 for various reasons; strongly recommend include: * a- divideInteger [extremely handy] * a- digits [= significant digits] * a- reduce [often asked for] * a- toEngString[really handy in practice] * a- getExponent[esp. if no compareTotal] Other 754 operations that are less essential but would probably add later anyway. 'b+' are a subset that are especially useful in practice: * b FMA * b canonical * b compareSignal * b+ compareTotal * b compareTotalMag * b copySign * b isCanonical * b+ isInfinite * b+ isInteger * b isNormal * b+ isSignaling [if sNaNs supported] * b+ isSignalling[ ] * b+ isSigned * b isSubnormal * b+ isZero * b logB * b maxMag * b minMag * b nextMinus * b nextPlus * b radix * b remainderNear * b+ sameQuantum * b scaleB * b+ setExponent * b toInt32 * b toInt32Exact * b+ toIntegralExact [perhaps only one of these] * b+ toIntegralValue [] * b toUInt32 * b toUInt32Exact Probably drop because conflict with ES bitwise logical ops: *c and (as digitAnd) *c invert (as digitInvert) *c or (as digitOr) *c rotate *c shift *c xor (as digitXor) And, finally, not needed: (The first two of these are 754 but don't fit with ES)
Re: Allen's lambda syntax proposal
Summary of what I've read:
The syntax \(){} has a named lambda problem if the lambda name starts
with a 'u'. Depending on whitespace between the backslash and the
identifier seems like it will cause bugs
\u03c0(){}
\ u03c0(){}
The syntax ^(){} has a semicolon insertion ambiguity. What does the
following mean?
x = x
^(){}
The {||} syntax has an optional parameters problem. What does the
following mean?
{|a, b = 1 | c | d}
The other suggestion which seems to be on the table has been a new
keyword lambda or something shorter.
lambda() {}
lmbd() {}
ld() {}
Any parsing problems are already ones programmers know how to work
around. The only whinge has been that lambda is too long. Changing
from the 6 character lambda keyword to something shorter would work
technically. I think just a one character keyword would be too short
as they are commonly used for loop variables. I think the sometimes
used fn can't be used because function is already taken. Both
lmbd or ld are abbreviations which are not in the character of ES
language keywords. var is the only keyword abbreviation in ES3. All
other keywords are complete words and the word for the concept desired
here is lambda.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Yuh-Ruey Chen wrote:
Brendan Eich wrote:
C# uses (a, b, c) = ... but in JS the comma operator makes that
nasty to parse top-down. I think the only candidates have to be of
the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the Smalltalky
{ |a, b, c| ... }
At this point we need a bake-off, or a convincing argument against
the unusual vertical bar usage.
Here's a possible technical issue that might not apply to ES: Ruby
blocks params can't have default arguments according to
http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :
The new syntax allows to specify default values for block
arguments, since
{|a,b=1| ... }
is said to be impossible with Ruby's current LALR(1) parser, built
with bison.
That Ruby 1.9 page also lists yet another possible syntax:
-(a, b, ...) {...}
Using Maciej's examples:
if_ (-{x 3}, -{
handleSmallNum(x);
}, -{
handleLargeNum(x);
});
while_ (-{x != null}, -{
x.process();
x = x.next();
});
for_ (-{var i = 1}, -{i 10}, -{i++}, -{
total += vec[i];
});
forIn_ (obj, -(prop) {
props.push(prop);
});
arr.sort(-(a, b) { a*a b*b });
arr.map(-(x) { x * (x-1)});
function doubleBs(str) {
str.replace(/b*/, -(substr) { substr + substr });
}
The control abstractions just don't look right, regardless of which
lambda syntax we choose. I'd rather wait for a more powerful macro
system, instead of choosing the syntax based off how it would look in
control abstractions.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/3 Yuh-Ruey Chen [EMAIL PROTECTED]: The control abstractions just don't look right, regardless of which lambda syntax we choose. I'd rather wait for a more powerful macro system, instead of choosing the syntax based off how it would look in control abstractions. I agree completely. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Allen's lambda syntax proposal
This may be a stupid question, but is the current let expression syntax defined in JavaScript 1.7 too fundamentally different from the sought out lambda expression to be repurposed? Or would this wreak havoc on current uses? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich Sent: Wednesday, December 03, 2008 12:52 PM To: Steven Johnson Cc: Neil Mix; Maciej Stachowiak; Eric Suen; es-discuss Subject: Re: Allen's lambda syntax proposal On Dec 3, 2008, at 10:45 AM, Steven Johnson wrote: On 12/2/08 7:11 PM, Neil Mix [EMAIL PROTECTED] wrote: How's this for a strawman: the choice is to follow either Objective-C or Smalltalk. Given that Objective-C and JS share syntactical roots in C, it makes more sense to follow the Objective-C precedent. I find Objective-C's syntax to be its weakest point, so I'm not sure I think either one of these is a good idea. My question is whether a new keyword (or token) is needed for lambda at all. Can't the existing function keyword be repurposed here? How? ES3 already defines function expressions as well as definitions. They are not the lambdas we seek. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Thu, Dec 4, 2008 at 9:28 AM, Michael [EMAIL PROTECTED] wrote: This may be a stupid question, but is the current let expression syntax defined in JavaScript 1.7 too fundamentally different from the sought out lambda expression to be repurposed? Or would this wreak havoc on current uses? I had kind of a similar thought about let statements. Would it be possible to simply turn a let statement into an assignable/callable value? Would that just break too many things? would it get us at least close to the lambda functionality we seek? ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
First, let expressions as implemented in JS1.7 are ambiguous in a bottom up grammar. See https://mail.mozilla.org/pipermail/es-discuss/2008-October/007890.html Second, let statements and expressions in JS1.7 are evaluated when reached. They are not implicitly quoted for later application. Third, let is the wrong keyword if there's no need to bind a name -- as there indeed is no need with many (most?) lambda use-cases. /be On Dec 3, 2008, at 3:26 PM, Breton Slivka wrote: On Thu, Dec 4, 2008 at 9:28 AM, Michael [EMAIL PROTECTED] wrote: This may be a stupid question, but is the current let expression syntax defined in JavaScript 1.7 too fundamentally different from the sought out lambda expression to be repurposed? Or would this wreak havoc on current uses? I had kind of a similar thought about let statements. Would it be possible to simply turn a let statement into an assignable/callable value? Would that just break too many things? would it get us at least close to the lambda functionality we seek? ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 3, 2008, at 4:06 PM, Sam Ruby wrote: 2008/11/30 Brendan Eich [EMAIL PROTECTED]: At the TC39 meeting two weeks ago in Kona, we had a brief bikeshedding discussion about lambda syntax and why it matters. Has anybody given any thought to the C# (ECMA TC49) syntax? Yes, it has come up on this list. Head of thread message is: https://mail.mozilla.org/pipermail/es-discuss/2007-March/003893.html In JS, the C# syntax creates an ambiguity with the comma expression in the n-ary n 1 case. Bottom-up parsers can cope; top-down have a harder time changing their minds about what they are parsing when the see the = after the parameter list. It can be handled either way, though. Having had several threads over a couple of years on this, my impression is almost no one has championed an infix syntax such as C#'s. The prefix crowd is split between those wanting lambda vs. a one- char punctuator. The postfix (not accurate but you know what I mean) position favors the Smalltalk homage. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Revisiting Decimal (was: Prioritized list of Decimal method additions)
On Dec 3, 2008, at 1:04 PM, Sam Ruby wrote: I saw the meeting minutes, and got a debrief from Allen yesterday. I'm still unclear on how to proceed with Decimal, even if the new target is Harmony. Waldemar's issues were raised and responded to prior to Kona: https://mail.mozilla.org/pipermail/es-discuss/2008-November/ 008074.html Did this address Waldemar's other message? https://mail.mozilla.org/pipermail/es-discuss/2008-September/007631.html I also don't see a reply to David-Sarah Hopwood's message: https://mail.mozilla.org/pipermail/es-discuss/2008-November/008078.html What are we left with relative to the the following output from the code that I wrote? http://intertwingly.net/stories/2008/09/20/estest.html Looks like we may need Waldemar to comment or elaborate on his last post (first link above). Relative to that output, I've heard two issues. The first was no user visible cohorts. The issue is Waldemar's insistence that ES is irretrievably broken if array lookup for x[1.10m] respects the trailing zero. IIRC, Brendan's position was a more pragmatic one, namely that small integers (like, say, up to 10**20th) are the only values for which toString must avoid both exponential notation and trailing zeros, other values shouldn't get in the way of doing the right thing. That would have been fine, but unfortunately he couldn't make the meeting (something I definitely understand). Mike and I weren't then, and still aren't happy about conceding to Waldemar's position on this one, but at Redmond we did with the understanding that with that concession, Decimal was in. This Redmond-meeting result did sound like a breakthrough in any event. Was it memorialized with spec changes? The second was the duplication between Math.min and Decimal.min. I was operating under the if it ain't broken, don't fix it guidelines. To date, Math.min *always* returns a Number, never an Object. Waldemar apparently feels that people will call the wrong function. To me, this is a you say N-EEE-THER, I say N-EYE-THER issue. If the consensus is that Math.min should be changed and Decimal.min should be removed, that's a pretty quick fix. This doesn't seem like a big problem, by itself. So now the question is: where are we now? The two general kinds of problems from the Kona meeting were: 1. Spec bugs, not just typos but material ones that couldn't be fixed by that meeting, which was the deadline for major additions to ES3.1 not already in the spec. 2. Future-proofing arguments including: do we need Decimal wrappers for decimal primitives. I know we've been over this before, but it still is an open issue in TC39. I'd appreciate Waldemar's comments; and those of other TC39ers too, of course. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Revisiting Decimal (was: Prioritized list of Decimal method additions)
Brendan Eich wrote: On Dec 3, 2008, at 1:04 PM, Sam Ruby wrote: I saw the meeting minutes, and got a debrief from Allen yesterday. I'm still unclear on how to proceed with Decimal, even if the new target is Harmony. Waldemar's issues were raised and responded to prior to Kona: https://mail.mozilla.org/pipermail/es-discuss/2008-November/008074.html Did this address Waldemar's other message? https://mail.mozilla.org/pipermail/es-discuss/2008-September/007631.html The no user visible cohorts addressed that particular concern. I also don't see a reply to David-Sarah Hopwood's message: https://mail.mozilla.org/pipermail/es-discuss/2008-November/008078.html Given that the spec text has been removed, the way I would like to proceed is to first come to an agreement on the semantics we desire, and for that I would like to solicit comments on the output produced by the implementation I produced. While I agree that Decimal wrappers are useless; but I think that consistency argues that they need to be there (in fact, I was talked into putting them there); again I refer back to the output produced and solicit comments. What are we left with relative to the the following output from the code that I wrote? http://intertwingly.net/stories/2008/09/20/estest.html Looks like we may need Waldemar to comment or elaborate on his last post (first link above). Relative to that output, I've heard two issues. The first was no user visible cohorts. The issue is Waldemar's insistence that ES is irretrievably broken if array lookup for x[1.10m] respects the trailing zero. IIRC, Brendan's position was a more pragmatic one, namely that small integers (like, say, up to 10**20th) are the only values for which toString must avoid both exponential notation and trailing zeros, other values shouldn't get in the way of doing the right thing. That would have been fine, but unfortunately he couldn't make the meeting (something I definitely understand). Mike and I weren't then, and still aren't happy about conceding to Waldemar's position on this one, but at Redmond we did with the understanding that with that concession, Decimal was in. This Redmond-meeting result did sound like a breakthrough in any event. Was it memorialized with spec changes? There were spec changes that went in as a result of the Redmond meeting, yes. At least one was identified before the Kona meeting by Waldemar (and fessed up to by me) as having been botched by myself (and = or). The second was the duplication between Math.min and Decimal.min. I was operating under the if it ain't broken, don't fix it guidelines. To date, Math.min *always* returns a Number, never an Object. Waldemar apparently feels that people will call the wrong function. To me, this is a you say N-EEE-THER, I say N-EYE-THER issue. If the consensus is that Math.min should be changed and Decimal.min should be removed, that's a pretty quick fix. This doesn't seem like a big problem, by itself. Agreed, and in any case, one that I would eagerly adopt. So now the question is: where are we now? The two general kinds of problems from the Kona meeting were: 1. Spec bugs, not just typos but material ones that couldn't be fixed by that meeting, which was the deadline for major additions to ES3.1 not already in the spec. For the moment, I would like to split that list into two categories: areas where there isn't yet agreement within the committee on how to proceed, and the best way I know how to make progress on that is to come to agreement on the behavior desired, hence my suggestion that we look at concrete test cases; and a list of places where I erred in my converting my understanding into prose. No matter how we proceed, the first list needs to be captured and addressed eventually anyway. 2. Future-proofing arguments including: do we need Decimal wrappers for decimal primitives. I know we've been over this before, but it still is an open issue in TC39. That does sound like the type of issue that I would like to see us identify and work to resolve. Two questions come to mind: (1) can anybody identify a specific expression which behaves differently that one would desire, and (2) if we've been over this before, what does it take to actually close this issue this time for good? I'd appreciate Waldemar's comments; and those of other TC39ers too, of course. /be - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 3, 2008, at 6:18 PM, Maciej Stachowiak wrote:
x = x
+x
That is equivalent to
x = x + x;
so the case with ^ should not differ. (Were you testing in an
interactive REPL?)
That the case Peter showed:
x = x
^(){}
cannot be parsed as a bitwise-xor expression doesn't help in general,
if we do not want to mandate bottom-up parsing (we don't).
/be___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 12/03/2008 06:18 PM, Maciej Stachowiak wrote:
On Dec 3, 2008, at 1:23 PM, Peter Michaux wrote:
x = x
^(){}
I think this has only one possible meaning: an expression statement
consisting of an assignment of x to itself, followed by an expression
statement that creates an empty no-argument closure. Do you see another
possible meaning?
According to the wording in E-262, that's a syntax error, and your
second example:
x = x
+x
Is equivalent to |x = x + x| because, when at the 2nd |x|, the next
token is valid.
--
Blake Kaplan
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 9:36 PM, Eric Suen [EMAIL PROTECTED] wrote:
No,
^(x) is not a legal expression, so you don't have to make
block in same line, no semicolon insertion will happens here.
You're looking at the wrong part of the example. Sorry -- the
wrapper lambda is superfluous, and I should have left it out for
clarity.
Using the GNU bracing style:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
The above parses as an xor expression followed by a block, like so:
x = x * x ^ (a,b,c,d,e,f,g)
{
x
}
... which is odd, to be sure, but perfectly legal.
The second example:
x = x * x
^(a,b,c,d,e,f,g) {x}
is not ambiguous, but it's unsuitable for top-down parsing. (I tried
to underscore the point by using a long list of formals.) The parser
has to get to the opening brace before it can determine that it isn't
dealing with an xor expression.
-Jon
see this post:
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008296.html
- Original Message -
From: Jon Zeppieri [EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: P T Withington [EMAIL PROTECTED]
Cc: es-discuss [EMAIL PROTECTED]
Sent: Thursday, December 04, 2008 3:09 AM
Subject: Re: Allen's lambda syntax proposal
2008/12/3 P T Withington [EMAIL PROTECTED]:
- prefix ^ might be confused with the infix operator of the same name
With semicolon insertion, isn't this a bigger problem?
The opening brace will need to be on the same line as the formals,
otherwise the syntax is ambiguous:
^(x) {
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
}
And, if it is on the same line, it's still bad for a top-down parser:
^(x) {
x = x * x
^(a,b,c,d,e,f,g) {x}
}
Will semicolon insertion be illegal inside a lambda body?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Because it is a xor expression, for lambda, it will be
x = x * x ^ ^ (a,b,c,d,e,f,g)
{
x
}
it is same for regexp,
x = x / x /i
is not regexp, but
x = x / /x/i
is regexp
seems that ^ will confuse lots of people
- Original Message -
From: Jon Zeppieri [EMAIL PROTECTED]
To: Eric Suen [EMAIL PROTECTED]
Cc: Jon Zeppieri [EMAIL PROTECTED]; es-discuss
es-discuss@mozilla.org
Sent: Thursday, December 04, 2008 10:45 AM
Subject: Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 9:36 PM, Eric Suen [EMAIL PROTECTED] wrote:
No,
^(x) is not a legal expression, so you don't have to make
block in same line, no semicolon insertion will happens here.
You're looking at the wrong part of the example. Sorry -- the
wrapper lambda is superfluous, and I should have left it out for
clarity.
Using the GNU bracing style:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
The above parses as an xor expression followed by a block, like so:
x = x * x ^ (a,b,c,d,e,f,g)
{
x
}
... which is odd, to be sure, but perfectly legal.
The second example:
x = x * x
^(a,b,c,d,e,f,g) {x}
is not ambiguous, but it's unsuitable for top-down parsing. (I tried
to underscore the point by using a long list of formals.) The parser
has to get to the opening brace before it can determine that it isn't
dealing with an xor expression.
-Jon
see this post:
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008296.html
- Original Message -
From: Jon Zeppieri [EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: P T Withington [EMAIL PROTECTED]
Cc: es-discuss [EMAIL PROTECTED]
Sent: Thursday, December 04, 2008 3:09 AM
Subject: Re: Allen's lambda syntax proposal
2008/12/3 P T Withington [EMAIL PROTECTED]:
- prefix ^ might be confused with the infix operator of the same name
With semicolon insertion, isn't this a bigger problem?
The opening brace will need to be on the same line as the formals,
otherwise the syntax is ambiguous:
^(x) {
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
}
And, if it is on the same line, it's still bad for a top-down parser:
^(x) {
x = x * x
^(a,b,c,d,e,f,g) {x}
}
Will semicolon insertion be illegal inside a lambda body?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
It even can be writen as:
Lambda ::= '' IdentifierOpt ParametersOpt Block
IdentifierOpt ::= %Empty
| PropertyIdentifier
ParametersOpt ::= %Empty
| '(' Parameters ')'
I suggest following grammar:
Lambda ::= '' '(' Parameters ')' Block
| '' Block //if no parameters
I can comfire that this rule is no problem for a LALR(k) parser,
ES4 is not LALR(1) anyway. and I think ^ is not good for eyes, it
is too small and may confused with ~. look more like C/C++ style
a = { ... }
a = (a,b) { ... }
Yuh-Ruey Chen wrote:
Brendan Eich wrote:
C# uses (a, b, c) = ... but in JS the comma operator makes that
nasty to parse top-down. I think the only candidates have to be of
the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the Smalltalky
{ |a, b, c| ... }
At this point we need a bake-off, or a convincing argument against
the unusual vertical bar usage.
Here's a possible technical issue that might not apply to ES: Ruby
blocks params can't have default arguments according to
http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :
The new syntax allows to specify default values for block
arguments, since
{|a,b=1| ... }
is said to be impossible with Ruby's current LALR(1) parser, built
with bison.
That Ruby 1.9 page also lists yet another possible syntax:
-(a, b, ...) {...}
Using Maciej's examples:
if_ (-{x 3}, -{
handleSmallNum(x);
}, -{
handleLargeNum(x);
});
while_ (-{x != null}, -{
x.process();
x = x.next();
});
for_ (-{var i = 1}, -{i 10}, -{i++}, -{
total += vec[i];
});
forIn_ (obj, -(prop) {
props.push(prop);
});
arr.sort(-(a, b) { a*a b*b });
arr.map(-(x) { x * (x-1)});
function doubleBs(str) {
str.replace(/b*/, -(substr) { substr + substr });
}
The control abstractions just don't look right, regardless of which
lambda syntax we choose. I'd rather wait for a more powerful macro
system, instead of choosing the syntax based off how it would look in
control abstractions.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 9:52 PM, Eric Suen [EMAIL PROTECTED] wrote:
Because it is a xor expression, for lambda, it will be
x = x * x ^ ^ (a,b,c,d,e,f,g)
{
x
}
I don't understand what you're getting at. That's a syntax error. My example:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
is not a syntax error, but it also (unfortunately) doesn't contain a
lambda expression. Or am I missing something?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Yes, it doesn't contain a lambda expression, just like:
a = x
/x/i
is not same as:
a = x;
/x/i
they both right but has different meaning...
Because it is a xor expression, for lambda, it will be
x = x * x ^ ^ (a,b,c,d,e,f,g)
{
x
}
I don't understand what you're getting at. That's a syntax error. My
example:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
is not a syntax error, but it also (unfortunately) doesn't contain a
lambda expression. Or am I missing something?
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 7:16 PM, Eric Suen [EMAIL PROTECTED] wrote: Yes, it doesn't contain a lambda expression, just like: a = x /x/i is not same as: a = x; /x/i they both right but has different meaning... Is adding more confusion like this in the language desirable? Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 10:16 PM, Eric Suen [EMAIL PROTECTED] wrote:
Yes, it doesn't contain a lambda expression, just like:
a = x
/x/i
is not same as:
a = x;
/x/i
they both right but has different meaning...
Okay -- so we agree. In that case, it's clear that your proposed syntax:
(a,b,c) {...}
has the same problem, right? Any valid ES3 infix operator will have
the same problem, if we use it as a prefix lambda operator.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
