Re: Futures (was: Request for JSON-LD API review)

classic Classic list List threaded Threaded
143 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

Re: Futures (was: Request for JSON-LD API review)

Mark S. Miller-2
[+es-discuss]


On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller <[hidden email]> wrote:
Frankly, DOMFutures have nothing to do with the DOM, other than the fact that the DOM would benefit from using them -- as would many other APIs. There is nothing browser specific about this, and much that is JavaScript specific. There is no reason for this to be under the jurisdiction of the w3c. There is already a promise strawman cooking for ES7 at http://wiki.ecmascript.org/doku.php?id=strawman:concurrency . More recently, the discussions for settling the promise spec have moved to https://github.com/promises-aplus/promises-spec/issues?state=open . When DOMFutures began, it was incompatible with promises in annoying ways. Fortunately, through much good work by Alex on the DOMFutures side and many people on the promises side, DOMFutures is now mostly compatible with Promises/A+. I respect the work Alex has done on this. But it is still proceeding within the wrong organization.

The main argument I've heard for proceeding with w3c/DOMFutures rather than tc39/promises is that the DOM can't wait for tc39 to get around to standardizing promises in ES7. But we should have our eyes open to the consequences. As Crockford says (paraphrasing Knuth) "Premature standardization is the root of all evil." The likely result of DOMFuture proceeding in this way is that it will be wrong, ES7 will be stuck with it and mostly unable to fix it, and we will all be stuck with the consequences for a very very long time.

As with Object.observe, if the need for promises is that urgent, it needs to be on an accelerated track with the JavaScript context -- as it already de facto is at promises/A+. It should not be needlessly tied to the browser or to w3c.



On Wed, Apr 17, 2013 at 7:24 AM, Norbert Lindenberg <[hidden email]> wrote:
On Apr 16, 2013, at 16:55 , Tab Atkins Jr. wrote:

> On Tue, Apr 16, 2013 at 8:30 AM, Markus Lanthaler
> <[hidden email]> wrote:
>> After a short discussion with Robin we decided to use method overloading to

>> We also considered Futures but decided that introducing a normative
>> dependency to the DOM spec is not acceptable at this stage.

> In this case, your API is a textbook example of Futures.  You have an
> async call which returns a single value, or an error.  You can't get
> much more perfect than that.

Maybe Futures should be in a separate spec? They don't seem to have any dependencies on DOM, and having them separate would reduce the bureaucratic hurdles for non-DOM specs to refer to them. Maybe eventually they could migrate into the ECMAScript standard library (currently known as ES chapter 15).

Norbert






--
    Cheers,
    --MarkM



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Futures (was: Request for JSON-LD API review)

Anne van Kesteren
> On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller <[hidden email]> wrote:
>> The main argument I've heard for proceeding with w3c/DOMFutures rather
>> than tc39/promises is that the DOM can't wait for tc39 to get around to
>> standardizing promises in ES7. But we should have our eyes open to the
>> consequences. As Crockford says (paraphrasing Knuth) "Premature
>> standardization is the root of all evil." The likely result of DOMFuture
>> proceeding in this way is that it will be wrong, ES7 will be stuck with it
>> and mostly unable to fix it, and we will all be stuck with the consequences
>> for a very very long time.
>>
>> As with Object.observe, if the need for promises is that urgent, it needs
>> to be on an accelerated track with the JavaScript context -- as it already
>> de facto is at promises/A+. It should not be needlessly tied to the browser
>> or to w3c.

I don't find the whole who owns what discussions very interesting to
be honest. If it was up to me JavaScript would just be part of the W3C
and we would not have to deal with that layer of distraction.

In any event, you can take the specification and improve on it
elsewhere if you so desire. It is in the public domain for a reason.
You can also provide technical feedback as to what exactly is evil.
Saying "stop doing this" and implying you're somehow the superior
forum to the other party is not helpful and has certainly not helped
in the past.


--
http://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Futures (was: Request for JSON-LD API review)

Mark S. Miller-2
On Wed, Apr 17, 2013 at 8:46 AM, Anne van Kesteren <[hidden email]> wrote:
> On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller <[hidden email]> wrote:
>> The main argument I've heard for proceeding with w3c/DOMFutures rather
>> than tc39/promises is that the DOM can't wait for tc39 to get around to
>> standardizing promises in ES7. But we should have our eyes open to the
>> consequences. As Crockford says (paraphrasing Knuth) "Premature
>> standardization is the root of all evil." The likely result of DOMFuture
>> proceeding in this way is that it will be wrong, ES7 will be stuck with it
>> and mostly unable to fix it, and we will all be stuck with the consequences
>> for a very very long time.
>>
>> As with Object.observe, if the need for promises is that urgent, it needs
>> to be on an accelerated track with the JavaScript context -- as it already
>> de facto is at promises/A+. It should not be needlessly tied to the browser
>> or to w3c.

I don't find the whole who owns what discussions very interesting to
be honest. If it was up to me JavaScript would just be part of the W3C
and we would not have to deal with that layer of distraction.

In any event, you can take the specification and improve on it
elsewhere if you so desire. It is in the public domain for a reason.
You can also provide technical feedback as to what exactly is evil.
Saying "stop doing this" and implying you're somehow the superior
forum to the other party is not helpful and has certainly not helped
in the past.

Hi Anne, promises were already in progress for ES7. It was the w3c that chose to fork the effort rather than participate and provide feedback. Given then, let's paraphrase your advice simply by swapping the roles, in order to keep things historically accurate:

(paraphrasing)
I don't find the whole who owns what discussions very interesting to
be honest. If it was up to me the W3C would stop biting off on more 
than they can chew, and would particularly avoid starting turf wars 
with other organizations, and we would not have to deal with that 
layer of distraction.

In any event, you can take the [promise] specification and improve on it
elsewhere if you so desire. It is in the public domain for a reason.
You can also provide technical feedback as to what exactly is evil.
Saying "stop doing this" and implying you're somehow the superior
forum to the other party is not helpful and has certainly not helped
in the past.


I'll note that I didn't feel the need to change one word of your last sentence.

 


--
http://annevankesteren.nl/



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Futures (was: Request for JSON-LD API review)

Anne van Kesteren
On Wed, Apr 17, 2013 at 4:56 PM, Mark S. Miller <[hidden email]> wrote:
> Hi Anne, promises were already in progress for ES7. It was the w3c that
> chose to fork the effort rather than participate and provide feedback.

Okay, lets assume promises are not in the DOM specification. How soon
do you think we can get a specification we can use for the dozens of
APIs in development today? I put them in the DOM specification because
waiting for ES7 will get us even more "W3C is terrible at APIs!!1!".
It's also still not clear what you think is wrong with the current
text. Naming?

(Technically it's not part of any W3C draft by the way, but I guess
the sentiment is the same either way.)


--
http://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Futures (was: Request for JSON-LD API review)

Anne van Kesteren
On Wed, Apr 17, 2013 at 5:06 PM, Anne van Kesteren <[hidden email]> wrote:
> [...]

My previous experience has been trying to get bytes in JavaScript
(mostly for XMLHttpRequest): asked from TC39 in 2006. Eventually
delivered by Khronos for WebGL. Mourned over by TC39 (and others,
myself included) in 2012. If the party "responsible" for delivering
the solution does not deliver, it will happen elsewhere. And to some
extent that seems good, as it keeps everyone alert and the platform is
not held hostile to the progress (and process) of a single entity.

As I mentioned elsewhere, the platform needs more primitives. IO
streams, event streams (or signals), futures, ... I have no strongly
held believes as to where these should be hosted, I just know that we
need them, soon. And getting them soon in JavaScript seems hard as
you'd have to lift up the event loop model defined in HTML somehow to
the language level.


--
http://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Futures

Alex Russell-4
In reply to this post by Mark S. Miller-2
Mark: It's also unfortunate and incorrect to say "the w3c forked this". This plan was fleshed out on public-script-coord and you've been part of the evolution of the proposal ever since. I don't understand what, if anything, you're objecting to.


On Wed, Apr 17, 2013 at 5:49 PM, Robin Berjon <[hidden email]> wrote:
On 17/04/2013 17:56 , Mark S. Miller wrote:
Hi Anne, promises were already in progress for ES7. It was the w3c that
chose to fork the effort rather than participate and provide feedback.

Just to be crystal clear here, the W3C hasn't done anything at this point. DOMFutures currently only exist in a WHATWG spec. Given W3C's close and cosy relationship with WHATWG though, I certainly expect groups to start using it pretty much immediately so I understand if you might see that as a distinction without a difference.

Having said that, the only reason we're collectively having what might amount to a form of turf war is because we're all tilling the same turf, and despite having goals that are overwhelmingly the same we're doing so from somewhat distant houses.

I don't think that Anne's comment stemmed from some form of imperialistic view of W3C taking over everything (that's not quite like him :), but rather simply intended to point out that it would be simpler if we did all of this under a common roof. Indeed, we can make plans for coordination as we just did, but coordination happens because there's a disconnect. Removing the disconnect can be helpful too.

I have no idea what the politics of such a rapprochement would look like, and I can certainly imagine a variegated spectrum of modalities for it. I just want to point out that if there's interest, there are people over here happy to help make it happen. At the end of the day we just want a better platform with the minimum cost in bureaucracy.

--
Robin Berjon - http://berjon.com/ - @robinberjon



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))

David Bruant-5
In reply to this post by Anne van Kesteren
[es-discuss only fork]

Hi,

I'm forking this as I feel it surfaces an issue which I analyse as being
rooted in the "ECMAScript organization". As I describe my opinion below,
please feel free to tell me I'm wrong in my analysis.
I'm sorry this is not a technical discussion, but I nonetheless believe
that it is a really important discussion to have.

Anne van Kesteren wrote:

> On Wed, Apr 17, 2013 at 4:56 PM, Mark S. Miller <[hidden email]> wrote:
> > Hi Anne, promises were already in progress for ES7. It was the w3c that
> > chose to fork the effort rather than participate and provide feedback.
>
> Okay, lets assume promises are not in the DOM specification. How soon
> do you think we can get a specification we can use for the dozens of
> APIs in development today?
>
> (Technically it's not part of any W3C draft by the way, but I guess
> the sentiment is the same either way.)

I don't think W3C forked the progress that was being done on the
ECMAScript side. I believe Alex Russel led an initiative [1] with a
handful of people. I believe in the good faith of this initiative.
This initiative isn't related to the W3C from what I know (Alex will
correct me if necessary). The reasons why Alex didn't choose to follow
up on the existing strawman ES-side [2] remain an unanswered question as
far as I'm concerned. It'd be interesting to have an expression on this
topic.

The major point here is that the different specs of the web platform
needs to stop reinventing the wheel when it comes to the Promise/Future
pattern and should agree on a shared idiom.

I have suggested [3] that promises should be part of ECMAScript, but
this didn't happen. Others seem to believe ECMAScript would be a better
place for a Promise/Future built-in library.
Why hasn't it happened? or, to repeat Anne's question: "How soon do you
think we can get a specification [for promise/future in ECMAScript] we
can use for the dozens of APIs in development today?"

I'm interested in the opinions of the different people who will read
this message.
My thoughts are as follow:
Although promises were planned for ES7, they weren't part of any formal
spec. As far as I know, no recent TC39 meetings even mentioned the
concurrency strawman [2].
No formally accepted and agreed upon spec makes ES7 promises and the
concurrency strawman virtually inexistent. The current largely informal
agreement on the concurrency strawman doesn't solve the current problem
of the web platform using promises/futures.

I believe the problem lies in that ECMAScript has a monolitic spec
snapshot model. This model doesn't allow the flexibility needed by
WebIDL and the web platform which are an important consumer of the spec.
I believe this is why the WHATWG was chosen to host the Future spec work
[4].

Assuming this is the agree cause, would it make sense for the ECMAScript
spec model to change to fit the flexibility needs of WebIDL and the web
platform?
I'm also going to ask a pretty violent question, but: does it still need
to be spec'ed by ECMA? The only argument I've heard in favor of staying
at ECMA is that some people still find ISO standardization and Word/PDF
important. Can this be re-assessed? Especially given the recent
promise/future mess?
Other parts of the platform (thinking of DOM, DOM Events, XHR,
forgetting about HTML5 specifically) have survived to the living
standard model with success. The rumor on the street is that their
latest editor draft of a lot of W3C is in HTML format; that would
encourage a tighter feedback loop.
Node.js is becoming more and more popular and I don't believe ECMAScript
5.1 being an ISO standard is that important for the people interested in
Node.js (probably even the business-focused ones).

To a large extent the flexibility I'm asking for is already in place
between TC39 and implementors (features are prototyped before being
fully spec'ed). It just needs to be extended to another important
consumer of the spec that is WebIDL.

David

[1] https://github.com/slightlyoff/DOMFuture
[2] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
[3] https://mail.mozilla.org/pipermail/es-discuss/2012-November/026188.html
[4] http://dom.spec.whatwg.org/#futures
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))

Tab Atkins Jr.
On Wed, Apr 17, 2013 at 10:28 AM, David Bruant <[hidden email]> wrote:

> I'm also going to ask a pretty violent question, but: does it still need to
> be spec'ed by ECMA? The only argument I've heard in favor of staying at ECMA
> is that some people still find ISO standardization and Word/PDF important.
> Can this be re-assessed? Especially given the recent promise/future mess?
> Other parts of the platform (thinking of DOM, DOM Events, XHR, forgetting
> about HTML5 specifically) have survived to the living standard model with
> success. The rumor on the street is that their latest editor draft of a lot
> of W3C is in HTML format; that would encourage a tighter feedback loop.
> Node.js is becoming more and more popular and I don't believe ECMAScript 5.1
> being an ISO standard is that important for the people interested in Node.js
> (probably even the business-focused ones).
>
> To a large extent the flexibility I'm asking for is already in place between
> TC39 and implementors (features are prototyped before being fully spec'ed).
> It just needs to be extended to another important consumer of the spec that
> is WebIDL.

Speaking as someone who's been doing W3C work for years, I find ISO
standardization a non-issue, and Word/PDF an anti-feature.  I can't
*stand* the ES draft as it's published today, and rely on the
unofficial HTML version for everything.

I strongly support any efforts to move JS standardization into the
umbrella of the W3C.  I also strongly support any efforts to move JS
standardization to a module-based affair, where parts can level
independently.  I think we've accumulated more than enough evidence
over the last decade that monolithic specs are not the right way to
develop standards for the web.  (The one counter-argument, HTML, is an
important exception to learn from, as it is a monolithic *document*
but a modular and independently-advancing *spec*.)

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Futures (was: Request for JSON-LD API review)

Kevin Smith
In reply to this post by Anne van Kesteren
HI Anne and Mark,

You both make good points:  Mark is correct when he suggests that a DOMFuture spec will effectively undercut TC39's role in designing a future/promise API.  It will also set a precedent (one that is perhaps already in motion) where TC39 is relegated to syntax-only enhancements and playing catch-up with platforms continually performing an end-run.

And Anne is certainly correct to point out that TC39 has not, as of yet, been able to provide the base-platform APIs that developer-facing platforms so badly need.

On the other hand, TC39 has done an *amazing* job with the ES6 language.  The usability improvements are striking and the module system will be exceptional.

It appears to me that what we are missing is a group sitting somewhere between TC39 and W3C, perhaps incorporating members of both.  This group would be responsible for designing the EcmaScript base platform API upon which developer-facing implementations can rely.  It would iterate more quickly than TC39, but unlike W3C its scope would include all EcmaScript-hosting platforms.  It would also share TC39's charge of maintaining the conceptual integrity of the language.

I nominate myself ; )

Ultimately, our goals are the same: a well-designed, conceptually consistent language and development platform.  We just need the right structure to make that happen.

Regarding futures specifically, for now I think any standardization discussions should be moved to es-discuss (or at least dual-homed there), as it is currently the only accepted public forum for platform-agnostic ES standards work.

{ Kevin }


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Futures (was: Request for JSON-LD API review)

Tab Atkins Jr.
On Wed, Apr 17, 2013 at 11:27 AM, Kevin Smith <[hidden email]> wrote:

> HI Anne and Mark,
>
> You both make good points:  Mark is correct when he suggests that a
> DOMFuture spec will effectively undercut TC39's role in designing a
> future/promise API.  It will also set a precedent (one that is perhaps
> already in motion) where TC39 is relegated to syntax-only enhancements and
> playing catch-up with platforms continually performing an end-run.
>
> And Anne is certainly correct to point out that TC39 has not, as of yet,
> been able to provide the base-platform APIs that developer-facing platforms
> so badly need.
>
> On the other hand, TC39 has done an *amazing* job with the ES6 language.
> The usability improvements are striking and the module system will be
> exceptional.
>
> It appears to me that what we are missing is a group sitting somewhere
> between TC39 and W3C, perhaps incorporating members of both.  This group
> would be responsible for designing the EcmaScript base platform API upon
> which developer-facing implementations can rely.  It would iterate more
> quickly than TC39, but unlike W3C its scope would include all
> EcmaScript-hosting platforms.  It would also share TC39's charge of
> maintaining the conceptual integrity of the language.
>
> I nominate myself ; )
>
> Ultimately, our goals are the same: a well-designed, conceptually consistent
> language and development platform.  We just need the right structure to make
> that happen.
>
> Regarding futures specifically, for now I think any standardization
> discussions should be moved to es-discuss (or at least dual-homed there), as
> it is currently the only accepted public forum for platform-agnostic ES
> standards work.

This group is public-script-coord, which we're already having the
discussion on, so... success!

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Futures (was: Request for JSON-LD API review)

Ron Buckton
In reply to this post by Anne van Kesteren
As someone who has been interested in Promises/Futures in JavaScript for a number of years, I'd like to throw in my $0.02 regarding a proposed API for Promises/Futures for thoughts:

https://gist.github.com/rbuckton/5406451

My apologies in advance as the API definitions are written using TypeScript and not Web IDL.

Ron

-----Original Message-----
From: Anne van Kesteren [mailto:[hidden email]]
Sent: Wednesday, April 17, 2013 8:46 AM
To: Mark S. Miller
Cc: [hidden email]; Norbert Lindenberg; Markus Lanthaler; Douglas Crockford; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API review)

> On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller <[hidden email]> wrote:
>> The main argument I've heard for proceeding with w3c/DOMFutures
>> rather than tc39/promises is that the DOM can't wait for tc39 to get
>> around to standardizing promises in ES7. But we should have our eyes
>> open to the consequences. As Crockford says (paraphrasing Knuth)
>> "Premature standardization is the root of all evil." The likely
>> result of DOMFuture proceeding in this way is that it will be wrong,
>> ES7 will be stuck with it and mostly unable to fix it, and we will
>> all be stuck with the consequences for a very very long time.
>>
>> As with Object.observe, if the need for promises is that urgent, it
>> needs to be on an accelerated track with the JavaScript context -- as
>> it already de facto is at promises/A+. It should not be needlessly
>> tied to the browser or to w3c.

I don't find the whole who owns what discussions very interesting to be honest. If it was up to me JavaScript would just be part of the W3C and we would not have to deal with that layer of distraction.

In any event, you can take the specification and improve on it elsewhere if you so desire. It is in the public domain for a reason.
You can also provide technical feedback as to what exactly is evil.
Saying "stop doing this" and implying you're somehow the superior forum to the other party is not helpful and has certainly not helped in the past.


--
http://annevankesteren.nl/

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))

Allen Wirfs-Brock
In reply to this post by David Bruant-5

On Apr 17, 2013, at 10:28 AM, David Bruant wrote:

...

Although promises were planned for ES7, they weren't part of any formal spec. As far as I know, no recent TC39 meetings even mentioned the concurrency strawman [2].

i don't think the "mention" observation is totally correct.  More generally, it is the actual TC39 participants who set the agenda for meetings and who build the necessary consensus to advance proposals.  That is how the ES7 observe proposal has advanced as rapidly as it has.  It is up to champions of specific proposal (such as Alex or Mark, in this case, but it could be others) to add appropriate agenda items and to move the process forward.

No formally accepted and agreed upon spec makes ES7 promises and the concurrency strawman virtually inexistent. The current largely informal agreement on the concurrency strawman doesn't solve the current problem of the web platform using promises/futures.

I believe the problem lies in that ECMAScript has a monolitic spec snapshot model. This model doesn't allow the flexibility needed by WebIDL and the web platform which are an important consumer of the spec. I believe this is why the WHATWG was chosen to host the Future spec work [4].

TC39 does not exclusively do monolithic specs. See for example Ecma-402, the ECMAScript initialization API [5] which is a modular addition to Ecma=262.  It is also a good example of domain experts working within the context of TC39 to focus attention on a specific feature area.

However, there is a very good reason that the ECMAScript Language specification is a monolithic spec.  Language design is different from library design. Programming language designs are notorious for the cross-cutting syntactic and semantic issues that arise when new langue level features are added. It would be irresponsible to try to introduce a new features without considering how it interacts with all other features of the language.  It also, isn't best practice to to only sequentially design in new features as this may lead to decision decisions that are hostile to other feature requests that are in the pipeline.

There is stuff in Ecma-262, particularly as ES6 emerges, that are basically library features and there has been casual conversations within TC39 about the desirability and practicality of of having separate standards for  some library components.  Ecma-402 is an example of this.  However, some care needs to be exercised here because sometimes library based features are actually cross-cutting language semantic extensions that are just masquerading as a library.  


Assuming this is the agree cause, would it make sense for the ECMAScript spec model to change to fit the flexibility needs of WebIDL and the web platform?
I'm also going to ask a pretty violent question, but: does it still need to be spec'ed by ECMA? The only argument I've heard in favor of staying at ECMA is that some people still find ISO standardization and Word/PDF important. Can this be re-assessed? Especially given the recent promise/future mess?

Language design is what it is, and to responsibly extend ECMAScript you need to have experienced language designers engaged. I think organizational venues and process has very little to do with the actual pragmatics of how you design extensions for a language as prominent as JavaScript. 

Other parts of the platform (thinking of DOM, DOM Events, XHR, forgetting about HTML5 specifically) have survived to the living standard model with success. The rumor on the street is that their latest editor draft of a lot of W3C is in HTML format; that would encourage a tighter feedback loop.
Node.js is becoming more and more popular and I don't believe ECMAScript 5.1 being an ISO standard is that important for the people interested in Node.js (probably even the business-focused ones).

To a large extent the flexibility I'm asking for is already in place between TC39 and implementors (features are prototyped before being fully spec'ed). It just needs to be extended to another important consumer of the spec that is WebIDL.

I would express this as, the web platform is the most important host environment for ECMAScript (that's how TC39 thinks of it). It is important that the architects of the web platform communicate their requirements, priorities, and timeframes to TC39 as the maintainers of ECMAScript and that TC39 is responsive to them. There really are no barriers to this, after all, many of us work for organizations that actively participate in both W3C and TC39 activities.

Regarding WebIDL, while it has improved it is still a terrible fit to ECMAScript  and attempts to extend the ECMAScript language semantics via WebIDL is a really bad idea as it circumvents the language design best practices mentioned above. WebIDL is not a good rallying point for better W3C/TC39 convergence.

Allen



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))

Allen Wirfs-Brock
In reply to this post by Tab Atkins Jr.

On Apr 17, 2013, at 10:48 AM, Tab Atkins Jr. wrote:

On Wed, Apr 17, 2013 at 10:28 AM, David Bruant <[hidden email]> wrote:
I'm also going to ask a pretty violent question, but: does it still need to
be spec'ed by ECMA? The only argument I've heard in favor of staying at ECMA
is that some people still find ISO standardization and Word/PDF important.
Can this be re-assessed? Especially given the recent promise/future mess?
Other parts of the platform (thinking of DOM, DOM Events, XHR, forgetting
about HTML5 specifically) have survived to the living standard model with
success. The rumor on the street is that their latest editor draft of a lot
of W3C is in HTML format; that would encourage a tighter feedback loop.
Node.js is becoming more and more popular and I don't believe ECMAScript 5.1
being an ISO standard is that important for the people interested in Node.js
(probably even the business-focused ones).

To a large extent the flexibility I'm asking for is already in place between
TC39 and implementors (features are prototyped before being fully spec'ed).
It just needs to be extended to another important consumer of the spec that
is WebIDL.

Speaking as someone who's been doing W3C work for years, I find ISO
standardization a non-issue, and Word/PDF an anti-feature.  I can't
*stand* the ES draft as it's published today, and rely on the
unofficial HTML version for everything.

Note that there is an official HTML version 


I strongly support any efforts to move JS standardization into the
umbrella of the W3C.  I also strongly support any efforts to move JS
standardization to a module-based affair, where parts can level
independently.  I think we've accumulated more than enough evidence
over the last decade that monolithic specs are not the right way to
develop standards for the web.  (The one counter-argument, HTML, is an
important exception to learn from, as it is a monolithic *document*
but a modular and independently-advancing *spec*.)

See my response to David's message. In many ways HTML is more like a langue design effort than a library design effort.  But regardless, I'm confident that wherever JS is standardized, the basic process of how you evolve a language of this importance will be much the same, and so will be the time frames.

Allen



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))

Tab Atkins Jr.
On Wed, Apr 17, 2013 at 12:06 PM, Allen Wirfs-Brock
<[hidden email]> wrote:
> Note that there is an official HTML version
> http://www.ecma-international.org/ecma-262/5.1/

Thanks!

This apparently has bad google-juice, and is not linked prominently in
the first couple results that I look at whenever I search for the ES
draft.  We can probably fix the latter, since most of those pages are
under close-by people's control.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part? (was: Re: Futures

David Bruant-5
In reply to this post by Allen Wirfs-Brock
Le 17/04/2013 21:03, Allen Wirfs-Brock a écrit :

> On Apr 17, 2013, at 10:28 AM, David Bruant wrote:
>> ...
>>
>> Although promises were planned for ES7, they weren't part of any
>> formal spec. As far as I know, no recent TC39 meetings even mentioned
>> the concurrency strawman [2].
>
> i don't think the "mention" observation is totally correct.  More
> generally, it is the actual TC39 participants who set the agenda for
> meetings and who build the necessary consensus to advance proposals.
>  That is how the ES7 observe proposal has advanced as rapidly as it
> has.  It is up to champions of specific proposal (such as Alex or
> Mark, in this case, but it could be others) to add appropriate agenda
> items and to move the process forward.
But that didn't happen. Instead, Alex Russel gathered a couple of
people, started with a minimal proposal privately then opened it up to
public feedback, then it entered the WHATWG DOM spec (people have mixed
feelings about that), this news has been so important it was shared to a
couple of W3C mailing lists I follow and there seems to be plan to
incorporate promises to other W3C specs.

Object.observe has moved quite fast, but still can't be consumed by
other specs as far as I can tell (there might also be an outreach issue
which is a different one)

>> No formally accepted and agreed upon spec makes ES7 promises and the
>> concurrency strawman virtually inexistent. The current largely
>> informal agreement on the concurrency strawman doesn't solve the
>> current problem of the web platform using promises/futures.
>>
>> I believe the problem lies in that ECMAScript has a monolitic spec
>> snapshot model. This model doesn't allow the flexibility needed by
>> WebIDL and the web platform which are an important consumer of the
>> spec. I believe this is why the WHATWG was chosen to host the Future
>> spec work [4].
>
> TC39 does not exclusively do monolithic specs. See for example
> Ecma-402, the ECMAScript initialization API [5] which is a modular
> addition to Ecma=262.  It is also a good example of domain experts
> working within the context of TC39 to focus attention on a specific
> feature area.
True. Can you provide a list of the next upcoming ECMA-xxx, please?

> However, there is a very good reason that the ECMAScript Language
> specification is a monolithic spec.  Language design is different from
> library design. (...)
The topic at hand is promises which is a library. I entirely agree with
the rest of what you said about language design. I'm perfectly fine with
the JS "virtual machine+syntax" being spec'ed as monolithic and agree it
should for the reasons you cited.

> There is stuff in Ecma-262, particularly as ES6 emerges, that are
> basically library features and there has been casual conversations
> within TC39 about the desirability and practicality of of having
> separate standards for  some library components.  Ecma-402 is an
> example of this.  However, some care needs to be exercised here
> because sometimes library based features are actually cross-cutting
> language semantic extensions that are just masquerading as a library.
I understand. Has the Future [1] proposal been reviewed with this needed
care? If not, can this be added to the agenda for the next meeting? (so
asks the non-TC39 guy :-p) It feels important.

>> Assuming this is the agree cause, would it make sense for the
>> ECMAScript spec model to change to fit the flexibility needs of
>> WebIDL and the web platform?
>> I'm also going to ask a pretty violent question, but: does it still
>> need to be spec'ed by ECMA? The only argument I've heard in favor of
>> staying at ECMA is that some people still find ISO standardization
>> and Word/PDF important. Can this be re-assessed? Especially given the
>> recent promise/future mess?
>
> Language design is what it is, and to responsibly extend ECMAScript
> you need to have experienced language designers engaged. I think
> organizational venues and process has very little to do with the
> actual pragmatics of how you design extensions for a language as
> prominent as JavaScript.
I'm glad we agree on this point :-)

David

[1] http://dom.spec.whatwg.org/#futures
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part? (was: Re: Futures

Allen Wirfs-Brock

On Apr 17, 2013, at 2:25 PM, David Bruant wrote:

Le 17/04/2013 21:03, Allen Wirfs-Brock a écrit :
On Apr 17, 2013, at 10:28 AM, David Bruant wrote:
...

Although promises were planned for ES7, they weren't part of any formal spec. As far as I know, no recent TC39 meetings even mentioned the concurrency strawman [2].

i don't think the "mention" observation is totally correct.  More generally, it is the actual TC39 participants who set the agenda for meetings and who build the necessary consensus to advance proposals.  That is how the ES7 observe proposal has advanced as rapidly as it has.  It is up to champions of specific proposal (such as Alex or Mark, in this case, but it could be others) to add appropriate agenda items and to move the process forward.
But that didn't happen. Instead, Alex Russel gathered a couple of people, started with a minimal proposal privately then opened it up to public feedback, then it entered the WHATWG DOM spec (people have mixed feelings about that), this news has been so important it was shared to a couple of W3C mailing lists I follow and there seems to be plan to incorporate promises to other W3C specs.

You have to ask Alex about that.  We all, as individual (subject to constraints our employers might impose), can create designs, circulate them, find supporters, promote their use, etc. But that is just personal action.   However, when a standards setting organization (SSO) agrees to undertake the development of a standard, that is a very different affair and formal rules start to apply.  For example, there may be rules on dependencies. Such as the rule that an Ecma (or ISO) standard is not allowed to normatively reference things that aren't also normative standards from a recognized SSO.   Differed organizations also have different chartered areas of responsibilities. One of the concerns I heard raised here is that  Futures may more appropriately fall into TC39 areas of responsibility.  Often when SSO find they have some overlap of interest they will find a way to jointly develop a standard.


Object.observe has moved quite fast, but still can't be consumed by other specs as far as I can tell (there might also be an outreach issue which is a different one)

Object.observe isn't part of a finished standard yet.  There is a fairly detailed proposal [2] (but not an official specification draft) that has been "accepted" by TC39 as the basis for a future standardized specification.  Some people are working on browser implementation based upon the proposal.  It is expect that the ultimate specification may vary somewhat from the proposal based upon feedback from those implementations.

Whether or not other specs chose to take dependencies upon Object.observe probably depends upon the rules they operate under plus their judgement of associated risks.

...

TC39 does not exclusively do monolithic specs. See for example Ecma-402, the ECMAScript initialization API [5] which is a modular addition to Ecma=262.  It is also a good example of domain experts working within the context of TC39 to focus attention on a specific feature area.
True. Can you provide a list of the next upcoming ECMA-xxx, please?

Work is already underway on the 2nd edition of Ecma-402, the Internationalization  APIs.

That (other than ES6) is the only formal standard in the current pipeline but there are other exploratory projects (see [3]) that are likely to either become part of the ES7 effort or a separate spec.  


However, there is a very good reason that the ECMAScript Language specification is a monolithic spec.  Language design is different from library design. (...)
The topic at hand is promises which is a library. I entirely agree with the rest of what you said about language design. I'm perfectly fine with the JS "virtual machine+syntax" being spec'ed as monolithic and agree it should for the reasons you cited.

Yes, but it is an library that extends  the sequential execution model of ES. That's a significant language level change to the ES specification.  We are already scrambling to a certain degree in the ES6 spec. to make it align with the browser-reality eventing model.

A a rule of thumb, if a library does something that can not be expressed in the its base language there is a good chance it is extending "the virtual machine" of the language and it should at least be reviewed from that perspective and iframe semantics.  These are both examples of browser design choices that have deep semantics impact upon the language.


There is stuff in Ecma-262, particularly as ES6 emerges, that are basically library features and there has been casual conversations within TC39 about the desirability and practicality of of having separate standards for  some library components.  Ecma-402 is an example of this.  However, some care needs to be exercised here because sometimes library based features are actually cross-cutting language semantic extensions that are just masquerading as a library.
I understand. Has the Future [1] proposal been reviewed with this needed care? If not, can this be added to the agenda for the next meeting? (so asks the non-TC39 guy :-p) It feels important.

no and see my first response above.  It can be as important as the TC39 members choose to make it. TC39's agenda is largely driven by feature champions.

...
...

 [2]  http://wiki.ecmascript.org/doku.php?id=harmony:observe 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part? (was: Re: Futures

Tab Atkins Jr.
On Wed, Apr 17, 2013 at 3:57 PM, Allen Wirfs-Brock
<[hidden email]> wrote:
> A a rule of thumb, if a library does something that can not be expressed in
> the its base language there is a good chance it is extending "the virtual
> machine" of the language and it should at least be reviewed from that
> perspective and iframe semantics.  These are both examples of browser design
> choices that have deep semantics impact upon the language.

Note that Futures are entirely expressible in today's JS semantics.

(Not to say that it shouldn't be reviewed by the language gurus here,
just saying.)

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part?

David Bruant-5
Le 18/04/2013 05:07, Tab Atkins Jr. a écrit :
> On Wed, Apr 17, 2013 at 3:57 PM, Allen Wirfs-Brock
> <[hidden email]> wrote:
>> A a rule of thumb, if a library does something that can not be expressed in
>> the its base language there is a good chance it is extending "the virtual
>> machine" of the language and it should at least be reviewed from that
>> perspective and iframe semantics.  These are both examples of browser design
>> choices that have deep semantics impact upon the language.
> Note that Futures are entirely expressible in today's JS semantics.
Allen was concerned about the "ECMAScript" definition of what you're
loosely calling "JS" while it seems you're referring to "web platform
enhanced JavaScript"
Specifically, the current semantics uses "queue a task" which interacts
with the event loop which is part of the web platform, but not ECMAScript.

I've read intention to move the event loop from HTML Living Standard to
ECMAScript 7, but we're not there yet and that work is necessary before
adding promises to ECMAScript.

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part? (was: Re: Futures

Anne van Kesteren
In reply to this post by Tab Atkins Jr.
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. <[hidden email]> wrote:
> Note that Futures are entirely expressible in today's JS semantics.
>
> (Not to say that it shouldn't be reviewed by the language gurus here,
> just saying.)

JavaScript does not have an event loop (as I mentioned elsewhere) so
that is not true. HTML defines the event loop model and processing
model for any asynchronous JavaScript execution. Lifting that up to
JavaScript seems difficult.


--
http://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the ECMAScript part?

David Bruant-5
Le 18/04/2013 09:40, Anne van Kesteren a écrit :
> On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. <[hidden email]> wrote:
>> Note that Futures are entirely expressible in today's JS semantics.
>>
>> (Not to say that it shouldn't be reviewed by the language gurus here,
>> just saying.)
> JavaScript does not have an event loop (as I mentioned elsewhere) so
> that is not true. HTML defines the event loop model and processing
> model for any asynchronous JavaScript execution. Lifting that up to
> JavaScript seems difficult.
What do you expect to be difficult? I foresee that it's going to be *a
lot* of work on both sides (W3C/WHATWG & TC39) to move this major piece
from one place to another without breaking anything. But I would say
it's a lot of "easy" work. It's going to take a lot of eyeballs and
probably tests to make sure what the new spec jonction between HTML LS
and ES7 conforms to what exists in reality (expecially in the new prose).
Is there a particular part of this work that you expect to be difficult.

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
1234 ... 8