Re: importModule followup

2008-08-18 Thread Brendan Eich
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

Re: Picking property by attribute

2008-08-18 Thread Brendan Eich
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

Re: Remarks about module import

2008-08-18 Thread Brendan Eich
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

Re: local

2008-08-21 Thread Brendan Eich
On Aug 21, 2008, at 6:12 AM, Michael Haufe wrote: Perhaps Brendan or someone else can shed light on the original decision making process of let's inclusion in JavaScript 1.7? We added let to JS1.7 based on the ES4 proposal:

Re: return when desugaring to closures

2008-08-21 Thread Brendan Eich
On Aug 21, 2008, at 11:45 AM, [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 11:24 AM, Mark S. Miller [EMAIL PROTECTED] wrote: When it doesn't work, it doesn't work. But when it does work, it's highly worthwhile because it's the closest thing we've got to proper lambda abstraction. ...

Re: local

2008-08-21 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-08-21 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-08-21 Thread Brendan Eich
On Aug 21, 2008, at 7:55 PM, David-Sarah Hopwood wrote: If it were dynamic, then you'd expect: function setOptionB(x) { print(x == opt_B); } setOptions({opt_B: 42}); to print true, but it actually prints false. I don't see how. Dynamic scope means the caller's environment

Re: local

2008-08-22 Thread Brendan Eich
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

Re: Attribute defaults for Object.defineProperty

2008-08-23 Thread Brendan Eich
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

Re: Es-discuss - several decimal discussions

2008-08-23 Thread Brendan Eich
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

Re: Use of redundant var

2008-08-23 Thread Brendan Eich
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

Re: Es-discuss - several decimal discussions

2008-08-24 Thread Brendan Eich
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

Re: Es-discuss - several decimal discussions

2008-08-24 Thread Brendan Eich
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

Re: Es-discuss - several decimal discussions

2008-08-24 Thread Brendan Eich
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

Re: Es-discuss - several decimal discussions

2008-08-24 Thread Brendan Eich
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

Re: Look Ma, no this (was: ECMAScript Harmony)

2008-08-24 Thread Brendan Eich
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

Re: Es-discuss - several decimal discussions

2008-08-25 Thread Brendan Eich
On Aug 24, 2008, at 8:10 PM, Mark S. Miller wrote: On Sun, Aug 24, 2008 at 7:54 PM, Brendan Eich [EMAIL PROTECTED] wrote: If === remains as good an indistinguishability test as it is now -- with only the above two exceptions -- then I'd agree we don't need Object.eq. Libraries could

Re: Es-discuss - several decimal discussions

2008-08-25 Thread Brendan Eich
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).

Re: Look Ma, no this (was: ECMAScript Harmony)

2008-08-25 Thread Brendan Eich
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

Re: Look Ma, no this (was: ECMAScript Harmony)

2008-08-25 Thread Brendan Eich
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),

Re: Look Ma, no this (was: ECMAScript Harmony)

2008-08-25 Thread Brendan Eich
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

Re: Look Ma, no this (was: ECMAScript Harmony)

2008-08-25 Thread Brendan Eich
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

Re: Es-discuss - several decimal discussions

2008-08-25 Thread Brendan Eich
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

Re: Es-discuss - several decimal discussions

2008-08-25 Thread Brendan Eich
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

Re: eq, eql, equal [Was: Es-discuss - several decimal discussions]

2008-08-25 Thread Brendan Eich
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

Re: Look Ma, no this (was: ECMAScript Harmony)

2008-08-25 Thread Brendan Eich
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

Re: Es-discuss - several decimal discussions

2008-08-25 Thread Brendan Eich
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

Re: local

2008-08-25 Thread Brendan Eich
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, ...

Re: return when desugaring to closures

2008-08-25 Thread Brendan Eich
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

Re: Consistent decimal semantics

2008-08-25 Thread Brendan Eich
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).

Re: Look Ma, no this (was: ECMAScript Harmony)

2008-08-25 Thread Brendan Eich
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.

Re: return when desugaring to closures

2008-08-25 Thread Brendan Eich
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

Re: Look Ma, no this (was: ECMAScript Harmony)

2008-08-25 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-08-25 Thread Brendan Eich
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

Re: dynamic class idiom

2008-08-26 Thread Brendan Eich
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

Re: dynamic class idiom

2008-08-26 Thread Brendan Eich
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

Re: Proposal: opt-out local scoping

2008-08-28 Thread Brendan Eich
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

Re: Proposal: opt-out local scoping

2008-08-28 Thread Brendan Eich
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|

Re: Proposal: opt-out local scoping

2008-08-28 Thread Brendan Eich
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

Re: Sugar unrelated to macros -- Was: Re: Sugar

2008-08-28 Thread Brendan Eich
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

Re: Sugar unrelated to macros -- Was: Re: Sugar

2008-08-28 Thread Brendan Eich
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

Re: Strict undefined this

2008-08-30 Thread Brendan Eich
#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

Re: Sugar

2008-09-03 Thread Brendan Eich
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.

Re: Call for opinions: attribute defaults and renaming flexible

2008-09-03 Thread Brendan Eich
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]] =

Re: Es-discuss - several decimal discussions

2008-09-04 Thread Brendan Eich
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 =

Re: Es-discuss - several decimal discussions

2008-09-04 Thread Brendan Eich
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.

Re: Call for opinions: attribute defaults and renaming flexible

2008-09-05 Thread Brendan Eich
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,

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

2008-09-09 Thread Brendan Eich
: 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

Re: Function.prototype.bind

2008-09-09 Thread Brendan Eich
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

Re: Function.prototype.bind

2008-09-10 Thread Brendan Eich
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

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

2008-09-12 Thread Brendan Eich
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

Re: Regexp capturing groups.

2008-09-15 Thread Brendan Eich
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

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

2008-09-15 Thread Brendan Eich
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

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

2008-09-15 Thread Brendan Eich
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

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

2008-09-15 Thread Brendan Eich
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',

Re: use decimal

2008-09-17 Thread Brendan Eich
On Sep 17, 2008, at 4:01 PM, Douglas Crockford wrote: It may be best to defer decimal to Harmony so we can try some experiments and have more confidence. Absolutely agree (someone added es-discuss to the cc: list already). See

Re: use decimal

2008-09-17 Thread Brendan Eich
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

Re: use decimal

2008-09-17 Thread Brendan Eich
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

Re: Decimal comparisons

2008-09-19 Thread Brendan Eich
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

Re: Decimal comparisons

2008-09-19 Thread Brendan Eich
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

Re: Regexp capturing groups.

2008-09-22 Thread Brendan Eich
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

Re: ES3.1 Draft: 22 Sep 2008 Redmond version available

2008-09-23 Thread Brendan Eich
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

Re: ES Decimal status

2008-09-24 Thread Brendan Eich
On Sep 24, 2008, at 8:28 AM, Sam Ruby wrote: My apologies. That wasn't the question I was intending. Can you identify code that today depends on numeric binary 64 floating point which makes use of operations such as unrounded division and depends on trailing zeros being truncated to

Re: ES Decimal status

2008-09-24 Thread Brendan Eich
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

Re: ES Decimal status

2008-09-24 Thread Brendan Eich
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)

Re: Arguments and formal parameters aliasing

2008-09-27 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-09 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-09 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-09 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-09 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-10 Thread Brendan Eich
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

Re: Revenge of the double-curly [Was: return when desugaring to closures]

2008-10-10 Thread Brendan Eich
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

Re: Revenge of the double-curly [Was: return when desugaring to closures]

2008-10-10 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-10 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-10 Thread Brendan Eich
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

Re: Revenge of the double-curly [Was: return when desugaring to closures]

2008-10-11 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-11 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-11 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-11 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-11 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-13 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-13 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-13 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-13 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-13 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-13 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-13 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-13 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-13 Thread Brendan Eich
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

Re: For Loop Desugaring (was: return when desugaring to closures)

2008-10-13 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-14 Thread Brendan Eich
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

Re: For Loop Desugaring (was: return when desugaring to closures)

2008-10-14 Thread Brendan Eich
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

Re: For Loop Desugaring (was: return when desugaring to closures)

2008-10-14 Thread Brendan Eich
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

Re: For Loop Desugaring (was: return when desugaring to closures)

2008-10-14 Thread Brendan Eich
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

Re: For Loop Desugaring (was: return when desugaring to closures)

2008-10-14 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-15 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-15 Thread Brendan Eich
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

Re: Lambda vs. function

2008-10-16 Thread Brendan Eich
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

Re: return when desugaring to closures

2008-10-16 Thread Brendan Eich
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

  1   2   3   4   5   6   7   8   9   10   >