Re: Improving Function.prototype.bind

[Andrea Giammarchi]

just to make it more concrete for those interested:
http://webreflection.blogspot.com/2012/01/introducing-objecthandler.html

IDL Like description and code ... to me this is a much faster/easier/better
solution than Function#bind ... unshimmable for IE < 9 but ... you know,
some wrapper could do the trick in any case.

/**
 *  interface ObjectHandler implements EventListener {
 *  voidhandleEvent(in Event evt);
 *  voidremitEvent(in Event evt);
 *  attribute   Object  events;
 *  };
 *
 *  @link
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener
 */
var ObjectHandler = {
  handleEvent: function handleEvent(e) {
var
  events = this.events,
  type = e.type
;
if (events.hasOwnProperty(type)) {
  events[type].call(this, e);
}
  },
  remitEvent: function cancelEvent(e) {
e.currentTarget.removeEventListener(
  e.type, this, e.eventPhase === e.CAPTURING_PHASE
);
  }
};

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

Re: ES6 doesn't need opt-in

[Brendan Eich]

FTR (a broken record, sorry), I think we will do a big disservice to 
interoperation in practice (as enjoyed by future web devs) if we essentially 
fork the spec and mutate one copy (even excluding Clause 15) to be ES6.

I'm still pretty sure implementations will not fork their non-library 
codebases. Mozilla's won't. So that means the spec will be the only 
unconsolidated "implementation".

Yes, new features (especially around parameters) may combine with old 
(arguments). Let's do the case analysis and see how bad this must be. I think 
it's strictly less bad on balance, weighing the cost to implementors, than 
forking.

Forking the spec also raises the risk of more incompatible changes than those 
(few, almost none) that we intended. I'd rather bail on completion reform back 
to ES5 strict runtime semantics if that is what it takes to keep a 
consolidated/minimized spec.

/be

On Jan 9, 2012, at 12:09 PM, Allen Wirfs-Brock wrote:

> 
> On Jan 8, 2012, at 9:26 PM, Brendan Eich wrote:
> 
>> On Jan 8, 2012, at 4:53 PM, Mark S. Miller wrote:
>> 
>>> On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich  wrote:
>>> [...]
>>> 
>>> All cool with the above. Thanks.
>>> 
>>> I wrote in a previous reply that we aren't preserving ES5 as a spec 
>>> referenced from ES6. ES6 will be self-contained. So I still don't grok your 
>>> concern here.
>>> 
>>> Sorry, I missed that. In that case, I still don't understand what your plan 
>>> for ES6 is. Does the ES6 spec include the state machine and an updated form 
>>> of the ES5-non-strict portions of the ES5 spec, as referenced by that state 
>>> machine?
>> 
>> I defer to Allen, but one approach is to leave ES5-nonstrict as is, and 
>> combine strict and extended modes for the "6" in 5&6 and ES56. As you 
>> proposed!
>> 
>> HTH,
>> 
>> /be
>> 
> 
> I've been thinking about this, but I'm not yet certain about a preferred 
> approach.
> 
> One alternative is to keep the current ES5 specification( both non-strict and 
> strict) as a normative part of ECMA-262 and add a new part which is the 
> complete specification for "ES6".  Essentially Ecma-262-6 part 1 would be the 
> same as Ecma-262-5 (plus any errata level corrections) but excluding most of 
> clause 15 (the builty-in library) and Ecma-262-9 part 2 would be a 
> comprehensive specification for a language that starts with implicit ES5 
> strict mode (modulo completion reform and any other semantic changes) add new 
> ES6 features and excludes ES5 "non-strict" features and semantics.  Because 
> of the shared heap, the new clause 15 would have to apply to both the part 1 
> and part 2 languages.  The specification would have to include something like 
> my state machine which determines whether the part 1 or part 2 language is to 
> be used to process a Program.
> 
> This approach has the advantage that it simplifies the specification of the 
> new ES6 features and minimizes the risk of unintentionally changing the 
> specification of ES-5 non-strict features that must exist somewhere in the 
> specification. I'm finding various places where significant changes in 
> specification technique is required to support new feature semantics and 
> making sure that  the rewritten specification also works for legacy 
> (non-strict ES5).   However, this approach has the disadvantage that 
> implementors who what to share as much logic as possible between "ES5 mode" 
> and "ES6 mode" many have to do their own analysis of the differences and 
> commonalities.
> 
> Allen
> 
> 
> 

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

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

On Jan 8, 2012, at 10:32 AM, Brendan Eich wrote:

> On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote:
> ...
> 
>> The other change I hope fits into the same bucket is 
>> . 
>> Right now, because of pressure from test262, we are in danger of having all 
>> browsers conform to this mistake, at which point it may be too late to fix 
>> it. Today, the diversity of actual browser behaviors means it is still 
>> possible to fix this mistake, much as the diversity of ways ES3 
>> implementations were broken made it possible for ES5 to fix many mistakes.
> 
> The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC 
> and (because V8 was drafting off JSC) V8 don't nullify all that history.
> 
> On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a 
> real-world case where this matters, even with Object.create. And I see the 
> ocap (not just SES) appeal of the fix.
> 

Just to be even clearer.  This was not a mistake in ES5/5.1 and it is not a 
bug.  It is a semantics, which as Brendan points out goes all the way back to 
ES1.  It is also a behavior which makes complete sense from a prototypal 
inheritance perspective and can be found in the Self language. 

The basic idea is that the properties prototype object are shared parts of all 
of inheriting child object.  Modifying such a shared part by a child, 
introduces a local change that is visible to that child (and its children) so 
this requires creation of a "own" property on the child. However, read-only 
properties can not modified (by normal means, eg assignment) so there is no 
need to create a "own" copy.  Assigning to an inherited read-only property or a 
"own" read-only property should have the same affect (whether it is ignoring 
the assignment, throwing, etc.).  Allowing assignment to an inherited read-only 
property would break the invariant that that a prototype's readonly property is 
an immutable value that is  shared among all children of the prototype.

If there was a mistake in designing ES5, it was allowing 
Object.defineOwnProperty to create child properties that over-ride inherited 
read-only data properties.  This broke an invariant that previously existed in 
the language but this invariant  was already violated by some pre-ES5 clause 15 
objects, (eg the writability of the prototype property of some children of 
Function.prototype).  However, I think the ES5 decision was probably the right 
one given the legacy clause 15 usages and the overall reflective nature of 
defineOwnProperty).

Allen





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

Re: ES6 doesn't need opt-in

[Gavin Barraclough]

On Jan 9, 2012, at 2:59 AM, Andreas Rossberg wrote:

> I think the state machine is over-complicating things. What it boils
> down to is that we are defining a new language, ES6-proper (or
> informally ES6 for short). It overlaps with ES5 but does not include
> it (e.g. throws out `with'). Then your "state machine" simply says,
> declaratively:
> 
> - If a program is ES5 but not ES6, treat as ES5.
> - If a program is ES6 but not ES5, treat as ES6.
> - If a program is both ES5 and ES6, with identical semantics, treat as
> ES6 (although it doesn't matter).
> - If a program is both ES5 and ES6, with different semantics, treat as
> ES5 (for compatibility).
> - If a program is neither ES5 nor ES6, it's an error (obviously).

If the a program is both ES5 and ES6 with identical semantics, then presumably 
we could equally treat it as ES5 with no behavior change?

If so, couldn't this be stated in a much simpler fashion:

- If a program is ES5, treat as ES5.
- If a program is not ES5 but is ES6, treat as ES6.
- If a program is neither ES5 nor ES6, it's an error (obviously).

cheers,
G.


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

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

On Jan 8, 2012, at 9:26 PM, Brendan Eich wrote:

> On Jan 8, 2012, at 4:53 PM, Mark S. Miller wrote:
> 
>> On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich  wrote:
>> [...]
>> 
>> All cool with the above. Thanks.
>> 
>> I wrote in a previous reply that we aren't preserving ES5 as a spec 
>> referenced from ES6. ES6 will be self-contained. So I still don't grok your 
>> concern here.
>> 
>> Sorry, I missed that. In that case, I still don't understand what your plan 
>> for ES6 is. Does the ES6 spec include the state machine and an updated form 
>> of the ES5-non-strict portions of the ES5 spec, as referenced by that state 
>> machine?
> 
> I defer to Allen, but one approach is to leave ES5-nonstrict as is, and 
> combine strict and extended modes for the "6" in 5&6 and ES56. As you 
> proposed!
> 
> HTH,
> 
> /be
> 

I've been thinking about this, but I'm not yet certain about a preferred 
approach.

One alternative is to keep the current ES5 specification( both non-strict and 
strict) as a normative part of ECMA-262 and add a new part which is the 
complete specification for "ES6".  Essentially Ecma-262-6 part 1 would be the 
same as Ecma-262-5 (plus any errata level corrections) but excluding most of 
clause 15 (the builty-in library) and Ecma-262-9 part 2 would be a 
comprehensive specification for a language that starts with implicit ES5 strict 
mode (modulo completion reform and any other semantic changes) add new ES6 
features and excludes ES5 "non-strict" features and semantics.  Because of the 
shared heap, the new clause 15 would have to apply to both the part 1 and part 
2 languages.  The specification would have to include something like my state 
machine which determines whether the part 1 or part 2 language is to be used to 
process a Program.

This approach has the advantage that it simplifies the specification of the new 
ES6 features and minimizes the risk of unintentionally changing the 
specification of ES-5 non-strict features that must exist somewhere in the 
specification. I'm finding various places where significant changes in 
specification technique is required to support new feature semantics and making 
sure that  the rewritten specification also works for legacy (non-strict ES5).  
 However, this approach has the disadvantage that implementors who what to 
share as much logic as possible between "ES5 mode" and "ES6 mode" many have to 
do their own analysis of the differences and commonalities.

Allen



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

Re: ES6 doesn't need opt-in

[Brendan Eich]

On Jan 9, 2012, at 9:28 AM, Andreas Rossberg wrote:

> On 9 January 2012 16:54, Brendan Eich  wrote:
>> The question is how bad these will be for anyone writing JS naively, based 
>> on current and emerging (ES6) docs, without explicit opt-in.
>> 
>> The answer entails at least:
>> 
>> 1. ES5-strict semantic changes, e.g. arguments aliasing, without early 
>> errors.
>> 
>> 2. Completion reform.
>> 
>> 3. New early errors.
>> 
>> I think 3 is a good thing and a non-problem. Some of us hope 2 is a matter 
>> of indifference to real-world code, but we don't know for sure. That leaves 
>> 1.
> 
> Yes, but (1) is not a trivial set -- e.g. receiver coercions, eval
> semantics, delete type errors, arguments aliasing, poisoning of
> caller/arguments, etc.

You're right, there's a lot of runtime meaning shift in ES5-strict, indeed -- 
more than just parameter no-aliasing.

Still the bet we are trying to place (not done yet detailing the proposal) is 
that most people won't use explicit version-based opt-in (also, such noise gets 
lost easily over the life of code snippets), *and* that the hard cases you cite 
are rare. None is common.

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

Re: Does private(expr) create a private storage block?

[Herby Vojčík]

Hello,

well, (const-classes aside) I am looking at private store as an automatic 
hidden private name indexed block (too implementation-like look, probably, 
but helps to grasp the content). This code (horror from the design point, 
managers don't do real work, but I can not come up with better use case) 
shows some more aspects of this (as was told, private names should help 
conflict-less monkey-patching)


class CounterManager {
incrementFor (client) {
 private(client).c++;
}

startManage (client) {
 private(client).c = 0;
}

countOf (client) {
 return private(ciient).c;
}
}

Yes, I could use private name directly, but this grasps the idea from 
another point of view.
And there may be use cases where instances of a classes want to access 
private part of another instance of the same class (to do comparision, for 
example, which is read-only, but maybe there are modifying use cases, too).


So I would propose that:
- if private(foo) is used to read a property value, it should silently 
return undefined is there is no private block (with private name of the 
actual scope) in foo
- if private(foo) is used to write a value into a property, it should try to 
create private block (with name for the actual scope) if it does not exist 
and then write to it


The latter also solves the const-class instances simply - it is not possible 
to create such block for them, so it fails the same as any other attempt to 
add propoerty to a frozen object.


But it is matter of point of view, mainly, what is private about? I like 
broader views, if possible, so I see private as "privately scoped naming for 
the use of class methods (as they see fit)" than "a way to make field in 
instance only visible to method of a class" (which is, by the nature of its 
formulation, imho much harder to implement because of all the constraints it 
puts on it; general is often better).


Herby

-Pôvodná správa- 
From: Mark S. Miller

Sent: Monday, January 09, 2012 5:52 PM
To: Herby Vojčík
Cc: es-discuss@mozilla.org
Subject: Re: Does private(expr) create a private storage block?

Hi Herby, I looked back over the class proposal and found that it indeed 
leaves this case ambiguous, as you point out. We have also not discussed it 
in committee or even in separate side discussions in which I participated. I 
don't have strong feelings about this for non-const classes. For const 
classes, I think privates should always be declared in the constructor. I 
would like to be able to always allocate instances of const classes of fixed 
"shape", i.e., non-configurable / non-extensible, so that users don't have 
to worry about whether they've enabled the resulting optimizations or 
whether they have uncaught spelling errors.


For consistency, perhaps we should make similar requirements for privates of 
non-const classes, but this isn't clear. If you have some arguments one way 
or another, please post. Thanks.




On Mon, Jan 9, 2012 at 8:33 AM, Herby Vojčík  wrote:
Hello,

the current class proposal (as I read it) specifies that the private block 
is created by first 'private foo[ = "bar"];' in the constructor. The 
question is, what is constructor does not contain any private declarations, 
but uses private, like this:


...

The question is: does private(this) create the private storage block in this 
case?


Herby

--
   Cheers,
   --MarkM 


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

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

On 9 January 2012 16:54, Brendan Eich  wrote:
> The question is how bad these will be for anyone writing JS naively, based on 
> current and emerging (ES6) docs, without explicit opt-in.
>
> The answer entails at least:
>
> 1. ES5-strict semantic changes, e.g. arguments aliasing, without early errors.
>
> 2. Completion reform.
>
> 3. New early errors.
>
> I think 3 is a good thing and a non-problem. Some of us hope 2 is a matter of 
> indifference to real-world code, but we don't know for sure. That leaves 1.

Yes, but (1) is not a trivial set -- e.g. receiver coercions, eval
semantics, delete type errors, arguments aliasing, poisoning of
caller/arguments, etc.

> No other semantic changes, right? The key idea of the state machine is not 
> its exact spec (still being discussed) but that "one JS" should mean sane 
> operation or early error, based on smooth upgrade to use non-conflicting new 
> features (or conflicts, e.g. 'with' vs. 'module').
>
> Why work harder on implicit opt-in? Yes, savvy users will put a pragma on 
> line 1. Not all JS users are savvy and requiring them to become so asks too 
> much.

But it's especially the non-savvy ones that would be particularly
well-advised to put in that pragma, so that they avoid nasty surprises
beyond their grasp!

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

Re: Does private(expr) create a private storage block?

[Mark S. Miller]

Hi Herby, I looked back over the class proposal and found that it indeed
leaves this case ambiguous, as you point out. We have also not discussed it
in committee or even in separate side discussions in which I participated.
I don't have strong feelings about this for non-const classes. For const
classes, I think privates should always be declared in the constructor. I
would like to be able to always allocate instances of const classes of
fixed "shape", i.e., non-configurable / non-extensible, so that users don't
have to worry about whether they've enabled the resulting optimizations or
whether they have uncaught spelling errors.

For consistency, perhaps we should make similar requirements for privates
of non-const classes, but this isn't clear. If you have some arguments one
way or another, please post. Thanks.


On Mon, Jan 9, 2012 at 8:33 AM, Herby Vojčík  wrote:

> Hello,
>
> the current class proposal (as I read it) specifies that the private block
> is created by first 'private foo[ = "bar"];' in the constructor. The
> question is, what is constructor does not contain any private declarations,
> but uses private, like this:
>
> class Coutner {
>  constructor () {
>   this.reset();
>  }
>
>  increment () {
>   private(this).c++;
>  }
>
>  reset () {
>   private(this).c = 0;
>  }
>
>  get count () {
>   return private(this).c;
>  }
> }
>
> The reset method is part of the API. Conveniently, it resets the state of
> the object to the initial state, so constructor is calling it.
> The question is: does private(this) create the private storage block in
> this case?
>
> Herby
> __**_
> 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

Does private(expr) create a private storage block?

[Herby Vojčík]

Hello,

the current class proposal (as I read it) specifies that the private block 
is created by first 'private foo[ = "bar"];' in the constructor. The 
question is, what is constructor does not contain any private declarations, 
but uses private, like this:


class Coutner {
 constructor () {
   this.reset();
 }

 increment () {
   private(this).c++;
 }

 reset () {
   private(this).c = 0;
 }

 get count () {
   return private(this).c;
 }
}

The reset method is part of the API. Conveniently, it resets the state of 
the object to the initial state, so constructor is calling it.
The question is: does private(this) create the private storage block in this 
case?


Herby 


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

Re: Improving Function.prototype.bind

[Brendan Eich]

On Jan 9, 2012, at 12:29 AM, David Bruant wrote:

> Le 09/01/2012 06:29, Brendan Eich a écrit :
>> 
>> On Jan 8, 2012, at 7:20 PM, John J Barton wrote:
>> 
>>> On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich  wrote:
 Firebug uses a library bind a lot, and we continually struggled with the 
 memoization problem; we did not try to solve it in part because we hated 
 Firebug's bind: it made debugging even more painful since it messes up the 
 call stack. Using the ES bind() ends up not being a win, since I now have 
 exactly the same problems.
>>> 
>>> I have a question: why is bind used so much in Firebug for event listeners, 
>>> when the DOM guarantees to dispatch them with the event target bound to 
>>> |this|? Way back in '95, I created event handlers but did not add bind (it 
>>> had to be discovered later). But dynamic |this| binding combined with DOM 
>>> event target-based listening and handling kept this properly bound. What 
>>> has changed?
>>> 
>>> Sorry I don't know what you mean here.
>> 
>> Why all the this-binding in Firebug if (as you suggested and a grep seems to 
>> confirm [but I skimmed]) the methods being this-bound are all or mostly 
>> event listeners? The DOM dispatches event handlers on the correct |this|.
> Relevant related documentation: 
> https://developer.mozilla.org/en/JavaScript/Reference/Operators/this#As_a_DOM_event_handler

Do you mean this "(some browsers do not follow this convention for listeners 
added dynamically with methods other than addEventListener)." part? Ghastly but 
not browsers Firebug targets (namely, Firefox), right? 

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

Re: ES6 doesn't need opt-in

[Brendan Eich]

On Jan 9, 2012, at 7:54 AM, Brendan Eich wrote:

> The question is how bad these will be for anyone writing JS naively, based on 
> current and emerging (ES6) docs, without explicit opt-in.
> 
> The answer entails at least:
> 
> 1. ES5-strict semantic changes, e.g. arguments aliasing, without early errors.

I should have written more, since "without early errors" is an assumption, not 
a requirement. Allen's state machine o.p discussed this more. From Allen's o.p.:

ES5~EAS6:  The construct has identical syntax and static semantics in both ES5 
and ES6, but differing semantics.  For example, accessing a formal parameter 
after an assignment to the corresponding element of the function's arguments 
object.

This triggers different state transitions.

I'm working on SpiderMonkey now, and we already must analyze for arguments[i] 
and formal parameter assignments to deoptimize nonstrict code. The main 
challenge is good error blame when the compiler detects a conflict requiring an 
early error. You want to blame both the (possibly much earlier) formal or 
arguments[i] assignment, and the later ES6 feature.

I believe that all current optimizing JS engines have to do this kind of 
analysis. So I wonder if it wouldn't be "easy" (not sure how normative we make 
this) to deal with (1) with early errors.

/be

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

Re: ES6 doesn't need opt-in

[Brendan Eich]

On Jan 9, 2012, at 2:49 AM, Andreas Rossberg wrote:

> On 5 January 2012 20:10, Brendan Eich  wrote:
>> On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote:
>>> Sorry, I still think that a growing set of subtle implicit rules for
>>> activating subtle semantic changes
>> 
>> Not changes, new semantics for new syntax.
> 
> I was referring to strict vs classic mode. The way I understood the
> discussion so far, certain syntax would implicitly opt into extended
> mode, and thereby also into strict mode -- locally, and from classic.
> That implies semantic changes for existing features.

The question is how bad these will be for anyone writing JS naively, based on 
current and emerging (ES6) docs, without explicit opt-in.

The answer entails at least:

1. ES5-strict semantic changes, e.g. arguments aliasing, without early errors.

2. Completion reform.

3. New early errors.

I think 3 is a good thing and a non-problem. Some of us hope 2 is a matter of 
indifference to real-world code, but we don't know for sure. That leaves 1.

No other semantic changes, right? The key idea of the state machine is not its 
exact spec (still being discussed) but that "one JS" should mean sane operation 
or early error, based on smooth upgrade to use non-conflicting new features (or 
conflicts, e.g. 'with' vs. 'module').

Why work harder on implicit opt-in? Yes, savvy users will put a pragma on line 
1. Not all JS users are savvy and requiring them to become so asks too much.


> [The discussion seems to have changed direction again with Allen's
> "state machine" idea. That probably makes some of my comments
> obsolete. Sorry for lagging behind.]

No problem.

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

Re: ES6 doesn't need opt-in

[Claus Reinke]

But the new plan reminds me strongly of bad experiences in Haskell-land.

That sounds interesting. Is this documented somewhere?


Not really documented, more my experience from having followed
various Haskell lists and forums for over 15 years now (*).

I have often seen the pattern where a language or library design
choice was discussed in length and detail in the appropriate sub-forum,
then decided on, implemented, and rolled out, at first without a
hitch, as long as it only affected those directly in the know; then,
a couple of months later or so, the main forums would start seeing
trouble reports from users who didn't use the new feature directly,
but who where relying on code (applications/libraries) whose
_dependencies_ where affected by the change.

When Haskell implementations still had monolithic flags to enable
all extensions at once, it would happen like this: some dependency D
would not compile in standard mode, because it needed one of the
extended language features, say F1; so extended mode had to be
enabled for that dependency D, and sometimes for the whole project
P; but, in extended mode, _all_ extended features were enabled,
including the one feature F2 that had recently been changed; enabling
the new version of F2 would then interfere with compilation of either
D or P, hopefully via an early error - compilation failure.

But the dependency D had been written long before F2 had been
redesigned, and P itself had no direct uses of either F1 or F2, only
via the dependency D. So the authors/maintainers of D and P had
no idea of the discussion that led to the change of F2, they just saw
an early error for code that used to work (and would still work, but
for the fact that they had upgraded to newer implementations).

Similar fun ensued when authors started to use some extensions,
but had to enable all extensions to make their code compile: in
addition to the extended features they were working with, their
code was now also affected by all other extended features, often
expert-mode extensions that they had no idea about.

When Haskell implementations started using explicit feature-based
versioning, thing calmed down considerably. Library authors would
select the set of extensions they needed to use, and enable them
only for their code (think of it as a specification of a language "API").
So neither their library code nor the code of library clients were
affected by unrelated features (or changes to unrelated features).

And authors moving into language extensions would also enable
them one by one, slowly building up to the level of complexity and
expertise they needed. Blog posts would mention which extensions
needed to be enabled to make examples run. When code used a
language extension, the compiler would complain that this wasn't
part of the portable standard, and suggest which pragma to use in
order to enable just this one extension.

That doesn't mean that all problems are solved (eg, library versioning
remains an interesting problem), but language extensions cause less
trouble than they used to, and there is much less pressure for extending
the language standard (Haskell 2010 is still very conservative, but a
small flood of extensions are available, selectively).

Claus

(*) For background, the early history of Haskell is documented
   in this HOPL-III paper (no discussion of feature-based versioning,
   but describes the early language revisions, up to the long-time
   standard Haskell98, as well as some of the extensions, and the
   conflict between language design experimentation and stability):

   "A History of Haskell: being lazy with class", 2007
   
http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm



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

Re: Improving Function.prototype.bind

[Andrea Giammarchi]

sorry, wrong debug, currentTarget is always the expected one ... my bad

On Mon, Jan 9, 2012 at 10:44 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Bear in mind e.currentTarget may be undefined  e.g. in an about:blank
> page
>
> document.addEventListener("click", function (e)
> {console.log(e.currentTarget)}, false);
>
> would be null
>
> On Mon, Jan 9, 2012 at 9:29 AM, David Bruant  wrote:
>
>>  Le 09/01/2012 06:29, Brendan Eich a écrit :
>>
>>  On Jan 8, 2012, at 7:20 PM, John J Barton wrote:
>>
>>  On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich wrote:
>>
>>>Firebug uses a library bind a lot, and we continually struggled with
>>> the memoization problem; we did not try to solve it in part because we
>>> hated Firebug's bind: it made debugging even more painful since it messes
>>> up the call stack. Using the ES bind() ends up not being a win, since I now
>>> have exactly the same problems.
>>>
>>>
>>>  I have a question: why is bind used so much in Firebug for event
>>> listeners, when the DOM guarantees to dispatch them with the event target
>>> bound to |this|? Way back in '95, I created event handlers but did not add
>>> bind (it had to be discovered later). But dynamic |this| binding combined
>>> with DOM event target-based listening and handling kept this properly
>>> bound. What has changed?
>>>
>>>   Sorry I don't know what you mean here.
>>
>>
>>  Why all the this-binding in Firebug if (as you suggested and a grep
>> seems to confirm [but I skimmed]) the methods being this-bound are all or
>> mostly event listeners? The DOM dispatches event handlers on the correct
>> |this|.
>>
>> Relevant related documentation:
>> https://developer.mozilla.org/en/JavaScript/Reference/Operators/this#As_a_DOM_event_handler
>>
>> David
>>
>> ___
>> 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: Improving Function.prototype.bind

[Andrea Giammarchi]

indeed ... inline functions are problem number 2, anonymous or not, unless
the removeEventListener is not performed inside the function itself so that
at least the function name could be reused while if anonymous and "use
strict" is in place there's no way to know which function is it.

However, two inline functions cannot possibly be the same object so, as
problem itself, I would not even consider to solve this.

br

On Mon, Jan 9, 2012 at 12:35 PM, David Bruant  wrote:

> Le 08/01/2012 19:47, John J Barton a écrit :
>
>> (...)
>>
>>   window.addEventListener('load'**, boundOnLoad, false);
>>   ...
>>   window.removeEventListener('**load', boundOnLoad, false);
>> The JS method 1) must be bound to the correct object 2) be reference-able
>> for the removeEventListener.
>>
>> This combination prevents simple inline functions so commonly used by JS
>> devs from being applied to DOM event registration, a very common use of
>> inline functions. If you use an inline function without bind(), then it
>> will not have the correct object binding; if you use an inline function
>> with bind(), then it will not be reference-able for the remove. (...)
>>
> If you want to use inline (anonymous) functions, you always loose the
> ability to reference the function for a later remove. This is independent
> of bind.
> Inline functions are not compatible with remove.
>
> David
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[David Bruant]

Le 08/01/2012 19:47, John J Barton a écrit :

(...)
   window.addEventListener('load', boundOnLoad, false);
   ...
   window.removeEventListener('load', boundOnLoad, false);
The JS method 1) must be bound to the correct object 2) be 
reference-able for the removeEventListener.


This combination prevents simple inline functions so commonly used by 
JS devs from being applied to DOM event registration, a very common 
use of inline functions. If you use an inline function without bind(), 
then it will not have the correct object binding; if you use an inline 
function with bind(), then it will not be reference-able for the 
remove. (...)
If you want to use inline (anonymous) functions, you always loose the 
ability to reference the function for a later remove. This is 
independent of bind.

Inline functions are not compatible with remove.

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

Re: Boolean shortcuts

[Herby Vojčík]

Hi,

I have looked at the links and as I understand they are trying to accomplish 
something slightly different, by adopting code as kind of data, though it is 
interesting, too (and your are true do-expressions do it elegantly, except 
for the "explicit zero-arg lambda" thing (I think || is not tragedy)".


I was trying to do something different - not bring code verbatim into data, 
but powerful code constructs into data - I had posted it in thread "RFC: 
Empowered data - unification of code block and object literal(and class)". 
It more a unification of code block and data block to be more similar in 
appearance as well as expressiveness (while retaining their 
imperatice/declarative nature).


As for the "empty-block/object issue" I realized it is a non-issue (or, 
little issue), I was freaked out. :-) This is old known things that {}.f() 
does not work until one parenthesizes {} and it is the same (anooying, but 
nothing breakingly new) category of quirk.


Herby

P.S.: Still got no comment on above-mentioned thread. :-(

P.P.S.: And back to boolean shortcuts: would there be a possibility (and 
demand for them)? I posted my '{ value: "foo", configurable, writable, 
!enumerable }' and 'var !done, !!soFarSoGood' and someone mentioned there is 
this kind of proposal in CoffeeScript land which goes more like '{ value: 
"foo", +configurable, +writable, -enumerable }' and 'var -done, 
+soFarSoGood'.


-Pôvodná správa- 
From: Brendan Eich

Sent: Thursday, January 05, 2012 12:03 AM
To: es-discuss
Subject: Re: Boolean shortcuts

On Jan 4, 2012, at 2:56 PM, Brendan Eich wrote:


On Jan 4, 2012, at 1:57 PM, Herby Vojčík wrote:


Hi,

as I already posted in the parallel thread, there is that strawman called 
"do expression" by dherman that does just that.


I feel like crying when I see how powerful data constructs could be if 
not hampered by "possible to parse as code block" ambiguity.


Yes, I have felt like crying too -- I did some work (see 
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015568.html)


I should have also linked:

http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal

Of course,

http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions

is much simpler.

Neither addresses the empty-block/object issue by trying to evaluate {} as 
an object literal where today it's a block statement.


/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: ES6 doesn't need opt-in

[Andreas Rossberg]

On 6 January 2012 03:37, Allen Wirfs-Brock  wrote:
> Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics 
> to a Program unit
>
> In an "ES6" implementation, all constructs that can occur in a valid program 
> fit into one of these categories:
> ES6-only:  The construct is based upon syntax or static semantics rules that 
> only exist in ES6.  For example, a destructuring pattern
> ES5-only:  The construct is based upon syntax that or static semantics rules 
> that that are not in ES6. For example, use of a with statement t.
> ES5&ES6:  The construct has identical semantics in both ES5 and ES6.
> ES5~EAS6:  The construct has identical syntax and static semantics in both 
> ES5 and ES6, but differing semantics.  For example, accessing a formal 
> parameter after an assignment to the corresponding element of the function's 
> arguments object.
>
> We can then use the following state machines to describes the processing of a 
> Program based upon the occurrence for these feature categories.  Initially 
> start in State 5&6:

I think the state machine is over-complicating things. What it boils
down to is that we are defining a new language, ES6-proper (or
informally ES6 for short). It overlaps with ES5 but does not include
it (e.g. throws out `with'). Then your "state machine" simply says,
declaratively:

- If a program is ES5 but not ES6, treat as ES5.
- If a program is ES6 but not ES5, treat as ES6.
- If a program is both ES5 and ES6, with identical semantics, treat as
ES6 (although it doesn't matter).
- If a program is both ES5 and ES6, with different semantics, treat as
ES5 (for compatibility).
- If a program is neither ES5 nor ES6, it's an error (obviously).

I very much like that opt-in would be for whole programs only. I think
that is good, and IMHO progress over some of the earlier discussion.

But still, deciding what semantics a program has can depend on very
minor syntactic details. This has several potential problems:

1. For eternity, we will require future programmers to remember what
exact features were introduced with ES6, in order to be sure that they
trigger the right (i.e. strict) semantics for their program.

2. The syntactic trigger in a given program may be hidden somewhere
deep down the source code, which makes it very difficult to decide for
the reader (and the compiler, which may have to do extra work in the
parser to decide).

3. Apparently minor local modifications may accidentally change the
semantics of the whole program.

The obvious way to avoid all these issues is to always put an explicit
trigger at the top. And I expect that style guides would recommend
that. But that kind of defeats the purpose, doesn't it? I still
haven't heard a convincing argument why it is advantageous to not make
this explicit trigger mandatory.

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

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

On 5 January 2012 20:10, Brendan Eich  wrote:
> On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote:
>> Sorry, I still think that a growing set of subtle implicit rules for
>> activating subtle semantic changes
>
> Not changes, new semantics for new syntax.

I was referring to strict vs classic mode. The way I understood the
discussion so far, certain syntax would implicitly opt into extended
mode, and thereby also into strict mode -- locally, and from classic.
That implies semantic changes for existing features.

[The discussion seems to have changed direction again with Allen's
"state machine" idea. That probably makes some of my comments
obsolete. Sorry for lagging behind.]

>> on a fine-grained level is far more
>> confusing (and error-prone!) than helpful. In all sorts of ways.
>
> Our experience was that adding new features to the default version where 
> there was no backward incompatibility was not confusing. We've been doing 
> this since 2006. Not to say all the particulars are right, or that we 
> anticipated all the combinations of ES5-strict and Harmony, of course! But I 
> think you protest too much without evidence.

Yes, but these didn't imply semantic changes to existing features,
like with implicit strict mode opt-in.

>> I'm also concerned about the 3 and a half language modes that might
>> result. With Dave's original proposal at least, the only opt-in was on
>> module level.
>
> Dave mentioned generators, IIRC. We were thinking of classes too (talked 
> about it privately).
>
>
>> That precluded a number of highly undesirable
>> combinations, e.g. extended mode nested into a "with" statement.
>
> You can "use strict"; in a with statement's body block. But see below, I 
> agree the opt in has to be "chunky", and is in the (not perfectly clear, 
> complete, etc.) proposal for "ES6 doesn't need [version] opt-in".

We had been discussing opting in a function if it's using
destructuring on its parameters, for example. I would count that as a
case that is not "chunky" enough, because it can be local to "evil"
classic features and e.g. screw up lexical scoping. Likewise
generators. I really think we should avoid these cases.

[Now the idea seems to be that any ES6 feature would always opt-in the
whole program. A like that much better, but it is not what Dave
originally proposed, and what we had been discussing before, as far as
I can tell.]

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

Re: Improving Function.prototype.bind

[Andrea Giammarchi]

Just to make the second proposal easier to understand:


// abstract __proto__
var AbstractEventHandler = {
  // invoked when events are fired
  handleEvent: function (e) {
var
  events = this.events,
  type = e.type
;
if (events.hasOwnProperty(type)) {
  events[type].call(this, e);
}
  },
  // shortcut to drop events
  cancelEvent: function (e) {
(e.currentTarget || document).removeEventListener(
  e.type, this, e.eventPhase !== e.BUBBLING_PHASE
);
  }
};

// generic "class"
function WhateverUIClass(){}
// extends AbstractEventHandler
WhateverUIClass.prototype = Object.create(
  WhateverUIClass.prototype,
  {
// extends AbstractEventHandler
handleEvent: {value: AbstractEventHandler.handleEvent},
cancelEvent: {value: AbstractEventHandler.cancelEvent},

// implements events
events: {value: {
  "click": function (e) {
console.log(this instanceof WhateverUIClass, e.type, e.eventPhase);
// to remove the event, if necessary
this.cancelEvent(e);
  }
}}
  }
);

document.addEventListener("click", new WhateverUIClass, false);
document.addEventListener("click", new WhateverUIClass, true);


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

Re: Improving Function.prototype.bind

[Andrea Giammarchi]

Bear in mind e.currentTarget may be undefined  e.g. in an about:blank
page

document.addEventListener("click", function (e)
{console.log(e.currentTarget)}, false);

would be null

On Mon, Jan 9, 2012 at 9:29 AM, David Bruant  wrote:

>  Le 09/01/2012 06:29, Brendan Eich a écrit :
>
>  On Jan 8, 2012, at 7:20 PM, John J Barton wrote:
>
>  On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich  wrote:
>
>>Firebug uses a library bind a lot, and we continually struggled with
>> the memoization problem; we did not try to solve it in part because we
>> hated Firebug's bind: it made debugging even more painful since it messes
>> up the call stack. Using the ES bind() ends up not being a win, since I now
>> have exactly the same problems.
>>
>>
>>  I have a question: why is bind used so much in Firebug for event
>> listeners, when the DOM guarantees to dispatch them with the event target
>> bound to |this|? Way back in '95, I created event handlers but did not add
>> bind (it had to be discovered later). But dynamic |this| binding combined
>> with DOM event target-based listening and handling kept this properly
>> bound. What has changed?
>>
>>   Sorry I don't know what you mean here.
>
>
>  Why all the this-binding in Firebug if (as you suggested and a grep
> seems to confirm [but I skimmed]) the methods being this-bound are all or
> mostly event listeners? The DOM dispatches event handlers on the correct
> |this|.
>
> Relevant related documentation:
> https://developer.mozilla.org/en/JavaScript/Reference/Operators/this#As_a_DOM_event_handler
>
> David
>
> ___
> 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: Improving Function.prototype.bind

[David Bruant]

Le 09/01/2012 06:29, Brendan Eich a écrit :

On Jan 8, 2012, at 7:20 PM, John J Barton wrote:

On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich > wrote:



Firebug uses a library bind a lot, and we continually struggled
with the memoization problem; we did not try to solve it in part
because we hated Firebug's bind: it made debugging even more
painful since it messes up the call stack. Using the ES bind()
ends up not being a win, since I now have exactly the same problems.


I have a question: why is bind used so much in Firebug for event
listeners, when the DOM guarantees to dispatch them with the
event target bound to |this|? Way back in '95, I created event
handlers but did not add bind (it had to be discovered later).
But dynamic |this| binding combined with DOM event target-based
listening and handling kept this properly bound. What has changed?

Sorry I don't know what you mean here.


Why all the this-binding in Firebug if (as you suggested and a grep 
seems to confirm [but I skimmed]) the methods being this-bound are all 
or mostly event listeners? The DOM dispatches event handlers on the 
correct |this|.
Relevant related documentation: 
https://developer.mozilla.org/en/JavaScript/Reference/Operators/this#As_a_DOM_event_handler


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

Re: Improving Function.prototype.bind

[Andrea Giammarchi]

I would be more than happy to go on with "libraries first" approach as long
as we don't have to wait 6 years before a needed feature is going to be
considered.

I have also raised the problem because it is in my opinion underestimated
but mainly because I would like to avoid the fragmentation of
implementations that Function#bind had indeed in its past.

My proposal was more like: would an Object.prototype.boundTo method make
sense?
If in this discussion list the outcome would be "Yes, it does" then me and
other libraries author may already consider, at least, the proposal, and
implement the best way they want with or without WeakMap shims in the
meanwhile.

If the answer is "No, bind should never be objects matter" then I could
come up with different proposal as long as we agree on a solution that
could be considered in TC39 too.

As summary, I am trying to find a "direction" able to solve this problem.
Even an interface, as common implementation independent direction, would be
fine ... something based on handleEvent property, another pattern rarely
seen out there, but with clear idea of how the whole problem would be
solved ... example:

// does not have to be in the global Object, just saying
Object.prototype.handleEvent = function handleEvent(evt) {
  // if there is some standard/agreed way to invoke meant method ...
  // let's use this pattern ...
  this["onEvent" + evt.type.slice(0, 1).toUpperCase() +
evt.type.slice(1)](evt);
};

// let's say that if the object is an object
// no need to implement handleEvent
// because everything is handled automagically
// behind the scene ...
window.addEventListener("resize", {
  onEventResize: function (evt) {
window.removeEventListener(evt.type, this, false);
  }
}, false);

So that if handleEvent is not explicit, the onEvent + event.type will be
fired ... I am not sure it's clear what I mean ... but this would be
another proposal I'd like to hear feedbacks about

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