Followup to discuss some open issues from the thread, evident in the
message cited below:
1. Unifying var scope and let scope at top level of a function could
be done, with tolerable restrictions: given let x at top level in a
function body, existence of formal parameter x, and
Brendan Eich wrote:
Followup to discuss some open issues from the thread, evident in the
message cited below:
1. Unifying var scope and let scope at top level of a function could be
done, with tolerable restrictions: given let x at top level in a
function body, existence of formal
On Tue, Oct 21, 2008 at 3:42 PM, Waldemar Horwat [EMAIL PROTECTED] wrote:
What does ES3.1 do if you have both const x and var x at the top level?
It just so happens that we discussed top level const in this morning's
ES3.1 phone meeting. It never occurred to us to ban top level const.
We did
Mark S. Miller wrote:
On Tue, Oct 21, 2008 at 3:42 PM, Waldemar Horwat [EMAIL PROTECTED] wrote:
What does ES3.1 do if you have both const x and var x at the top level?
It just so happens that we discussed top level const in this morning's
ES3.1 phone meeting. It never occurred to us to ban
On Oct 21, 2008, at 5:56 PM, David-Sarah Hopwood wrote:
If we got in wrong in ES3.1, we couldn't fix it later.
That's true, but I still hope to convince you and the group that we
can
get it right for ES3.1.
With zero implementations due to lack of a spec that hangs together in
full,
Eric Suen wrote:
I think top-down parser has no issue to parse following code:
function() {
}();
but this is not a valid statement because:
ExpressionStatement ::= [lookahead ! {{, function}] Expression ;
There is a good reason for that. It's because of semicolon insertion. You'd
Brendan Eich wrote:
On Oct 16, 2008, at 7:04 PM, Waldemar Horwat wrote:
The parser is required to backtrack until it either finds an expansion
of the grammar that doesn't generate a syntax error or until it
discovers that they all do. You can choose to make additional syntax
errors as
Maciej Stachowiak wrote:
I think it might be better to write the official ES3.1 grammar in this
way, even though it is a little annoying and repetitive, so it can more
readily be verified that the language grammar has no ambiguities by
running through a parser-generator like yacc or bison
On Oct 17, 2008, at 11:05 AM, Waldemar Horwat wrote:
Brendan Eich wrote:
Is this a perfectly valid for-in statement?
for (a = b in c);
Not according to ES3's grammar. An assignment expression is not
valid on
the left of the for-in's in:
/IterationStatement /*:*
* ...*
*
On Oct 17, 2008, at 11:30 AM, Brendan Eich wrote:
In that case the -NoIn sub-grammar should apply, extended to
LetExpressionNoIn. So
for (let (a = b) c in d);
Sorry, of course that should have been
for (var a = let (b = c) b in d);
/be
___
On Oct 16, 2008, at 3:40 PM, Brendan Eich wrote:
For now I favor the lambda expression form as well as the lambda
block form.
Good thing I added For now. Since I'm convinced by Waldemar's
argument against ambiguity, I have to drop support for the lambda
expression form. It could be
On Oct 17, 2008, at 11:17 AM, Waldemar Horwat wrote:
Maciej Stachowiak wrote:
As to the else issue, I don't think that ambiguity can be avoided,
but bison lets you solve that with %nonassoc, which is a sound
disambiguation mechanism.
It can. I have a machine-validated ES3 (and ES4
The parser is required to backtrack until it either finds an
expansion of the grammar that doesn't generate a syntax error or
until it discovers that they all do. You can choose to make
additional syntax errors as per chapter 16, but that does not
relieve you of the backtracking requirement.
On Oct 17, 2008, at 7:36 PM, Eric Suen wrote:
Are you sure about that, because you using hand written top-down
parser,
Is it confirmed by a top-down parser generator like ANTLR?
I haven't used ANTLR or any other LL(*) parser generator, no.
I found http://code.google.com/p/antlr-javascript/
Brendan Eich wrote:
On Oct 15, 2008, at 2:36 PM, Waldemar Horwat wrote:
There is no such thing as a let expression.
Let expressions
http://developer.mozilla.org/en/New_in_JavaScript_1.7#let_expressions in
JS1.7 (Firefox 2+), based on the ES4 proposal
Brendan Eich wrote:
On Oct 16, 2008, at 11:38 AM, Waldemar Horwat wrote:
Brendan Eich wrote:
That's not a valid grammar.
It is unambiguous. How do you define valid?
You can't have an AssignmentExpression terminating a
PrimaryExpression. It leads to trouble such as:
let a = b + c
On Wed, Oct 15, 2008 at 4:49 PM, Dave Herman [EMAIL PROTECTED] wrote:
In the grammar for proposed ES4, LetExpression was under
PrimaryExpression. That's where I'm suggesting LambdaExpression might
fit. IOW:
PrimaryExpression ::= ...
| LetExpression
|
On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote:
I don't think you can come up with a consistent shift or greedy
notion.
Funny, yacc has had one for decades, used to resolve dangling-else.
The one you may be thinking of will happily accept code such as
let (a = 5) x + y.foo = 2;
yet
On Oct 15, 2008, at 1:28 PM, Mark S. Miller wrote:
On Wed, Oct 15, 2008 at 12:31 PM, Dave Herman [EMAIL PROTECTED]
wrote:
Do you prefer (lambda Formals Block | lambda Formals Expression)?
[Personally I'm fine with that.] Or do you oppose any lambda
expressions
at all? Or did you have
On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote:
SpiderMonkey historically used SyntaxError, not ReferenceError, and
throw at compile-time. This pre-dates ES1. Another example not
involving let expressions:
js a + b = c
typein:1: SyntaxError: invalid assignment left-hand side:
Mark S. Miller wrote:
On Wed, Oct 15, 2008 at 4:49 PM, Dave Herman [EMAIL PROTECTED] wrote:
In the grammar for proposed ES4, LetExpression was under
PrimaryExpression. That's where I'm suggesting LambdaExpression might
fit. IOW:
PrimaryExpression ::= ...
| LetExpression
Brendan Eich wrote:
On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote:
I don't think you can come up with a consistent shift or greedy
notion.
Funny, yacc has had one for decades, used to resolve dangling-else.
The one you may be thinking of will happily accept code such as
let (a
On Thu, Oct 16, 2008 at 5:49 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
[lots of good stuff snipped]
I agree.
The degenerate syntax let {...} allowed by this grammar at first-sight
doesn't seem very useful, until you realize that it has a similar effect
(apart from not preventing
On Oct 16, 2008, at 7:01 PM, Brendan Eich wrote:
On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote:
On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote:
I don't think you can come up with a consistent shift or
greedy notion.
Funny, yacc has had one for decades, used to resolve
Please specify what you are proposing. The one proposal I've seen is:
Expression ::= ... | lambda Formals Statement
Yes, that's what I meant, or at least what I thought Yuh-Ruey meant.
This is not particularly useful because then even assign a lambda to a
variable would be a syntax
Dave Herman wrote:
Please specify what you are proposing. The one proposal I've seen is:
Expression ::= ... | lambda Formals Statement
Yes, that's what I meant, or at least what I thought Yuh-Ruey meant.
This is not particularly useful because then even assign a lambda to a
variable
Please specify what you are proposing. The one proposal I've seen is:
Expression ::= ... | lambda Formals Statement
Dave Herman wrote:
Yes, that's what I meant, or at least what I thought Yuh-Ruey meant.
This is not particularly useful because then even assign a lambda to a
variable
On Oct 15, 2008, at 2:36 PM, Waldemar Horwat wrote:
There is no such thing as a let expression.
Let expressions in JS1.7 (Firefox 2+), based on the ES4 proposal. ES3-
ish grammar:
LetExpression :
let ( VariableDeclarationList ) [lookahead ∉ {{}]
AssignmentExpression
produced from
On Oct 15, 2008, at 6:13 PM, Brendan Eich wrote:
On Oct 15, 2008, at 2:36 PM, Waldemar Horwat wrote:
There is no such thing as a let expression.
Let expressions in JS1.7 (Firefox 2+), based on the ES4 proposal.
ES3-ish grammar:
LetExpression :
let ( VariableDeclarationList )
On Oct 13, 2008, at 6:39 PM, Brendan Eich wrote:
Users may be modeling closures as capturing bindings, not scope chains
of mutable objects, one per for (let...) statement or explicitly
braced block. If so, could we make let declaration capture this way?
Again, I'm proceeding from real users'
David-Sarah Hopwood wrote:
Neil Mix wrote:
The for/closures bug is definitely a newbie trap, but its pain is
not its discovery, but the difficulty of working around it. To me
this could be a winning argument against re-binding on each loop,
since re-binding precludes the (admittedly
On Oct 14, 2008, at 7:38 AM, Neil Mix wrote:
On Oct 13, 2008, at 6:39 PM, Brendan Eich wrote:
Users may be modeling closures as capturing bindings, not scope
chains
of mutable objects, one per for (let...) statement or explicitly
braced block. If so, could we make let declaration capture
What about for-in loops?
I'm proceeding from user expectations being confounded. Something
needs help here, possibly not for (;;) loops -- but almost certainly
for-in loops containing closures capturing the loop variable.
Whatever is done should be consistent between for and for-in. My
On 2008-10-11, at 08:34EDT, David Herman wrote:
Thank you for pointing out, though, that try/catch isn't so easily
defined on top of return-to-label, since it still needs special
handling for finally. The options are either to define a lower-level
primitive underlying try/finally (akin
Brendan Eich wrote:
What did you mean by had better fail to compile? Other than the
type annotation, there is nothing about
function f() {
x = 15;
...
var t = some_runtime_expression;
...
var x:t = ...
}
that ought to fail to compile.
The assignment to x in that temporal dead
David-Sarah Hopwood wrote:
David-Sarah Hopwood wrote:
Waldemar Horwat wrote:
I am talking about let bindings. Lars brought up at that meeting. I did
not find the use cases particularly convincing, but the dead zone is
compelling. There are four ways to do this:
A1. Lexical dead zone.
Neil Mix wrote:
The for/closures bug is definitely a newbie trap, but its pain is
not its discovery, but the difficulty of working around it. To me
this could be a winning argument against re-binding on each loop,
since re-binding precludes the (admittedly dubious) use-case of
Mark S. Miller wrote:
On Sun, Oct 12, 2008 at 7:55 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
In ES3.1, this will mean that they normally require braces whenever a
body can introduce variables. There are two classes of exceptions,
shown by these examples:
a) while (...) foo: var x =
On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
for (var ...) implicitly introduces a block whether or not it
is a substatement. This is a wart of C++/C99/Java syntax that
we have to live with, since too much code relies on it.
Yes, but how do we live with it? The
On Mon, Oct 13, 2008 at 11:43 AM, Mark S. Miller [EMAIL PROTECTED] wrote:
On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
for (var ...) implicitly introduces a block whether or not it
is a substatement. This is a wart of C++/C99/Java syntax that
we have to live
On Mon, Oct 13, 2008 at 9:13 AM, Jon Zeppieri [EMAIL PROTECTED] wrote:
I like your intention here -- I brought up the iteration variable /
closure issue earlier in the thread -- but this seems rather messy.
In the 'var' case, x must be the same throughout, no?
yes.
function foo() {
for
On Mon, Oct 13, 2008 at 12:47 PM, Mark Miller [EMAIL PROTECTED] wrote:
On Mon, Oct 13, 2008 at 9:13 AM, Jon Zeppieri [EMAIL PROTECTED] wrote:
But then it becomes extremely awkward for the 'let' or 'const' case to
use a fresh variable on every iteration. It ties the semantics of
'for' to its
Mark S. Miller wrote:
On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
for (var ...) implicitly introduces a block whether or not it
is a substatement. This is a wart of C++/C99/Java syntax that
we have to live with, since too much code relies on it.
Yes, but
David-Sarah Hopwood wrote:
Mark S. Miller wrote:
But what about let. Do we all agree that in
for (let x = ...) {...x...}
... x ...
the x after the for loop does not refer to the x defined by the for
loop?
Yes, if this form is allowed. The other options are either to require:
On Oct 13, 2008, at 8:43 AM, Mark S. Miller wrote:
On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
for (var ...) implicitly introduces a block whether or not it
is a substatement. This is a wart of C++/C99/Java syntax that
we have to live with, since too much
Brendan Eich wrote:
After some experiments, we decided for ES4 to make let and var the
same at top level in a function or global code.
This helped avoid implementation pain: very long scripts on the web,
consisting of many statements in a row, motivate statement-wise
parsing and
Brendan Eich wrote:
The agreement from the May TC39 meeting was that the declarations
implicit (:*) and explicit annotations must normalize to the same
type, or there's an error.
That was back when the language had lots of requirements for compile-time
expressions, including on all types.
On Oct 13, 2008, at 3:51 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
After some experiments, we decided for ES4 to make let and var the
same at top level in a function or global code.
This helped avoid implementation pain: very long scripts on the web,
consisting of many statements in a
On Oct 13, 2008, at 3:56 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
The agreement from the May TC39 meeting was that the declarations
implicit (:*) and explicit annotations must normalize to the same
type, or there's an error.
That was back when the language had lots of requirements for
Brendan Eich wrote:
If using an uninitialized let binding is an error, then hoisting is
pointless except to make the statements between start of block and the
let declaration a dead zone for the binding name. This fits the
ancient, weak but not entirely worthless post-hoc rationale for
On Oct 13, 2008, at 4:01 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
If using an uninitialized let binding is an error, then hoisting is
pointless except to make the statements between start of block and
the
let declaration a dead zone for the binding name. This fits the
ancient, weak
On Mon, Oct 13, 2008 at 6:34 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On the contrary, what's magical is when one stores i in elements of an
array, or calls setTimeout (example in
https://bugzilla.mozilla.org/show_bug.cgi?id=449811)
, and the results are all the last value of the loop
Brendan Eich wrote:
On Oct 13, 2008, at 3:56 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
The agreement from the May TC39 meeting was that the declarations
implicit (:*) and explicit annotations must normalize to the same
type, or there's an error.
That was back when the language had
On Oct 13, 2008, at 4:14 PM, Jon Zeppieri wrote:
Yes, and binding a fresh induction variable on every iteration makes
sense for a 'for-each' loop (as in the bug report you cited), where
the user is not in charge of updating the induction variable by means
of explicit assignment. In a plain
David-Sarah Hopwood wrote:
Mark S. Miller wrote:
[...] I recommend the per-iteration view. If we can
agree quickly on per-iteration, then
for (const x = ...) {...x...}
should be allowed in ES3.1 (whether or not const hoists to block
start). After ES3.1
for (const i :T[i] = ...)
Mark S. Miller wrote:
On Sat, Oct 11, 2008 at 9:11 AM, Peter Michaux [EMAIL PROTECTED] wrote:
I think it would be ok to have only unnamed lambdas. (It would be ok
to have named lambdas too.)
I think we should not introduce named lambdas because then we'd need
to decide whether the scoping
On Mon, Oct 13, 2008 at 7:39 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Oct 13, 2008, at 4:14 PM, Jon Zeppieri wrote:
Yes, and binding a fresh induction variable on every iteration makes
sense for a 'for-each' loop (as in the bug report you cited), where
the user is not in charge of
On Oct 13, 2008, at 4:09 PM, Brendan Eich wrote:
On Oct 13, 2008, at 4:01 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
If using an uninitialized let binding is an error, then hoisting is
pointless except to make the statements between start of block and
the
let declaration a dead zone
Brendan Eich wrote:
On Oct 13, 2008, at 4:01 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
If using an uninitialized let binding is an error, then hoisting is
pointless except to make the statements between start of block and the
let declaration a dead zone for the binding name. This fits
On Oct 13, 2008, at 5:00 PM, Jon Zeppieri wrote:
On Mon, Oct 13, 2008 at 7:39 PM, Brendan Eich [EMAIL PROTECTED]
wrote:
On Oct 13, 2008, at 4:14 PM, Jon Zeppieri wrote:
Yes, and binding a fresh induction variable on every iteration makes
sense for a 'for-each' loop (as in the bug report
David Herman wrote:
Also, I wonder why lambda in it's block-less form is restricted to
expressions.
I'm with you... but I'd want to check with the experts on the ES grammar to
see whether this introduces any nasty ambiguities.
Please specify what you are proposing. The one proposal I've
On Oct 13, 2008, at 4:54 PM, Waldemar Horwat wrote:
I am talking about let bindings. Lars brought up at that meeting.
I did not find the use cases particularly convincing, but the dead
zone is compelling. There are four ways to do this:
A1. Lexical dead zone. References textually
Brendan Eich wrote:
On Oct 13, 2008, at 5:29 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
On Oct 13, 2008, at 3:51 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
After some experiments, we decided for ES4 to make let and var the
same at top level in a function or global code.
...
You
On Oct 13, 2008, at 6:08 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
Because presumably the let x:t became var x:t and var can't have
types?
Why can't var have a type annotation?
Because a function can have many var declarations for the same
variable and because you can use the
Waldemar Horwat wrote:
I am talking about let bindings. Lars brought up at that meeting. I did not
find the use cases particularly convincing, but the dead zone is compelling.
There are four ways to do this:
A1. Lexical dead zone. References textually prior to a definition in the
same
David-Sarah Hopwood wrote:
Waldemar Horwat wrote:
I am talking about let bindings. Lars brought up at that meeting. I did
not find the use cases particularly convincing, but the dead zone is
compelling. There are four ways to do this:
A1. Lexical dead zone. References textually prior to
Yuh-Ruey Chen wrote:
Mark S. Miller wrote:
On Sat, Oct 11, 2008 at 4:33 PM, Dave Herman [EMAIL PROTECTED] wrote:
Expression ::= ... | lambda Formals? Statement
Statement or SubStatement? If Statement, what meaning do you propose for
{
const f = (lambda () const x = 3;);
x
David-Sarah Hopwood wrote:
Yuh-Ruey Chen wrote:
Now that I think about it, would it truly be necessary for lambda to
create an implicit block scope in the first place?
It's not strictly necessary, but it's quite ugly not to. We are intending
to restrict 'eval' precisely to remove the
On Sun, Oct 12, 2008 at 2:19 PM, Yuh-Ruey Chen [EMAIL PROTECTED] wrote:
David-Sarah Hopwood wrote:
{ while (...) let x = ...; }
I was under the impression that such statements should be disallowed,
following the example of JS1.8. In JS1.8 (Fx3), the following are all
syntax errors:
while
Mark S. Miller wrote:
On Sun, Oct 12, 2008 at 2:19 PM, Yuh-Ruey Chen [EMAIL PROTECTED] wrote:
David-Sarah Hopwood wrote:
{ while (...) let x = ...; }
I was under the impression that such statements should be disallowed,
following the example of JS1.8. In JS1.8 (Fx3), the following are all
Mark S. Miller wrote:
On Sun, Oct 12, 2008 at 2:19 PM, Yuh-Ruey Chen [EMAIL PROTECTED] wrote:
David-Sarah Hopwood wrote:
{ while (...) let x = ...; }
I was under the impression that such statements should be disallowed,
following the example of JS1.8. In JS1.8 (Fx3), the following are all
On Sun, Oct 12, 2008 at 7:34 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
So why are we arguing about whether lambdas should be allowed without
braces, when the direction being taken for the rest of the language
is to make the braces mandatory around all forms that can potentially
On Sun, Oct 12, 2008 at 5:45 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
Since LabelledStatement is included in SubStatement, the following is
allowed in the current ES3.1 draft:
while (...) foo: var x = ...;
This will be corrected in the next version. But the agreed fix is not
to make
YR Chen wrote:
On Sun, Oct 12, 2008 at 7:34 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
So why are we arguing about whether lambdas should be allowed without
braces, when the direction being taken for the rest of the language
is to make the braces mandatory around all forms that can
On Sun, Oct 12, 2008 at 7:55 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
In ES3.1, this will mean that they normally require braces whenever a
body can introduce variables. There are two classes of exceptions,
shown by these examples:
a) while (...) foo: var x = ...;
b) while (...)
if (h == 0)
h = function() {break};
Did you mean if (x == 0)? That's been confusing me in trying to read your
example.
Dave
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Sat, Oct 11, 2008 at 10:02 AM, Mark S. Miller [EMAIL PROTECTED] wrote:
On Sat, Oct 11, 2008 at 9:11 AM, Peter Michaux [EMAIL PROTECTED] wrote:
As it stands, I always write the following in ES3
var f = function() {};
and now that arguments.callee is on the chopping block, I've started
Peter Michaux wrote:
On Sat, Oct 11, 2008 at 10:02 AM, Mark S. Miller [EMAIL PROTECTED] wrote:
On Sat, Oct 11, 2008 at 9:11 AM, Peter Michaux [EMAIL PROTECTED] wrote:
As it stands, I always write the following in ES3
var f = function() {};
and now that arguments.callee is on the chopping
On Sat, Oct 11, 2008 at 11:59 AM, Brendan Eich [EMAIL PROTECTED] wrote:
On Oct 11, 2008, at 9:05 AM, Peter Michaux wrote:
How to define a variable that is local to the enclosing lambda? Isn't
the ability to do that essential?
Use let (the var replacement declaration form).
Sounds good to me
Also, I wonder why lambda in it's block-less form is restricted to
expressions.
I'm with you... but I'd want to check with the experts on the ES grammar to see
whether this introduces any nasty ambiguities.
Dave
___
Es-discuss mailing list
Sounds good to me but it is a little confusing to keep track if let
is either in or out of ES-Harmony and if it is partly in then which
of
the several JavaScript 1.7 uses are in and if there will be let,
let*, letrec semantics.
I've got no crystal ball, but I'd say it'd be unlikely (and
On Sat, Oct 11, 2008 at 12:52 PM, Peter Michaux [EMAIL PROTECTED] wrote:
Use let (the var replacement declaration form).
Sounds good to me but it is a little confusing to keep track if let
is either in or out of ES-Harmony and if it is partly in then which of
the several JavaScript 1.7 uses
On Sat, Oct 11, 2008 at 1:21 PM, Mark S. Miller [EMAIL PROTECTED] wrote:
The let declaration is in. Like const and function declarations, it
has block-level letrec lexical scoping. I continue to oppose let
expressions and let statements, as they don't provide enough
additional power to
On Oct 11, 2008, at 12:55 PM, David Herman wrote:
How to define a variable that is local to the enclosing lambda? Isn't
the ability to do that essential?
No. With all due respect to Brendan, `var' hoisting to the top of a
function body is one of the more problematic aspects of ES's
On Oct 11, 2008, at 12:52 PM, Peter Michaux wrote:
On Sat, Oct 11, 2008 at 11:59 AM, Brendan Eich [EMAIL PROTECTED]
wrote:
On Oct 11, 2008, at 9:05 AM, Peter Michaux wrote:
How to define a variable that is local to the enclosing lambda?
Isn't
the ability to do that essential?
Use let
On Oct 11, 2008, at 2:43 PM, Brendan Eich wrote:
On Oct 11, 2008, at 12:52 PM, Peter Michaux wrote:
and if it is partly in then which of
the several JavaScript 1.7 uses are in and if there will be let,
let*, letrec semantics.
It's something else. See my reply about hoisting, just sent.
Hi Dave, first, my compliments on your lambda proposal. This should
significantly simplify the core language after expanding sugars --
especially if you succeed at redefining function as desugaring to
lambdas. That would be awesome!
On Sat, Oct 11, 2008 at 5:34 AM, David Herman [EMAIL PROTECTED]
On Oct 11, 2008, at 2:55 PM, Mark S. Miller wrote:
On Sat, Oct 11, 2008 at 2:42 PM, Brendan Eich [EMAIL PROTECTED]
wrote:
We've discussed making use-before-set a strict error, but we've
avoided it. The initialiser is not mandatory, and we do not wish to
impose costly analysis on small
On Sat, Oct 11, 2008 at 3:26 PM, Brendan Eich [EMAIL PROTECTED] wrote:
Of course, let expressions would need lambda-coding no matter what
names were shadowed. The experience gained in JS1.7+ shows more let
block usage than let expression, but expression temporaries (lacking
macros and ignoring
On Sat, Oct 11, 2008 at 4:05 PM, Dave Herman [EMAIL PROTECTED] wrote:
Read the proposal again: the statement form of lambdas *does* return the
value of its last expression; this is what ES3 calls the completion value.
Cool! So why are we still discussing proposed let expressions and let
blocks
On Oct 9, 2008, at 8:57 PM, Peter Michaux wrote:
This keyword/scoping problem must already have appeared for functions
as function declarations have var scoping and obtaining let
scoping requires using something like let a = function(){}. This is
pretty ugly for functions to have let scoping
Peter Michaux wrote:
This keyword/scoping problem must already have appeared for functions
as function declarations have var scoping and obtaining let
scoping requires using something like let a = function(){}. This is
pretty ugly for functions to have let scoping but the good news is
the
On Oct 10, 2008, at 1:25 PM, Waldemar Horwat wrote:
So what should f(5, 0) do?
function f(x, h) {
while (true) {
try {
if (h == 0)
h = function() {break};
Just to repeat something Dave wrote, we don't propose to allow break
in a function where the break is not in a
On Oct 10, 2008, at 3:31 PM, Brendan Eich wrote:
} catch (e) {
alert(caught + e + on + x);
} finally {
alert(f called finally on + x);
}
Skipping the intervening active finally clauses is bad, though -- a
bug in the current wiki rough draft that I should have mentioned.
David Herman wrote:
My question was whether the semantics of break and continue would
support the following:
Yes, this is another good case to consider. Thanks for pointing it out; I'll
add this to the strawman:lambdas proposal. Essentially this is another aspect
of the semantics of
On Sep 2, 2008, at 2:16 PM, Lex Spoon wrote:
On Sun, Aug 24, 2008 at 3:17 AM, Brendan Eich [EMAIL PROTECTED]
wrote:
First, let's settle the hash over whether any desugaring without
extensions such as return-to-label, reformed lexical scope, tamed
this, banished arguments, etc. etc., trumps
On Thu, Oct 9, 2008 at 5:31 PM, Brendan Eich [EMAIL PROTECTED] wrote:
JS has break from labeled statement, and continue to labeled loop bottom, a
la Java. These look trouble-free to me. Let me know if you see a hard case.
Thanks,
My question was whether the semantics of break and continue
On Oct 9, 2008, at 3:05 PM, Lex Spoon wrote:
On Thu, Oct 9, 2008 at 5:31 PM, Brendan Eich [EMAIL PROTECTED]
wrote: JS has break from labeled statement, and continue to labeled
loop bottom, a la Java. These look trouble-free to me. Let me know
if you see a hard case. Thanks,
My
On Oct 9, 2008, at 4:28 PM, David Herman wrote:
How would people feel about the declaration form being 'define'
instead of lambda? As in:
define const(x) {
lambda(y) x
}
Maybe I'm just accustomed to Scheme, but it looks awkward to me for
the declaration form to be called
@mozilla.org
Sent: Thursday, October 9, 2008 9:12:26 PM GMT -05:00 US/Canada Eastern
Subject: Re: return when desugaring to closures
On Oct 9, 2008, at 4:28 PM, David Herman wrote:
How would people feel about the declaration form being 'define'
instead of lambda? As in:
define const(x
1 - 100 of 123 matches
Mail list logo
