Re: April 10 2014 Meeting Notes
In this case we have try-finally statements as an existing feature. The semantics of this feature is a bounded execution scope with a cleanup action on completion. This feature is widely used and has always been internally consistent and reliable, expect for catastrophic external failure or intervention (ie, externally imposed process termination, power failure, etc). People use it for all sorts of things, including bounded resource management. Zeroing in on cleanup action on completion: don't co-routines by nature prohibit us from reasoning in this way about completion? It seems to me that this shift is broader than just `try/finally`, although I agree that `try/finally` shows some particularly acute symptoms. And I also agree that we should not provide gratuitous footguns. Unfortunately, though, I'm having a hard time forming an opinion on how disallowing `try/yield/finally` would balance out. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
Kevin Smith wrote: In this case we have try-finally statements as an existing feature. The semantics of this feature is a bounded execution scope with a cleanup action on completion. This feature is widely used and has always been internally consistent and reliable, expect for catastrophic external failure or intervention (ie, externally imposed process termination, power failure, etc). People use it for all sorts of things, including bounded resource management. Zeroing in on cleanup action on completion: don't co-routines by nature prohibit us from reasoning in this way about completion? It seems to me that this shift is broader than just `try/finally`, although I agree that `try/finally` shows some particularly acute symptoms. And I also agree that we should not provide gratuitous footguns. Unfortunately, though, I'm having a hard time forming an opinion on how disallowing `try/yield/finally` would balance out. We're at risk of going around the design wheel again. Python started by banning yield in try: and then added it, with GeneratorExit as a magic exception thrown from Python's implicitly-called generator.close method at a yield-in-try that would run the finally clauses. When Igor Bukanov and I were working on ES4 and prototyping it in SpiderMonkey, Igor urged forcing a return instead of throwing a magic exception. He even persuaded Philip J. Eby on python-dev that forcing return was better, possibly even for Python (which IIRC then went in the direction of reifying control effects as exceptions). Instead of kicking the can and dragging this out yet again, I'm ok with return automation as proposed. Yeah, we're doing a common-ish use-case affordance. No, it isn't the last case where scoped resource release will come up. But yes, it has precedent in other languages and it's useful. BTW Dave Herman persuaded me we don't need to use a symbol for the name; 'return' is ok if 'next' is. The iteration protocol hooks via @@iterator, which returns an instance of something coded new implementations, so implementors can avoid using 'return' for a different purpose without conflict. IOW, one symbol-name is enough! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
+1, especially on the last point. As something added to iterators rather than iterables in ES6, there's no reason for return to be a symbol rather than a string. On Sat, Apr 26, 2014 at 9:59 AM, Brendan Eich bren...@mozilla.org wrote: Kevin Smith wrote: In this case we have try-finally statements as an existing feature. The semantics of this feature is a bounded execution scope with a cleanup action on completion. This feature is widely used and has always been internally consistent and reliable, expect for catastrophic external failure or intervention (ie, externally imposed process termination, power failure, etc). People use it for all sorts of things, including bounded resource management. Zeroing in on cleanup action on completion: don't co-routines by nature prohibit us from reasoning in this way about completion? It seems to me that this shift is broader than just `try/finally`, although I agree that `try/finally` shows some particularly acute symptoms. And I also agree that we should not provide gratuitous footguns. Unfortunately, though, I'm having a hard time forming an opinion on how disallowing `try/yield/finally` would balance out. We're at risk of going around the design wheel again. Python started by banning yield in try: and then added it, with GeneratorExit as a magic exception thrown from Python's implicitly-called generator.close method at a yield-in-try that would run the finally clauses. When Igor Bukanov and I were working on ES4 and prototyping it in SpiderMonkey, Igor urged forcing a return instead of throwing a magic exception. He even persuaded Philip J. Eby on python-dev that forcing return was better, possibly even for Python (which IIRC then went in the direction of reifying control effects as exceptions). Instead of kicking the can and dragging this out yet again, I'm ok with return automation as proposed. Yeah, we're doing a common-ish use-case affordance. No, it isn't the last case where scoped resource release will come up. But yes, it has precedent in other languages and it's useful. BTW Dave Herman persuaded me we don't need to use a symbol for the name; 'return' is ok if 'next' is. The iteration protocol hooks via @@iterator, which returns an instance of something coded new implementations, so implementors can avoid using 'return' for a different purpose without conflict. IOW, one symbol-name is enough! /be ___ 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
Re: April 10 2014 Meeting Notes
+1 from me as well. None of the proposed quick workarounds are truly safe, we might as well fix it properly. --scott ps. it seems like modules are still the long pole in the tent, so there's a little bit of time to spend on this? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
On Fri, Apr 25, 2014 at 8:48 AM, Rick Waldron waldron.r...@gmail.comwrote: On Fri, Apr 25, 2014 at 11:16 AM, Mark S. Miller erig...@google.comwrote: Hi Domenic, that's a long thread. Could you summarize, or point at a very small number of messages on that thread that get the point across? Thanks. Mark, This is the specific post we discussed at the last meeting: http://esdiscuss.org/topic/yield-desugaring#content-29 (It may not be the one Domenic is referring to, but it's relevant to this discussion) Ok, the point of that post still seems well summarized by the example at the end for_each_n(x = console.log(x), iter, 10); // first 10 for_each_n(x = console.log(x), iter, 10); // next 10 And the points In summary my problems with close() are these: 1. It attempts to provide a reliable finally for unlimited-extent activations, when we can't do that. 2. It complicates the mental model of what happens when you yield. 3. It makes common sugar like for-of inappropriate for some uses of generator objects. IIRC, on wednesday at tc39, when Brendan presented this, I found it compelling. On thurs (when Brendan was absent) when this came up again, I flipped because of the following argument: Given that for/of comes to be understood to use up its iterable's iterator, when the iterable is the iterator and you desire not to use it up, don't use for/of. Use for(;;) instead, which is easy enough and makes it more explicit what you are and are not doing in the iteration. Regarding the points: #1 yes, we cannot provide one that's reliable, so let's not claim that it is reliable. #2 yes it does. I acknowledge that this is a genuine cost. #3 for those rare cases where it is inappropriate, like this example, better not to use a for/of anyway to make the unusualness of this code's purpose more explicit. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
Mark S. Miller wrote: Regarding the points: #1 yes, we cannot provide one that's reliable, so let's not claim that it is reliable. Indeed it is not safe, even excluding yield, to assume finallys run in browser contexts, unless you can prove termination of trys (which is hard, right? Halting problem and all that). #2 yes it does. I acknowledge that this is a genuine cost. I think I can make your case stronger: without |return| one cannot be sure a generator iterator |it| parked at a yield won't resume some time later. To ensure that it is really done, call it.return(). Might this be important for reasoning about security? BTW, return() should be idempotent. Is it? #3 for those rare cases where it is inappropriate, like this example, better not to use a for/of anyway to make the unusualness of this code's purpose more explicit. Definitely -- given the implicit @@iterator call from (among other places) for-of constructs, it's best with for-of loops to avoid any reuse of the iterator later. Such hinky multi-loop consumption of a single iterator should be considered bad style. One can still do it, of course. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
On Sat, Apr 26, 2014 at 2:52 PM, Brendan Eich bren...@mozilla.org wrote: Mark S. Miller wrote: Regarding the points: #1 yes, we cannot provide one that's reliable, so let's not claim that it is reliable. Indeed it is not safe, even excluding yield, to assume finallys run in browser contexts, unless you can prove termination of trys (which is hard, right? Halting problem and all that). #2 yes it does. I acknowledge that this is a genuine cost. I think I can make your case stronger: without |return| one cannot be sure a generator iterator |it| parked at a yield won't resume some time later. To ensure that it is really done, call it.return(). Might this be important for reasoning about security? Plausible! BTW, return() should be idempotent. Is it? Since .return takes an argument whose value is observable, I think not. Hmmm. This is interestingly similar to multiple calls to resolve. #3 for those rare cases where it is inappropriate, like this example, better not to use a for/of anyway to make the unusualness of this code's purpose more explicit. Definitely -- given the implicit @@iterator call from (among other places) for-of constructs, it's best with for-of loops to avoid any reuse of the iterator later. Such hinky multi-loop consumption of a single iterator should be considered bad style. One can still do it, of course. /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Detecting a Module object
Has there been any further discussion on this? It would be good to know the
form so that ES6 modules currently being generated today will not break in
real ES6 environments.
On 21 February 2014 13:30, David Herman dher...@mozilla.com wrote:
OK, we can discuss and report back. We'll definitely want to take into
account Guy's use case about being able to recognize module instance
objects as such.
Dave
On Feb 21, 2014, at 12:53 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 21, 2014, at 12:08 PM, David Herman wrote:
I think it should be Module.isModule.
I don't think we actually need something named Module, but that's a
separate conversation I have in the queue to have with you.
But food for thought: for module loader reflection purposes, it would be
better for use a mirror-like object rather than the actual magic module
objects.
allen
Dave
On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
it's not going to be instanceof for various technical reasons.
I suspect, we can have a isModule predicate function somewhere.
Perhaps, Reflect.isModule or Reflect.Loader.isModule...
Allen
On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote:
Being able to do `m instanceof Module` is certainly a lot nicer here
though.
Just to return to the consideration of modules as classes, I still
don't understand what the major issue is with having a module as a class
without any prototype methods.
On 21 February 2014 00:07, Guy Bedford guybedf...@gmail.com wrote:
Thanks John for explaining. As for the usefulness of this path as I
say it is yet to be determined.
Specifically the ability to detect a module instance is needed to
allow ES6 loaders to load AMD that was transpiled from ES6 into AMD.
It may be a little bit of an obscure use case, the exact details of
the use case are described in this gist -
https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417.
The key point being raised here is that there is a scenario in which
detecting a module instance is useful.
On 20 February 2014 23:45, John Barton johnjbar...@google.com
wrote:
On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote:
Thanks, if there is some way to detect this it may well be useful.
The use case I came across it was trying to allow ES6 modules to be
transpiled into AMD for use in an ES6 loader. I'm still not sure how
necessary the use case is, but it definitely would need this functionality
work.
The Es6 module loader design has specific hooks to support importing
from foreign module systems. However, I'll leave it to Dave or Sam to
explain how to use them...
Guy is trying to support an important path for JS developers to get
to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD
modules. He already supports loading AMD via ES6-loader. Now he wants to
allow that AMD code to depend upon ES6 modules. This allows AMD teams to
transition smoothly to ES6. He needs something like:
define(['a', 'b'], function(a, b) {
if (!(a instanceof Module)) a = { default: a }
if (!(b instanceof Module)) b = { default: b }
so his generated AMD code can accept ES6 modules.
HTH,
jjb
___
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
