On Aug 18, 2008, at 8:35 AM, Brendan Eich wrote:
Scripts are synchronously loaded today, but browsers are working on
async loading techniques, and IE promulgated the defer attribute into
HTML5.
Er, into HTML4.
(Coffee time! ;-)
/be
___
Es-discuss
On Aug 18, 2008, at 9:28 AM, Yuh-Ruey Chen wrote:
OK, with the advent of ES-Harmony, I have no clue whether the language
will support iterators (and maybe generators)
We talked about these in Oslo. My notes say generators received
favorable comments, with the thought from Mark Miller that
On Aug 18, 2008, at 4:55 PM, David-Sarah Hopwood wrote:
I really like the general approach and the simplicity of Ihab's
proposal.
Also I strongly agree that a module should *not* implicitly capture
the lexical scope in which it is imported.
I don't think anyone proposed any such thing. Do
On Aug 21, 2008, at 6:54 PM, Mark S. Miller wrote:
On Thu, Aug 21, 2008 at 3:07 PM, Brendan Eich [EMAIL PROTECTED]
wrote:
[...] A strict mode or similar [...]. The greater its distance
from the standard mode,
A nit: Please let's start referring to the opposite of strict mode as
non
On Aug 21, 2008, at 7:26 PM, Peter Michaux wrote:
It works in practice as context of syntax sometime matters.
Context matters in many ways in JS and other languages.
This is definitely an example of the same syntax having semantically
different meaning (actually opposite meanings)
The
On Aug 21, 2008, at 10:10 PM, Breton Slivka wrote:
In the case of let statements, as I understand it, the current
proposal, and how let works in firefox is that
let (x = 2, y = x) {
print(y);
}
desugars to
{
let x = 2, y = x;
print(y);
}
No, because in the latter, as for var in a
On Aug 22, 2008, at 11:53 AM, David-Sarah Hopwood wrote:
Allen Wirfs-Brock wrote:
Michael Haufe [mailto:[EMAIL PROTECTED] said:
Although I'd prefer to control Deletable separately from Fixed,
Using a single state to control deletability, attribute
mutability, and
property
On Aug 23, 2008, at 8:44 AM, [EMAIL PROTECTED] wrote:
On Sat, Aug 23, 2008 at 1:49 AM, Mike Cowlishaw [EMAIL PROTECTED]
wrote:
Finally, I'd like to take a poll: Other than people working on
decimal
at IBM and people on the EcmaScript committee, is there anyone on
this
list who thinks
On Aug 23, 2008, at 8:23 AM, Fergus Cooney wrote:
Another use I have for redeclaring variables is when I want to
reuse the
name but there's a clear separation between the previous use and
the new
use. For example, I might have a variable to amass a bunch of html
snippets
and then
On Aug 23, 2008, at 5:45 PM, [EMAIL PROTECTED] wrote:
On Sat, Aug 23, 2008 at 11:30 AM, Sam Ruby [EMAIL PROTECTED]
wrote:
Having Decimal.parse(2) + 3 produce 23 is not what I would call
fail
fast, as that is a term I would typically use for throwing an
exception or
the like.
Point
On Aug 23, 2008, at 8:23 PM, Sam Ruby wrote:
The remainder of the quote that was relayed to me was that spec'ing
the operators would not be hard. I took it upon myself to
refamilarize myself with spider monkey and implement these operators,
and despite it being a decade or so since I've done
On Aug 24, 2008, at 12:51 AM, Maciej Stachowiak wrote:
But this doesn't mean that throwing when a
Decimal is used in any not-guaranteed-to-be-numeric operand context
is good.
Actually, throwing from valueOf would have the opposite effect.
Of course, and my not- was a thinko. I meant
On Aug 24, 2008, at 6:18 AM, Sam Ruby wrote:
A modest
request: if the code could be reviewed and feedback provided to me
with sufficient time for me to address the comments and the code to be
integrated into a nightly build, by default disabled, in time for the
Redmond meeting, I would
Polls are not so good, compared to reasons. Could you give your
rationale and talk about the trade-offs, in your experience?
/be
On Aug 24, 2008, at 7:36 PM, Peter Michaux wrote:
On Sun, Aug 24, 2008 at 6:05 PM, Brendan Eich [EMAIL PROTECTED]
wrote:
On Aug 24, 2008, at 4:09 PM, Mark S
On Aug 24, 2008, at 10:02 PM, Mark S. Miller wrote:
Let's say you did that -- make a special case for NaN but not for -0.
Let's say you use this Map to build memoize. Now let's say someone
writes a purely functional function F such that F(0) is 3 and F(-0) is
7. Let's say G is memoize(F).
On Aug 24, 2008, at 8:40 PM, Peter Michaux wrote:
Polls are not so good, compared to reasons. Could you give your
rationale
and talk about the trade-offs, in your experience?
You summed it up nicely with the hat trick:
It's a nice hat trick: privacy, higher integrity, and semantic reuse
On Aug 24, 2008, at 9:44 PM, Kris Zyp wrote:
I am surprised this is up for debate, I would also think that we
would want
instance-private by default.
We can debate lots of things, some that might actually be in play.
AFAIK this one is not decided in the committee (it's way too early),
On Aug 25, 2008, at 12:34 AM, Peter Michaux wrote:
On Sun, Aug 24, 2008 at 9:44 PM, Kris Zyp [EMAIL PROTECTED] wrote:
Desugared from:
class Point {
private var x = Math.random();
function getX(){
return this.x;
}
...
}
Is there any need for the this.? Some languages
On Aug 25, 2008, at 6:39 AM, Kris Zyp wrote:
I am surprised this is up for debate, I would also think that we
would
want
instance-private by default.
We can debate lots of things, some that might actually be in
play. AFAIK
this one is not decided in the committee (it's way too
On Aug 25, 2008, at 4:29 AM, Sam Ruby wrote:
If Decimal is an object type, then typeof 1.0m == object is good
for a couple of reasons:
* Future-proof in case we do add a primitive decimal type, as ES4
proposed -- a peer of double that shares Number.prototype; typeof on
a decimal would
On Aug 25, 2008, at 6:45 AM, Mark S. Miller wrote:
maybe even in ES3.1 (I should get my act together and help spec 'em).
(I will help on identical/hashcode, btw -- think we're agreeing
vehemently ;-).)
Just
not particularly on account of Decimal, even with equated cohort
members. I
On Aug 25, 2008, at 6:58 AM, Mark S. Miller wrote:
On Mon, Aug 25, 2008 at 6:50 AM, P T Withington [EMAIL PROTECTED] wrote:
FWIW, as a user, I've always assumed:
== : equal [1]
[1, 2] == [1, 2] // yields false
This makes me sad, but some day there might be ways to attach
multimethods
On Aug 25, 2008, at 12:23 PM, Peter Michaux wrote:
To refer to the instance in the sugared language, and there are valid
use-cases for doing so, we should use |this|. There's no point in
introducing a new keyword.
If there is a need to refer to the instance then this does make
sense. What
On Aug 25, 2008, at 1:59 PM, Mark S. Miller wrote:
On Mon, Aug 25, 2008 at 1:20 PM, Brendan Eich [EMAIL PROTECTED]
wrote:
On Aug 25, 2008, at 6:45 AM, Mark S. Miller wrote:
What is it you and Sam are agreeing about? I lost track.
That if we make cohort members == and ===, telling anyone
On Aug 25, 2008, at 3:00 PM, Ingvar von Schoultz wrote:
...we'll have to write something like this?
const
{ DatabaseName,
DisplayCount,
... Ten more ...
} =
Debugging ?
{ DatabaseName: TestDatabase,
DisplayCount: 5,
...
On Aug 25, 2008, at 4:10 PM, Mark S. Miller wrote:
are shallow generators
implementable by a local cps transform?
Yes, the local evaluation (inside the generator function) is the only
place that needs to be CPS'ed to allow yield in any expression or
statement context.
This approach
On Aug 25, 2008, at 4:41 PM, Waldemar Horwat wrote:
We're going round in circles on a few issues surrounding Decimal.
It seems to me people have reached the conclusion you already did on
===. I'm not sure anyone advocated otherwise (I've missed most 3.1
calls lately, so can't be sure).
On Aug 25, 2008, at 4:57 PM, Peter Michaux wrote:
There needs to be a way(s) to distinguish which variables have which
lifetimes and visibilities.
We have ways already: explicit blocks containing let-declared
temporaries; your public to make things visible outside their lexical
scope.
On Aug 25, 2008, at 6:15 PM, Mark S. Miller wrote:
Thanks, that helps a lot. But shouldn't that i == n be !(i n)
since it's a transform of the original i n?
Sure -- was going fast (other work competing ;-).
On Thu, Aug 21, 2008 at 11:31 PM, Dave Herman [EMAIL PROTECTED]
wrote:
Can't
On Aug 25, 2008, at 7:07 PM, Erik Arvidsson wrote:
I've been quiet on these threads for a long time but i just wanted
to emphasize Kris's point. Whatever we decide to desugar the class
syntax into I think it is very important to get this right. We need
to make classes work with existing
On Aug 25, 2008, at 8:51 PM, Mark S. Miller wrote:
How important is it that yield be an expression rather than a
statement? It seems like a sibling of return and throw, so I don't
think anyone coming to them afresh would be surprised if yield were a
statement.
This is and was not a
On Aug 26, 2008, at 2:49 PM, Dave Herman wrote:
I noticed a little idiom supported by classes-as-values:
(new (class() { ... }))
This essentially builds an object whose properties can be computed
in an
arbitrary statement context-- with loops or what have you. You might
call this a
On Aug 26, 2008, at 4:16 PM, Dave Herman wrote:
Does not say class, seems to save only a few chars (you
over-parenthesize new ;-). Wait for demand?
It's not about saving chars so much as introducing a new (lightweight)
semantic concept: an object initializer that is a block rather than a
On Aug 28, 2008, at 12:14 PM, Dave Herman wrote:
I interpreted Erik's point to be that the binding of `this' is not
lexically scoped, so it would be useful to have a lexically scoped
variable initially bound to the global object. IOW, if I write:
this.print(blah blah blah)
and then I
On Aug 28, 2008, at 1:23 PM, P T Withington wrote:
I'd like to have a syntax where this is _not_ implicitly bound. One
idea would be to riff on default arguments:
function example (receiver=this, ...
Why wouldn't you use |this| for the parameter name? We did for type-
annotating |this|
On Aug 28, 2008, at 2:59 PM, Ingvar von Schoultz wrote:
Dave Herman wrote:
Reformed `with' depended on type annotations and structural type
syntax,
which are undergoing discussion. So I think reformed `with' is up
in the
air for now.
I find it odd that reformed |with| required such
On Aug 28, 2008, at 3:26 PM, Ingvar von Schoultz wrote:
Macros and functions are very, very different. My proposal
has only regular, run-of-the-mill functions. They don't have
do have, right?
parentheses around the arguments, but this detail doesn't
make them in any way related to macros
On Aug 28, 2008, at 5:35 PM, Dave Herman wrote:
If you mean hygiene, that is not a practical problem so much as a
theoretical one. Dave knows a lot about this topic, so I'll defer
to him.
No, hygiene is most certainly a practical problem!
*Lack* of hygiene is a problem. My statement in
#c wins by maximizing TC purity, utility, and safety.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Sep 3, 2008, at 3:11 PM, Peter Michaux wrote:
On Wed, Sep 3, 2008 at 8:55 AM, Dave Herman [EMAIL PROTECTED]
wrote:
As I've said, macros aren't on the agenda for this go 'round.
Is there an official wiki location which states what the committee has
agreed upon for Harmony?
Not yet.
On Sep 3, 2008, at 10:51 PM, Mark S. Miller wrote:
On Wed, Sep 3, 2008 at 9:49 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
I don't see why any special case is needed here, or why removing it
would require splitting [[Deletable]] from [[Configurable]].
Suppose that [[Configurable]] =
On Sep 3, 2008, at 11:15 PM, David-Sarah Hopwood wrote:
In the absence of decimal, Object.eq is trivial to spec:
Object.eq(NaN, NaN) = true
Object.eq( 0, -0) = false
Object.eq( -0, 0) = false
Object.eq( x, y) = (x === y), otherwise.
or to implement:
Object.eq =
On Sep 4, 2008, at 12:29 AM, David-Sarah Hopwood wrote:
1. You can't do that in ES3.1 if Decimal is not in ES3.1. You'd have
to add typeof Decimal !== 'undefined' to the 'if' condition.
And then you'd be trying to anticipate a future spec, rather than
relying on an existing one.
On Sep 5, 2008, at 4:33 PM, Ingvar von Schoultz wrote:
Ingvar von Schoultz skrev:
Mark S. Miller skrev:
On Fri, Sep 5, 2008 at 2:33 PM, Ingvar von Schoultz
[EMAIL PROTECTED] wrote:
and silent failures
are often very expensive to debug.
I don't understand. As currently proposed,
: Brendan Eich [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2008 7:34 AM
To: Pratap Lakshman (VJ#SDK)
Cc: [EMAIL PROTECTED]; Mark S. Miller; Kris Zyp; Mike Cowlishaw;
Adam Peller; Sam Ruby; Lars Hansen; [EMAIL PROTECTED]; Allen Wirfs-
Brock; Waldemar Horwat
Subject: Re: ES3.1 WG phone
On Sep 9, 2008, at 9:47 PM, David-Sarah Hopwood wrote:
As an alternative to saying the original bindings of... in the spec,
we could provide a way to actually get the original bindings in
ECMAScript
code. This is independently useful, e.g. for secure subset run-times.
Have you read
On Sep 10, 2008, at 6:24 PM, David-Sarah Hopwood wrote:
David-Sarah Hopwood wrote:
Mark S. Miller wrote:
On Wed, Sep 10, 2008 at 12:49 AM, Brendan Eich
[EMAIL PROTECTED] wrote:
I'm willing to rename Function.apply, but let's talk some more
about the
better name, and about why
on the list, please pipe up.
/ be
Sent from my iPhone
On Sep 12, 2008, at 6:54 PM, Tobie Langel [EMAIL PROTECTED]
wrote:
On Sep 11, 2008, at 14:34 , Brendan Eich wrote:
I snipped your words about callee, but it's used quite a bit in Ajax
libraries, e.g, Prototype:
$ grep -w callee
Good point -- could you please file a separate ticket and cite it
here in reply? Thanks,
/be
On Sep 15, 2008, at 7:51 PM, Markus Jarderot wrote:
Brendan Eich wrote:
Steven did file
http://bugs.ecmascript.org/ticket/376
I'll champion fixing this, somehow, in Harmony. We should get
On Sep 15, 2008, at 10:13 PM, Jorge Chamorro wrote:
El 15/09/2008, a las 22:32, Jon Zeppieri escribió:
IOW, could we have instead a ('standalone') 'callee' property (that
isn't to be innocently passed on) ?
...as a property of what?
The activation object of the execution context.
I've
On Sep 15, 2008, at 10:21 PM, Jon Zeppieri wrote:
Don't even get me started on activation 'objects'...
Nor me.
Mark, didn't you propose eliminating that language from the spec?
(Yup. https://mail.mozilla.org/pipermail/es-discuss/2008-April/
006062.html)
I'm guessing that's not actually
On Sep 16, 2008, at 12:21 AM, liorean wrote:
2008/9/16 William Edney [EMAIL PROTECTED]:
Could I do an assignment of the handler? Sure, but syntactically
suboptimal, IMHO.
Once JScript has fixed the function name scope bug, you could use
myElem.addEventListener(
'click',
On Sep 17, 2008, at 10:13 PM, Mark S. Miller wrote:
On Wed, Sep 17, 2008 at 6:50 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
I agree that typeof 1.5m == typeof 1.1m. However, I do not agree
that 1.1m == 1.1. These should be !=, since they represent
distinct real numbers.
It seems
On Sep 17, 2008, at 7:48 PM, Sam Ruby wrote:
Anybody care to mark up what they would like to see the following
look like?
http://intertwingly.net/stories/2008/09/12/estest.html
Shipt it!
(Not in ES3.1, certainly in Firefox 3.1 if we can... :-)
/be
On Sep 18, 2008, at 10:58 PM, Kris Zyp wrote:
* Like Crock, I prefer that typeof 1m === 'number'. However, unlike
Crock's
and Brendan's agreement, I think this should be unconditional. I
think it
would be horrible for 'typeof X' to depend not only on the value
of X but
also on the mode
On Sep 19, 2008, at 8:45 AM, Sam Ruby wrote:
The motivation for the fourth choice on the first question is to
produce a value that is is valid JSON, is unlikely to be widely used
today (by virtue of the capital E), will fall back to binary 64 many
JSON implementations, and can be used as a
On Sep 22, 2008, at 4:17 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
On Sep 22, 2008, at 3:32 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
Good point -- could you please file a separate ticket and cite it
here in reply? Thanks,
I filed a ticket to fix this bug in Chrome.
The ticket
On Sep 23, 2008, at 1:45 PM, Waldemar Horwat wrote:
Sam Ruby wrote:
One minor request: statements like breaks arrays are less helpful
than specific ECMAScript statements which would fail; better yet
would
be citing specific deployed code that would fail.
I already gave specific examples
On Sep 24, 2008, at 9:01 AM, Mike Cowlishaw wrote:
I'm not sure what you are getting at. a[1] and a[1.000] refer to the
same property in ECMAScript, but a[1m] and a[1.000m] would not. Are
you saying this isn't a problem?
Absolutely not a problem ... many languages (and ES itself) which
On Sep 24, 2008, at 9:18 AM, Sam Ruby wrote:
[over-top-citing trimmed]
The concern remains, though. Not due to power-of-five problems that
would lead to 0.09987 or the like, but from cases where a
number was spelled with extra trailing zeros (in external data,
e.g. a
spreadsheet)
On Sep 27, 2008, at 8:14 PM, David-Sarah Hopwood wrote:
liorean wrote:
[...]
10.1.3 Variable Instantiation
[...] If two or more formal parameters share the same
name, hence the same property, the corresponding property is given
the
value that was supplied for the last parameter
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 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
On Oct 9, 2008, at 6:44 PM, David Herman wrote:
Sorry, I was unclear.
No, my fault for missing declaration form.
I meant 'lambda' for the expression form and 'define' for the
definition form.
Do keywords cost more than concepts?
If people think define name(x) x and lambda (x) x are
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
On Oct 10, 2008, at 5:44 AM, P T Withington wrote:
On 2008-10-10, at 02:29EDT, Brendan Eich wrote:
An agreement from TC39 this past spring was that function definitions
directly nested in blocks, not specified by ES3, defined block-local
(let) bindings.
Holy smokes. Does that mean we
On Oct 10, 2008, at 11:58 AM, P T Withington wrote:
? If so, perhaps you can see how I might imagine that:
function foo () {{
var bar = ...;
}}
might be sugar for:
function foo () {
let bar = ...;
}
Nope, not compatible and not what I meant.
Just the function's name
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
On Oct 11, 2008, at 7:25 AM, David-Sarah Hopwood wrote:
It is correct to say, though, that:
function foo() {
...
{ var bar = baz; }
...
}
is equivalent to
function foo() {
let bar = undefined;
...
{ bar = baz; }
...
}
That is, 'var' need not be
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
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 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
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
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
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 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
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
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
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
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
On Oct 13, 2008, at 7:48 PM, Mark S. Miller wrote:
On Mon, Oct 13, 2008 at 5:00 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
1) for (var i = 0; i len; i++) ... continues to mean what it
means in ES3.
2) for (let i = 0; i len; i++) ... has the proper scope for 'i'
(which you reiterated
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
On Oct 14, 2008, at 7:17 AM, David-Sarah Hopwood wrote:
This is subject to the criticism that the loop variable(s) are
implicitly mutable in the update expression (only), when they were
declared it to be const.
My point was simpler: sometimes it is handy to write for (const x...)
and have
On Oct 14, 2008, at 7:17 AM, David-Sarah Hopwood wrote:
Requirement 3 is met because var hoists to the enclosing function.
Assuming that var hoisting is done before this expansion, yes.
Absolutely -- var hoisting across lambdas to preserve TCP is prior
magic, assumed by the (revised) lambda
On Oct 14, 2008, at 12:39 PM, Waldemar Horwat wrote:
PS. What does lambda(x = y){...}() mean? Is it different from
lambda(x){...}(y)?
No.
What does lambda(x = y){...}(z) do when z is undefined?
Passes undefined bound to x. Undefined is not the same as missing.
These are my answers
On Oct 14, 2008, at 1:36 PM, Brendan Eich wrote:
On Oct 14, 2008, at 12:39 PM, Waldemar Horwat wrote:
What does lambda(x = y){...}(z) do when z is undefined?
Passes undefined bound to x. Undefined is not the same as missing.
Lest anyone think otherwise, missing means actual argument count
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 16, 2008, at 1:55 PM, Waldemar Horwat wrote:
var: Not an issue if you're not using var inside the lambda. Code
generation that wants to use lambda would use var why?
arguments: Again, not an issue if you're not using the arguments
array. If a code generator is updated for
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:
typein:1
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
___
Es
On Oct 17, 2008, at 12:25 PM, Waldemar Horwat wrote:
Here's a clearer case that Firefox gets wrong (or your grammar gets
wrong, depending on your point of view):
function f() {return f}
var x = 3;
let (a = 1) a ? f : x++();
The grammar states that the last statement must evaluate to f.
On Oct 17, 2008, at 3:39 PM, Brendan Eich wrote:
On Oct 17, 2008, at 12:25 PM, Waldemar Horwat wrote:
Here's a clearer case that Firefox gets wrong (or your grammar gets
wrong, depending on your point of view):
function f() {return f}
var x = 3;
let (a = 1) a ? f : x++();
The grammar
1 - 100 of 4618 matches
Mail list logo
