Re: Are ES Modules garbage collected? If so, do they re-execute on next import?

[Mark S. Miller]

Only a module registry as a whole may be GCed. During the lifetime of any
one module registry, it can only grow. No other solution is possible.

Btw, I remember being surprised ages ago when the same issue came up for
the Java ClassLoader. A classLoader holds on to all the classes it ever
loaded. Each class holds onto its classLoader. Each instance holds on to
its class. During the lifetime of a classLoader or any of its classes, the
graph of that classLoader and its classes can only grow new classes. Not
until the classLoader and all of its classes are unreachable at the same
time can any of them be collected. This was equally unfortunate,
surprising, and inescapable.



On Tue, Jul 14, 2020 at 10:16 PM #!/JoePea  wrote:

> How can we ensure that long-running applications (even if theoretical),
> that may load and unload an unlimited number of new modules over time
> (f.e. routes in a web page specified by 3rd parties as time
> progresses), not leak memory?
>
> Even if it is theoretical, I don't like the thought of something that
> only ever allocates memory that will never be freed.
>
> Is someone working on a solution for this?
>
>
> #!/JoePea
>
> On Wed, Jul 1, 2020 at 6:16 AM Mark S. Miller  wrote:
> >
> > No, definitely not. The table from specifiers to module instances is
> indexed by specifiers. Specifiers are strings, so this table is not weak.
> It is not a "cache" in the sense that it is allowed to drop things. Rather
> it is a registry of module instances. Only a registry as a whole can be
> gc'ed, and which point that context is no longer around for instantiating
> or reinstantiating modules.
> >
> > As you suggest, if it could drop things because of GC that it would then
> need to regenerate, that would expose the non-determinism of gc. That would
> be a big deal. We carefully designed WeakMaps so that gc was
> non-observable. WeakMaps introduce no observable non-determinism. WeakRefs
> alone expose the non-determinism of gc, and are kept well quarantined from
> the rest of the language.
> >
> >
> > On Tue, Jun 30, 2020 at 5:42 PM #!/JoePea  wrote:
> >>
> >> I am curious: can modules be garbage collected if the exports are not
> >> references by anything anymore? And if so, will the module be
> >> re-evaluated the next time it is imported?
> >>
> >> I haven't tried an experiment to answer this yet. I'll be back to post
> >> findings if someone doesn't post an official answer first.
> >>
> >> I'm thinking about code longevity. For example, if we make
> >> long-running web-based applications with many routes and features (for
> >> sake of example imagine a desktop environment, or a MMORPG game, with
> >> apps or components that are loaded within the same context). Over
> >> time, if imports are not collected, then it means we have a memory
> >> leak.
> >>
> >> Imagine, for example, an infinite-universe MMORPG where you can land
> >> on different planets where the code for features of a planet are
> >> provided by third parties as ES Modules. I know, this might not be a
> >> safe idea to import any code into an app, but just imagine it for sake
> >> of example (imagine we have a continuous integration system to test
> >> and verify code security, or something, before that code is allowed to
> >> be consumed in the app). Imagine you play this app for many many days,
> >> and visit many places, and you leave the app running the whole time
> >> (because farming for resources is disabled if the app is not running,
> >> or something).
> >>
> >> I would imagine that we want unused modules (when we leave a planet,
> >> for example) to be (destroyed) garbage collected so that we don't
> >> waste memory.
> >>
> >> #!/JoePea
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > --
> >   Cheers,
> >   --MarkM
>


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

Re: Are ES Modules garbage collected? If so, do they re-execute on next import?

[Mark S. Miller]

No, definitely not. The table from specifiers to module instances is
indexed by specifiers. Specifiers are strings, so this table is not weak.
It is not a "cache" in the sense that it is allowed to drop things. Rather
it is a registry of module instances. Only a registry as a whole can be
gc'ed, and which point that context is no longer around for instantiating
or reinstantiating modules.

As you suggest, if it could drop things because of GC that it would then
need to regenerate, that would expose the non-determinism of gc. That would
be a big deal. We carefully designed WeakMaps so that gc was
non-observable. WeakMaps introduce no observable non-determinism. WeakRefs
alone expose the non-determinism of gc, and are kept well quarantined from
the rest of the language.


On Tue, Jun 30, 2020 at 5:42 PM #!/JoePea  wrote:

> I am curious: can modules be garbage collected if the exports are not
> references by anything anymore? And if so, will the module be
> re-evaluated the next time it is imported?
>
> I haven't tried an experiment to answer this yet. I'll be back to post
> findings if someone doesn't post an official answer first.
>
> I'm thinking about code longevity. For example, if we make
> long-running web-based applications with many routes and features (for
> sake of example imagine a desktop environment, or a MMORPG game, with
> apps or components that are loaded within the same context). Over
> time, if imports are not collected, then it means we have a memory
> leak.
>
> Imagine, for example, an infinite-universe MMORPG where you can land
> on different planets where the code for features of a planet are
> provided by third parties as ES Modules. I know, this might not be a
> safe idea to import any code into an app, but just imagine it for sake
> of example (imagine we have a continuous integration system to test
> and verify code security, or something, before that code is allowed to
> be consumed in the app). Imagine you play this app for many many days,
> and visit many places, and you leave the app running the whole time
> (because farming for resources is disabled if the app is not running,
> or something).
>
> I would imagine that we want unused modules (when we leave a planet,
> for example) to be (destroyed) garbage collected so that we don't
> waste memory.
>
> #!/JoePea
> ___
> 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

Realms and Compartments

[Mark S. Miller]

At TC39, the EcmaScript standards committee, Caridy Patiño gave a great
talk on Realms https://docs.google.com/…/1umg2Kw18IlQyzrWwaQCAkeZ6xL…/edit…

.
I gave complementary talks on Virtualizability
https://github.com/…/…/02_talk_preserve-virtualizability.pdf

and
Compartments https://www.youtube.com/watch…

.
All received very well.

Enjoy! Comments appreciated. Thanks.

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

Re: syntax for case ranges

[Mark S. Miller]

While correct, each case asked the browser makers to make a risky and
costly bet. When the risk was low and the payoff high, they've been great
at doing so. This one does not fall into the viable risk vs reward
territory.


On Mon, Feb 3, 2020 at 7:58 AM kdex  wrote:

> Yes, there have been numerous backwards-incompatible changes to the
> language
> over the years.
>
> You can find a list of them in section E of the ECMAScript language
> standard.
> IIRC, that list is non-exhaustive.
>
> On Monday, February 3, 2020 6:35:12 PM CET Naveen Chawla wrote:
> > Thank you Claude! I did miss the point.
> >
> > Have there ever been "BC" breaks introduced into the language before? If
> > so, is there a sustainable standard for an "acceptable" one?
> >
> > On Mon, 3 Feb 2020 at 22:47, Claude Pache 
> wrote:
> > > Try typing `3 < 2 < 1` in the web console of your favourite browser,
> and
> > > see the result: it will evaluate to `true`. No, your browser isn’t
> buggy,
> > > it is just following blindly the semantics of `<`.
> > >
> > > Modifying the meaning of `3 < 2 < 1` in order to make it evaluating  to
> > > `false` is a BC break. Is it acceptable? Dunno.
> > >
> > > —Claude
> > >
> > > Le 3 févr. 2020 à 15:23, Naveen Chawla  a
> écrit :
> > >
> > > Hi!
> > >
> > > I didn't understand your reply.
> > >
> > > I think currently it would raise an error, because 1 < 2 < 3 is
> currently
> > > saying (probably) true < 3.
> > >
> > > But a "new" syntax could possibly parse that as a "chain" of
> comparisons.
> > >
> > > Would this be acceptable to introduce into JavaScript (just curious)?
> > >
> > > I've probably missed your point entirely, because I saw a short
> message "3
> > > < 2 < 1 //true", and I've assumed you meant it in reverse.
> > >
> > > On Sat, 1 Feb 2020 at 23:12, Mark S. Miller  wrote:
> > >> 3 < 2 < 1;  // true
> > >>
> > >>
> > >> On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla 
> > >>
> > >> wrote:
> > >>> Certain languages allow the expression 0 this
> > >>> would be syntactically possible in JavaScript? Of course this would
> only
> > >>> apply for "if"/"while" statements.
> > >>>
> > >>> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows <
> cont...@isiahmeadows.com>
> > >>>
> > >>> wrote:
> > >>>> Still better to discuss it there - it's highly related to your
> > >>>> suggestion. And I'm pretty sure an issue already exists related to
> > >>>> that.
> > >>>>
> > >>>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
> > >>>>> The pattern matching proposal does not handles the mentioned case:
> > >>>>>
> > >>>>> switch(type) { case 0...5: } being the equivalent of switch(type) {
> > >>>>> case 0: case 1: case 2: case 3: case 4: case 5: }
> > >>>>>
> > >>>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus <
> > >>>>>
> > >>>>> bruno.macab...@gmail.com> wrote:
> > >>>>>> I agree with Oriol.
> > >>>>>> We already have the proposal pattern matching, that has a very
> > >>>>>> similar effect.
> > >>>>>> I think that is better to improve pattern matching proposal in
> order
> > >>>>>> to be able to match using ranges (or at least check if it's good
> to
> > >>>>>> do)
> > >>>>>> instead of create a new proposal.
> > >>>>>>
> > >>>>>> On Fri, 31 Jan 2020 at 14:08, Oriol _  >
> > >>>>>>
> > >>>>>> wrote:
> > >>>>>>> This sounds like
> https://github.com/tc39/proposal-pattern-matching
> > >>>>>>>
> > >>>>>>> El 31/1/20 a les 10:57, Sultan ha escrit:
> > >>>>>>>
> > >>>>>>> For example, the following:
> > >>>>>>>
> > >>>>>>> switch (value) {
> > >>>>>>>
> > >>>>>>> case 0...9: break
> > >>>&g

Re: syntax for case ranges

[Mark S. Miller]

3 < 2 < 1;  // true


On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla  wrote:

> Certain languages allow the expression 0 would be syntactically possible in JavaScript? Of course this would only
> apply for "if"/"while" statements.
>
> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows 
> wrote:
>
>> Still better to discuss it there - it's highly related to your
>> suggestion. And I'm pretty sure an issue already exists related to that.
>>
>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
>>
>>> The pattern matching proposal does not handles the mentioned case:
>>>
>>> switch(type) { case 0...5: } being the equivalent of switch(type) { case
>>> 0: case 1: case 2: case 3: case 4: case 5: }
>>>
>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus 
>>> wrote:
>>>
 I agree with Oriol.
 We already have the proposal pattern matching, that has a very similar
 effect.
 I think that is better to improve pattern matching proposal in order to
 be able to match using ranges (or at least check if it's good to do)
 instead of create a new proposal.

 On Fri, 31 Jan 2020 at 14:08, Oriol _ 
 wrote:

> This sounds like https://github.com/tc39/proposal-pattern-matching
>
> El 31/1/20 a les 10:57, Sultan ha escrit:
>
> For example, the following:
>
> switch (value) {
> case 0...9: break
> case 'a'...'z': break
> }
>
>
> ___
> es-discuss mailing 
> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> 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

>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> --
>> -
>>
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>> ___
>> 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
>


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

Re: Proposal: strict built-in functions

[Mark S. Miller]

Thanks Claude, I agree. I have added it to the agenda as well.
https://github.com/tc39/agendas/blob/master/2020/02.md



On Mon, Dec 9, 2019 at 12:45 AM Claude Pache  wrote:

>
>
> Le 8 déc. 2019 à 15:39, Mark S. Miller  a écrit :
>
> Wow, Edge is definitely in violation of the intent of the spec, and the
> intent of the history of treatments of .caller in previous discussions and
> specs over the years. The Edge behavior is grossly unsafe.
>
> Hi Jack, thanks for catching this and raising it!! It does need to be
> fixed. I do think it can be a PR because the historical intent was clear.
> Since the FF behavior is correct, the correct behavior is web compat, so we
> should be able to handle this in a PR.
>
> Whether a PR or a full proposal, in either case I'm happy to take this to
> the committee. I invested years of my life killing non-sloppy
> function.caller. I can spend a little more ;)
>
>
> Hi Mark,
>
> I think it is time to revive https://github.com/tc39/ecma262/issues/562 and
> its associated repo
> https://github.com/claudepache/es-legacy-function-reflection.
>
> —Claude
>
>
>

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

Re: Proposal: strict built-in functions

[Mark S. Miller]

Wow, Edge is definitely in violation of the intent of the spec, and the
intent of the history of treatments of .caller in previous discussions and
specs over the years. The Edge behavior is grossly unsafe.

Hi Jack, thanks for catching this and raising it!! It does need to be
fixed. I do think it can be a PR because the historical intent was clear.
Since the FF behavior is correct, the correct behavior is web compat, so we
should be able to handle this in a PR.

Whether a PR or a full proposal, in either case I'm happy to take this to
the committee. I invested years of my life killing non-sloppy
function.caller. I can spend a little more ;)




On Sun, Dec 8, 2019 at 5:52 AM Jack Works  wrote:

> It is a runtime level change. I think it might break some code that
> depends on the strictness of the built-in function like code that using
> func.caller.
>
> On Sun, Dec 8, 2019, 9:48 PM Isiah Meadows 
> wrote:
>
>> You might do better to file a pull request directly against the spec for
>> this: https://github.com/tc39/ecma262. To me, it looks more like an
>> oversight, not something that would likely have to go through all 4 stages.
>> (If it does, at least you already have a repo for it.)
>>
>> On Sun, Dec 8, 2019 at 08:43 Jack Works  wrote:
>>
>>> In the current spec, strictness of the built-in functions are
>>> implementation-dependent behaviors. This proposal is going to fix this
>>> problem.
>>> https://github.com/Jack-Works/proposal-strict-built-in-functions
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> --
>> -
>>
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>>
> ___
> 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

Meetup: "Making Javascript Safe and Secure" Thursday 5 Dec, 6pm San Francisco

[Mark S. Miller]

https://www.eventbrite.com/e/making-javascript-safe-and-secure-tickets-81435250025

On Thursday evening after the tc39 meeting, Agoric, Moddable, and MetaMask
are organizing a meetup on

*Making Javascript Safe and Secure*
https://www.eventbrite.com/e/making-javascript-safe-and-secure-tickets-81435250025


Talks at least by Agoric, Moddable, and MetaMask. This is a good
opportunity for developers and TC39 members interested in Javascript
security to meet each other.

Hope to see you there!
-- 
  Cheers,
  --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observable GC

[Mark S. Miller]

On Fri, Oct 20, 2017 at 10:52 AM, Filip Pizlo  wrote:

>
>
> On Oct 20, 2017, at 10:29 AM, Mark Miller  wrote:
>
> There is a glaring inconsistency in the criteria we use to evaluate these
> issues. While we are understandably reluctant to admit more non-determinism
> into the platform via weakrefs, we have admitted an astonishingly greater
> degree of non-determinism into the platform via "Shared Array Buffers"
> (SAB), i.e., shared memory multithreading with data races.
>
> The scenario we legitimately fear for weakrefs: A developer writes code
> that is not correct according to the weakref specification but happens to
> work on present implementations. Perhaps it relies on something being
> collected that is not guaranteed to be collected.
>
>
> Being collected when it shouldn’t have been?  Like a dangling reference.
> The game theory of security exploits forces implementations to keep things
> alive longer, not shorter.
>

Not what I meant. Being collected when it should not be would clearly
violate the spec. Rather, the weakref spec never guarantees that anything
is collected. Any program whose correct behavior ever relies on anything
being observably collected is an incorrect program. When run on a different
correct implementation --- one on which those objects never get observably
collected --- it will misbehave.




>
> Perhaps it relies on something not being collected that is not guaranteed
> not to be collected. A later correct change to an implementation, or
> another correct implementation, causes that code to break. The game theory
> punishes the correct implementation rather than the incorrect code.
>
>
> Java had weak refs and multiple different implementations.  My claim, as
> someone who implemented lots of weird GC algorithms in Java, is that I
> don’t know of a case where different weak ref semantics breaks something.
> The only time that getting it wrong ever had an observably bad effect is
> when you break weak refs or finalizers so badly that they never get cleared
> or called, and then some resource has an unbounded leak.  This usually
> results in not being able to run any benchmarks that have weak references
> or finalizers, so you fix those bugs pretty quickly.
>
> Here are the motivations:
> - Competitive perf motivates GC authors to try to free things as soon as
> possible.  Smaller heaps mean more speed.  Some benchmarks won’t run to
> completion if you aren’t aggressive enough.
>

This causes only a tendency to collect more as a quality-of-implementation
issue. And even for that, it is at best a statistical issue. There is never
a guarantee that anything in particular will get collected.

- The need to avoid dangling references forces us to keep alive at least
> what we need to, and sometimes a bit more.
>

"Need to" in the sense of strongly referenced, absolutely. Any
implementation that fails to do so seriously violates the spec and more.
There is no controversy on this point.

The concern is "need to" in the sense that a given program points at
something only weakly at t1, fetches is at t2 and finds it still there and
comes to count on that behavior. A different correct implementation might
cause this same program to find that the object has been collected before
t2, causing this buggy program to break.


>
> I guess a program could rely on the weak references actually being strong
> in some implementation.  I haven’t heard of Java programs ever doing that.
> It’s unlikely to happen because the major implementations will try to clear
> weak refs as aggressively as they can to compete on benchmarks.
>
> Perhaps part of the problem here is that we’re assuming that GC is already
> not observable.  It’s totally observable.  We have to fix bugs sometimes
> because the GC didn’t free something it should have, and the memory
> footprint of an app balloons so much that it crashes.  Also, people obsess
> over GC perf and GC pauses exactly because they observe them.  Considering
> all of the existing ways that GCs are observable, I don’t think that weak
> refs change the game.
>

I can only see this argument becoming solid if we were willing to consider
obligating the platform to do accurate gc, rather than conservative gc. 1)
no one is willing to advocate that, including me. 2) Even if we were, the
timing would still cause all the same issues.


> I think there are features of the web platform that are significantly more
> likely to create incompatibilities than this issue, and you seem to agree:
>
>
> The parallel scenario for data races is clear. And on some measures, the
> magnitude of the problem is orders of magnitude larger for SAB because of
> * the fine granularity of non-deterministic interleaving (especially if
> observable gc interleaving happens only at turn boundaries),
> * the greater difficultly of reasoning about memory models vs observable
> gc (again, especially if observable gc interleaving happens only at turn
> boundaries).

Re: Proxy performance: JIT-compilation?

[Mark S. Miller]

On Fri, Aug 4, 2017 at 2:52 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>
wrote:

>
> On Aug 4, 2017, at 2:22 PM, Mark S. Miller <erig...@google.com> wrote:
>
> At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have an idea
> (that we should turn into a proposal) for a subtle change to proxy
> semantics that
> * should break essentially no current code,
> * repair the cycle detection transparency violation bug,
> * enable many proxies to be *much* faster.
>
>
> I actually don’t see why any semantic changes are needed to enable better
> Proxy performance. One abstractions are sufficiently lowered, a proxy trap
> invocation is just a series  of procedure calls (some dynamically
> dispatched; some to built-in procedures).  I don’t see any reason why the
> same sort of PIC+dynamic typed based specialization+inlining that is used
> to optimize more conventional JS code isn’t also applicable to Proxy using
> code.
>
> I don’t think the barriers to such optimization are technical.  It’s more
> a matter of convincing that engine implementors that doing the work
> (probably significant)  to optimizing Proxies in this manner is a sound
> investment and hight priority
>

I agree. So I change the claims to

* should break essentially no current code,
* repair the cycle detection transparency violation bug,
* enable many proxies to be *much* faster with less work by
implementors.

In particular, for many permanently absent traps, the proxy can just pass
these through directly to the target without much analysis.

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

Re: Intercepting sets on array-like objects

[Mark S. Miller]

Interesting. At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have
been discussing a way to make Proxies cheaper, and Proxies that only
override a few traps and let the rest default, much cheaper.



On Thu, Jun 8, 2017 at 11:32 AM, Tab Atkins Jr. 
wrote:

> Heya!  As part of designing the CSS Typed OM
> , we've ended up with at
> three (so far) places where we want an interface that represents a
> list of values:
>
> * CSSUnparsedValue
> ,
> representing alternating unparsed strings and variable references in a
> property
> * CSSNumericArray
> ,
> representing the n-ary arguments of sum/product/min/max operations
> * CSSTransformValue
> ,
> representing a list of transform functions
>
> The most natural way to represent these is as an Array, so authors can
> get all the Array methods, use `val[i]` syntax, etc.  However, doing
> so means we lose the ability to type-check sets to the values.
>
> In general, type-checking is an important part of APIs defined in
> WebIDL.  Any set to a property on an object is automatically
> type-checked, any arguments to methods are automatically type-checked,
> etc.  By building this into WebIDL, it removes the need for a lot of
> annoying boilerplate on the part of spec authors, and more
> importantly, removes the possibility that spec authors will forget to
> typecheck at all, or will typecheck in incorrect or weird bespoke
> ways.  Every API responds in exactly the same way when you pass the
> wrong type of object, and that's a Good Thing for both users and
> implementors.
>
> And so, it would be great to have the same ability to typecheck these
> Array-likes in the Typed OM.
>
> Naively, this requires a Proxy, so we can intercept uses of the []
> syntax.  However, we don't need all the rest of the Proxy
> functionality, just this one intercept - a setter function, just for
> `obj[foo]` rather than `obj.foo`.  Further, Typed Arrays already have
> *precisely* the functionality I'd like to use - they intercept setting
> using [], and convert it into the appropriate type of number.  AWB
> also proposed adding exactly this hook in the past (I think it was
> called "Array reformation" or something?).
>
> Thoughts?
>
> Note that if we don't get some variant of this functionality, these
> APIs will instead do one of:
>
> * just using Proxies (already defined in WebIDL)
> * using .get()/.set() functions with integer arguments to badly emulate
> arrays
> * just relying on iterator/constructor, so users have to convert the
> object to an Array, fiddle with it, then construct a brand new object
>
> And whichever I end up with, I'll be advocating that as the Standard
> WebIDL Way to do array-likes, so we can finally have some consistency.
>
> ~TJ
> ___
> 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: Unicode non-character being treat as space on Firefox/Chrome

[Mark S. Miller]

Allen, I'm very glad to hear that it is unambiguous after all.

Gareth, could you file bugs against the non-conforming browsers? Thanks for
finding this!



On Thu, May 25, 2017 at 8:58 AM, Allen Wirfs-Brock 
wrote:

> clause 10.1:
>
> ECMAScript code is expressed using Unicode. ECMAScript source text is a
> sequence of code points. All Unicode code point values from U+ to
> U+10, including surrogate code points, may occur in source text where
> permitted by the ECMAScript grammars.
>
>
> https://tc39.github.io/ecma262/#sec-white-space exactly defines which
> specific code units are treated as Whitespae by the ECMAScript grammar. It
> does not include unassigned code points in the set of valid Whitespace
>
> Allen
>
>
>


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

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

[Mark S. Miller]

Take a look at Tom's explanation of the "shadow target" technique at
https://research.google.com/pubs/pub40736.html
section 4.3



On Tue, May 23, 2017 at 8:45 AM, Jason Orendorff 
wrote:

> On Tue, May 23, 2017 at 2:44 AM, Alex Vincent  wrote:
>
>> Full details are at https://github.com/ajvincent/es7-membrane/issues/79
>> , which is where I'm hoping to find a solution.
>>
>
> To fix this, you must create a third object for each dry proxy, to serve
> as its [[ProxyTarget]]. There's no way around it. And you're right, it's
> not easy; you have to implement all of the handler methods, because none of
> the defaults do the right thing anymore.
>
> All the target checks in the design were intended to (a) allow proxies to
> claim to have immutable parts; and yet (b) maintain the language's
> invariants that immutable parts cannot change, even for proxies.
> [[ProxyTarget]] looks like an ease-of-use feature, but it's not; it's
> really in support of (a) and (b), and as you've found, it actually makes
> some things harder.
>
> -j
>
>
> ___
> 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: Re: Strict (non-coercing) expressions

[Mark S. Miller]

On Thu, Apr 13, 2017 at 11:08 AM, Bruno Jouhier  wrote:

> I like the idea of a block level annotation. Lighter and more practical
> than a new set of operators. Module level would be nice too. OTOH
> expression level feels a bit like overkill.
>
> Why not turn this into a more general _pragma_ syntax then?


We already have a pragma syntax. So how about

"use coercions, not!";

Just kidding about the actual text, but this "use x"; pragma pattern was
meant to be usable for more than just "use strict";. This pragma syntax was
designed to be ignored on versions of the language that do not yet
recognize the pragma. Such version compat seems appropriate for the issue
we're discussing.



> This would allow us to control other special conditions: throw on
> overflow, on divide by zero, etc.
>
>
>
> ___
> 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: Strict Relational Operators

[Mark S. Miller]

Hi T.J.,

I do not recall such a discussion. Please do start one! Thanks.


On Mon, Apr 10, 2017 at 2:47 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> I'm sure there must have been discussions of adding strict relational
> operators (e.g., non-coercing ones, the `===` versions of `<`, `>`, `<=`,
> and `>=`), but I'm not having a lot of luck finding those discussions.
> Searching "strict relational site:https://mail.mozilla.org/
> pipermail/es-discuss/" and on esdiscuss.org doesn't turn up anything
> relevant.
>
> Does anyone have a link handy? I'm not trying to start a new discussion,
> just keen to read what's already been discussed.
>
> Thanks,
>
> -- T.J. Crowder
>
> ___
> 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: Proxies fail comparison operator

[Mark S. Miller]

The Left Hand of Equals
https://research.google.com/pubs/pub45576.html
is relevant to this discussion. The advice in this paper should be
considered new languages that are not yet committed to an equality
semantics. Frankly I have mixed feelings about it, but it is fascinating.

OTOH, for JavaScript, === must not trap.

Enjoy.



On Mon, Apr 3, 2017 at 2:07 AM, Michał Wadas  wrote:

> Proxies being able to intercept strict equality would be nightmare -
> WeakMap and WeakSet would need new semantics, potentially incompatible with
> previous one. Engines won't be able to optimize certain boolean expressions
> because of potential side effects.
>
> The only thing I can think of is not-a-trap:
>
> const foo = {};
> const bar = new Proxy({}, {
> equals: foo
> });
> bar === foo; // true
> bar === {}; // false
>
> But even that can lead to many problems with design (how about new
> Proxy({}, {equals: bar})
>
>
> On 31/03/17 16:21, Michael Lewis wrote:
>
> Proxies do not reflect internal slots (Oriol)
>
>
>  You really don't *want* proxies to equal their underlying objects:
>> proxies can show properties that the underlying object doesn't have, hide
>> properties that the underlying object does have, alter the appearance of
>> other proxies, etc.  (Alex Vincent)
>
>
> What you really want to ask for is for JavaScript support for overriding
>> the comparison operator for a class. (and other operators, too...)
>>  (Michael Kriegel)
>
>
>
> Sounds like the purpose of Proxies evades me and unfortunately, I don't
> have time to read up on it, but thanks for the link, Allen.  Any article
> that begins with the word *abstract* scares me.
>
> Yes, Michael, I think *operator traps* for the proxies would be a perfect
> solution.  Then I could let my proxies === my targets, woohoo!
>
> Thanks everyone, great feedback.
>
>
>
>
> On Fri, Mar 31, 2017 at 5:06 AM, Michael Kriegel <
> michael.krie...@actifsource.com> wrote:
>
>> I agree with everyone, that the proxy object should not equal the proxied
>> object.
>>
>> What you really want to ask for is for JavaScript support for overriding
>> the comparison operator for a class. (and other operators, too...)
>>
>> On 30.03.2017 21:44, Michael Lewis wrote:
>>
>> I don't believe Proxies are designed to give you any encapsulation to a
>>> user who also has a reference to the target object
>>>
>>
>> So the Proxy wasn't designed to proxy real objects that operate with real
>> code?
>>
>> `myRealFunction(obj)` <---> `myRealFunction(proxy)`
>>
>> This could be incredibly useful.  You could log every get/set/method call
>> on the obj.  And, this *will* work in 99% of use cases.  Just cross your
>> fingers that your code doesn't use the comparison operator.
>>
>> you'd have to never provide the reference to the target object in the
>>> first place.
>>
>>
>> Yea, that's what I'm doing.  But inside a constructor, you basically have
>> to create the proxy first thing, call all initialization logic on the proxy
>> instead of `this`, and return the proxy.  And when you're only proxying if
>> `log: true` has been set, you have to maybe proxy, but maybe not.  I can
>> work around it, but I'm not happy about it ;)
>>
>> ljharb ftw!  (I am delevoper on IRC, the one frequently ranting about the
>> software revolution)
>>
>> On Thu, Mar 30, 2017 at 1:53 PM, Jordan Harband  wrote:
>>
>>> I don't believe Proxies are designed to give you any encapsulation to a
>>> user who also has a reference to the target object - you'd have to never
>>> provide the reference to the target object in the first place.
>>>
>>> On Thu, Mar 30, 2017 at 11:50 AM, Michael Lewis  wrote:
>>>
 Hello community,

 The proxy is almost an identical to the underlying object, but it* fails
 a comparison check with the underlying object.*

 This means that if anyone gets a reference to the underlying object
 before it is proxied, then we have a problem.  For example:

 var obj = {};
 var proxy = new Proxy(obj, {});
 obj == proxy; // false

 *Isn't the purpose of the proxy to be exchanged with the original**,
 without any negative side effects?  *Maybe that's not the intended use
 case, but it's a useful one.  And, besides the comparison, I can't think of
 any other "negative side effects".

 It seems like the Proxy could have a *comparison trap*.  The
 comparison could pass by default, and you could use the trap if you wanted
 to make `proxy == obj` fail.

 Also, a slight tangent: it would be awesome if you could *skip
 debugging proxy traps when stepping through code.  *When you proxy
 both `get` and `apply` for all objects/methods, you have 10x the work when
 trying to step through your code.

 I just subscribed to this list.  Is this an appropriate venue for this
 type of inquiry?  I appreciate any feedback.



 Thanks!

 Michael

Re: A WeakMap where values (not keys) are weak references?

[Mark S. Miller]

What you are asking for is sometimes called a "WeakValueMap". It is a very
sensible abstraction and sometimes exactly what is needed. It is easy to
build using Maps (or WeakMaps, depending) combined with <
https://github.com/tc39/proposal-weakrefs>.

The old wiki.ecmascript.org shows an implementation of a WeakValueMap in
terms of these. Unfortunately the wiki still seems to be offline.

Since there are still outstanding links into it, how did the wiki get
collected? Were these links weak? ;)






On Tue, Mar 21, 2017 at 7:20 AM, Boris Zbarsky  wrote:

> On 3/21/17 2:15 AM, /#!/JoePea wrote:
>
>> I'd like to have something like a WeakMap where the keys can be
>> primitives and the values are weakly-held Objects
>>
>
> It might be worth searching the archives: this has been proposed multiple
> times and discussed at quite some length.
>
> If there isn't an existing document that summarizes the discussions (and
> quick searching doesn't find one in the top several hits, though it does
> find https://esdiscuss.org/topic/what-is-the-status-of-weak-references at
> the very least), there really should be one...
>
> -Boris
>
> ___
> 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: How about awaiting Arrays ?

[Mark S. Miller]

On Fri, Mar 3, 2017 at 12:27 PM, Mark S. Miller <erig...@google.com> wrote:

>
>
> On Fri, Mar 3, 2017 at 8:51 AM, Michał Wadas <michalwa...@gmail.com>
> wrote:
>
>> Actually I would go with
>>
>> await ...expr;
>>
>
> I have not liked any of the prior suggestions on this thread. But this one
> is interesting. It has no compatibility problems, it composes nicely, and
> it suggests its meaning clearly.
>

I should have read ahead. await.all and await.race also have these virtues,
and there's no generalization of await ...expr that naturally expresses
race.



>
>
>
>>
>> As sugar for:
>>
>> await Promise.all(Array.from(expr))
>>
>>
>> On 3 Mar 2017 17:15, "T.J. Crowder" <tj.crow...@farsightsoftware.com>
>> wrote:
>>
>> On Fri, Mar 3, 2017 at 3:28 PM, Matthew Robb <matthewwr...@gmail.com>
>> wrote:
>> >
>> > I think this conversation needs to happen but I am not sure baking
>> > it into Array facilities makes the most sense.
>> >
>> > In my experience with async/await I am very often needing Promise.all
>> but
>> > in some cases the other forms of multi promise capabilities. What if we
>> > expanded the keyword `await.all [...]; await.race [...]`
>>
>> Heh, I was thinking of that too, as an alternative to the `awaitall`
>> and such I suggested to Andrea so we didn't need to add Yet More
>> Keywords. :-)
>>
>> ```js
>> await.all iterable;
>> ```
>>
>> instead of
>>
>> ```js
>> await Promise.all(iterable);
>> ```
>>
>> ? That seems pretty clear to me, and doesn't seem like a big
>> specification or implementation burden (he said, talking through his
>> hat).
>>
>> -- T.J.
>> ___
>> 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
>>
>>
>
>
> --
> Cheers,
> --MarkM
>



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

Re: How about awaiting Arrays ?

[Mark S. Miller]

On Fri, Mar 3, 2017 at 8:51 AM, Michał Wadas  wrote:

> Actually I would go with
>
> await ...expr;
>

I have not liked any of the prior suggestions on this thread. But this one
is interesting. It has no compatibility problems, it composes nicely, and
it suggests its meaning clearly.




>
> As sugar for:
>
> await Promise.all(Array.from(expr))
>
>
> On 3 Mar 2017 17:15, "T.J. Crowder" 
> wrote:
>
> On Fri, Mar 3, 2017 at 3:28 PM, Matthew Robb 
> wrote:
> >
> > I think this conversation needs to happen but I am not sure baking
> > it into Array facilities makes the most sense.
> >
> > In my experience with async/await I am very often needing Promise.all but
> > in some cases the other forms of multi promise capabilities. What if we
> > expanded the keyword `await.all [...]; await.race [...]`
>
> Heh, I was thinking of that too, as an alternative to the `awaitall`
> and such I suggested to Andrea so we didn't need to add Yet More
> Keywords. :-)
>
> ```js
> await.all iterable;
> ```
>
> instead of
>
> ```js
> await Promise.all(iterable);
> ```
>
> ? That seems pretty clear to me, and doesn't seem like a big
> specification or implementation burden (he said, talking through his
> hat).
>
> -- T.J.
> ___
> 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
>
>


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

Re: getOwnPropertyDescriptor side effects

[Mark S. Miller]

On Thu, Jan 19, 2017 at 9:30 AM, Boris Zbarsky  wrote:

> On 1/19/17 12:24 PM, Isiah Meadows wrote:
>
>> 1. What does Firefox do with the getter on non-errors?
>>
>
> Oh, I didn't make that clear, did I?  On a non-error in the getter, we
> have an Error object or Error.prototype (which appeared somewhere on our
> receiver's proto chain).  Those objects all have, in Spidermonkey, an
> internal slot that stores information about the stack.  The getter uses the
> information in that internal slot to create a string and return it.
>
> 2. How breaking is having the getter and setter throwing on non-errors?
>>
>
> Well, when we tried to do it it didn't even pass our test automation, so...
>
> In particular it would throw on anyone doing ES5-style subclassing of
> Error and then doing anything with .stack.


That makes perfect sense.

We could have the Error.prototype.getter not throw but have System.getStack
throw. There was no strong reason for the getter and System.getStack to
have precisely the same behavior; it was just that there was no reason not
to. Now there is. Thanks.




>
>
> I'm struggling to see how it'd be that breaking. It's a getter, not a
>> method, so it requires a call to `__locateGetter__` or
>> `Object.defineProperty` to even access.
>>
>
> No, it just requires that you have an Error on your prototype chain but
> not be an Error yourself, and suddenly you have exceptions everywhere.
>
>
> -Boris
> ___
> 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: Proposal: Symbol.templateTag

[Mark S. Miller]

Hi Alexander, I have run into this myself. It is a real problem, and I like
the nature of your proposed solution. But I don't understand how it might
break the web. If Symbol.templateTag is a new symbol, guaranteed unequal to
any prior value, how can introducing it, and new behavior conditional on
it, change any existing behavior?




On Wed, Nov 16, 2016 at 5:02 PM, Alexander Jones  wrote:

> Hi es-discuss!
>
> Template tags are a great feature with many novel applications, IMO
> approaching macro-level expressiveness. But due to their nature in this
> context, it's helpful if tags are named quite tersely. Unfortunately, if
> you have existing API, this can be challenging.
>
> Let's say I have a DSL (domain-specific language), and I *may*, unsafely,
> generate typed snippets of code containing that DSL like so:
>
> ```js
> function dsl(code: string) {
> // `code` MUST be well-formed
> }
>
> const someStatement = dsl("val foo = " + dslEncode(foo));
> ```
>
> Let's say I'd like to add support in my library for ES6 clients such that
> they can do:
>
> ```js
> const someStatement = dsl`val foo = ${foo}`;
> ```
>
> where the `dsl` template tag would be implemented such that `dslEncode` is
> used on each interpolated expression.
>
> Unfortunately, the `dsl` function's arguments are already defined and
> can't be changed. I'd need a new name, like `dsl.tag`, which would end up
> being a fair bit more verbose.
>
> Would it be possible, at this point, to introduce a new behaviour into ES
> such that instead of merely calling the tag object, the implementation
> first checks for a `Symbol.templateTag` property on the tag object, and if
> it exists, it is invoked? I'd guess this can't Break The Web because no-one
> can realistically be using an existing function as a template tag if it was
> not already designed for it.
>
> ```js
> const someStatement = dsl`val foo = ${foo}`;
> // desugars to, approximately
> const someStatement = (dsl[Symbol.templateTag] || dsl)(["val foo =", ""],
> foo);
> ```
>
> To be honest, I am kind of surprised it wasn't already implemented like
> this, but maybe there were performance concerns with the branching.
> Interested in your thoughts.
>
> Thanks
>
> Alex
>
> ___
> 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: JSON.stringify

[Mark S. Miller]

On Thu, Sep 29, 2016 at 9:25 AM, Alexander Jones  wrote:

> Maybe we should just make U+2028 and U+2029 valid in JS then? What other
> productions in JSON are invalid syntax in JS?


IIRC, Doug Crockford, possibly Mike Samuel, and I (and perhaps others)
advocated such a change to EcmaScript back during the transition from ES3
to ES3.1/ES5. ES differed enough between platforms in other ways that, some
of us felt, it would have been worth the experiment to see if we could get
away with it -- without breaking the web. We were not able to convince
people to engage in that experiment then. Such an experiment would be much
more expensive now, with a much lower probability of success, and with a
lower payoff. I don't see it happening.



>
> On Thursday, 29 September 2016, Mike Samuel  wrote:
>
>> On Thu, Sep 29, 2016 at 8:45 AM, Oriol Bugzilla
>>  wrote:
>> >> ECMAScript, while highly used in web browsers, should really not care
>> >> about HTML constructs. That's where WHATWG and W3C come in. I suggest
>> this
>> >> type of feature should come from one of those groups, not ECMA.
>> >
>> > That applies to escaping things like `` or `]]>`, and I agree.
>> But
>> > as Mike Samuel mentioned, JSON strings containing U+2028 or U+2029 are
>> not
>> > valid JS expressions. I think it would make sense for `JSON.stringify`
>> to
>> > escape these.
>>
>> What is it that you're saying is not in TC-39's bailiwick?
>>
>> Is it that w3c/whatwg should define what constitutes "embeddable JSON"?
>>
>> Or is it that if it's worth defining a function that produces
>> embeddable JSON from an EcmaScript object, that w3c/whatwg should
>> include that in some set of EcmaScript APIs that it defines?
>>
>> If you agree with my earlier claim
>> """
>> We're talking about JSON serializers.  Every serializers produces
>> a subset of the output language. Choices about that sublanguage affect
>> how easy/hard it is to use that serializer with other tools.
>> """
>> then it seems that TC-39 might take embeddability into account when
>> crafting the subset of JSON that JSON.stringify produces.
>>
>

I agree that this issue belongs with TC39 much more than it belongs
anywhere else. TC39's steering of JS is certainly influenced by how JS gets
used in web browsers. When an issue touches both JS and browser specific
concerns, it can often be unclear whose "jurisdiction" it belongs in. This
one is not unclear. It should be treated as a language issue by TC39.




> ___
>> 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
>
>


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

Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

[Mark S. Miller]

Besides those two, the only other reference
to AddRestrictedFunctionProperties is <
http://www.ecma-international.org/ecma-262/7.0/#sec-createintrinsics>
step 12:

12. Perform AddRestrictedFunctionProperties

(funcProto, realmRec).

So .caller and .arguments must now exist as poisoned on (the intrinsic
normally bound to) Function.prototype . So, besides Function.prototype,
they may only appear on old-style sloppy functions; nowhere else.



On Mon, Sep 5, 2016 at 6:09 PM, Caitlin Potter 
wrote:

> The part that matters here is in annex B: http://www.ecma-
> international.org/ecma-262/7.0/#sec-forbidden-extensions
>
> This forbids functions in strict code from having own properties "caller"
> or "arguments". Newer function kinds have these restrictions in sloppy mode.
>
> AddRestricted... adds the accessor which makes getting/setting "caller" or
> "arguments" throw, but is per spec only performed on intrinsics (like
> %FunctionPrototype%).
>
> So unfortunately, this is something your membrane would need to be aware
> of and work around. Mozilla's approach violates ECMAScript's forbidden
> extensions and can't be considered "correct"
>

This result by itself does not demonstrate that Mozilla or v8 are either
conformant or non-conformant. By the spec, A must not have its own .caller
and .arguments -- it must only inherit these from Function.prototype. B,
being sloppy, may or may not.



>
>
> Sent from my iPhone
> On Sep 5, 2016, at 8:54 PM, Alex Vincent  wrote:
>
> 
> "use strict"
> function A() {}
> 
> 
> function B() {}
> 
> 
> window.onload = function() {
> let a = Reflect.ownKeys(A);
> let b = Reflect.ownKeys(B);
> document.getElementById("output").value = (a.includes("arguments")
> === b.includes("arguments"));
> }
> 
>
> Mozilla Firefox reports true. Google Chrome and node.js report false.
> Which one is correct?
>
> I looked through Mozilla's Bugzilla, Google Chrome's Monorail, and the ES7
> spec to try figuring this out.  The closest I could get was section 9.2.7
> of the ES7 spec. [1]
>
> Right now I have an inadvertent mix of strict code / non-strict code in my
> membrane, and this difference is causing my most recent patch to fail tests
> in nodejs and Google Chrome, and to pass in Mozilla Firefox.  In Chrome and
> nodejs, I get:
>
> TypeError: 'ownKeys' on proxy: trap result did not include 'arguments'
>
> If it turns out Google & nodejs are correct, this could be an issue going
> forward:  I can't control whether my membrane library's users are running
> strict mode code or not... likewise, I don't know if my code should be
> consistently strict mode or consistently non-strict.  (I feel that a mix is
> not good, except for finding bugs like this...)
>
> My apologies for treating this list as a help forum, but I'm just not sure
> where else to go...
>
> [1] http://www.ecma-international.org/ecma-262/7.0/#sec-
> addrestrictedfunctionproperties
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
>
> ___
> 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
>
>


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

Re: Function constants for Identity and No-op

[Mark S. Miller]

On Wed, Aug 10, 2016 at 7:33 AM, Mark S. Miller <erig...@google.com> wrote:

>
>
> On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman <e...@eliperelman.com> wrote:
>
>> I can understand the sentiment of wanting brevity and avoiding
>> unnecessary abstraction, but in some cases I think it comes at the cost of
>> readability or good practice. This is why variables exist at all: to store
>> commonly used values either for reuse or to cut down on unnecessary
>> allocation.
>>
>> Sure, I could write code to ensure my numbers did go over a certain limit
>> with `Math.min(userInput, 9007199254740991)`, but readability and
>> abstraction give me something without having to keep this knowledge
>> internally and create my own allocation, e.g. `Math.min(userInput,
>> Math.MAX_SAFE_INTEGER`.
>>
>
> My message is about tradeoffs -- weighing costs against benefits. The
> costs I raise are cognitive burden.
>
> `x => x` has lower cognitive burden than `Function.IDENTITY`
> `9007199254740991` has much higher cognitive burden than
> `Math.MAX_SAFE_INTEGER`
> `3.141592653589793` has much higher cognitive burden than `Math.PI`
> `3` has lower cognitive burden than `Math.THREE`
>
>
>
>
>>
>> Now obviously it would be trivial for me to declare these constants in
>> userland code like I already do, e.g. `const NOOP = () => {}`
>>
>
>
> If there was a reason to do that, then it might make sense to consolidate
> these. However, this definition looks to me like a userland
>
> `const THREE = Math.THREE;`
>

Meant:

const THREE = 3;




>
> Whether in userland or not, such an "abstraction" only subtracts value.
>
>
>
>
>> , but in projects where it's needed in several files, I'll have to put
>> that in a module or re-declare everywhere. This is not a huge inconvenience
>> but something that could easily allocated for in the language.
>>
>> > The semantics of the named forms can be guessed rather well from the
>> names, but one cannot be sure without looking up or remembering their
>> definitions.
>>
>> This is true of anything; you know what you know, and are unsure of what
>> you are unsure of. Those that understand what a no-ops and identity
>> functions are will not need to look it up, and those that do not will look
>> it up until they know it. Just like my personal enemies `Array#shift` and
>> `Array#unshift`, I have to look those up every single time, and just
>> because I can't remember which is which or their individual case doesn't
>> mean they don't have value or that I resort to other tricks to avoid their
>> usage. All that to say, I don't think lack of knowledge is a valid argument
>> for these constants' non-inclusion. :)
>>
>> > Only pay these costs when the potential benefits are real.
>>
>> I think my allusion to potential benefits is avoidance of re-declaration
>> (DRY) and allocation.
>>
>> Just my thoughts. :)
>>
>> Eli Perelman
>>
>>
>>
>> On Wed, Aug 10, 2016 at 9:08 AM Mark S. Miller <erig...@google.com>
>> wrote:
>>
>>> On Wed, Aug 10, 2016 at 2:10 AM, Isiah Meadows <isiahmead...@gmail.com>
>>> wrote:
>>>
>>>> I'll note that it's longer than just typing them out manually (and
>>>> close if they're aliased):
>>>>
>>>> ```js
>>>> Function.IDENTITY
>>>> IDENTITY
>>>> x => x
>>>>
>>>> Function.NOOP
>>>> NOOP
>>>> () => {}
>>>> ```
>>>>
>>>> Not sure if it adds anything.
>>>>
>>>
>>> Even aside from brevity, `x => x` and `() => {}` are more readable than
>>> `Function.IDENTITY` and `Function.NOOP` for a very simple reason. The
>>> semantics of the shorter forms are obvious and clear, give knowledge only
>>> of the core language. The semantics of the named forms can be guessed
>>> rather well from the names, but one cannot be sure without looking up or
>>> remembering their definitions. As we all know, abstraction has tremendous
>>> potential benefits. But it also has these costs -- the need to learn the
>>> meaning of new definitions. Only pay these costs when the potential
>>> benefits are real.
>>>
>>> Also, other things being equal, a briefer form is easier to read. In
>>> this case, other things are not equal but both considerations point in the
>>> same direction.
>>>
>>>
>>>> On Tue, Aug 9, 2016, 14:44 Eli Perelman <e...@eli

Re: Function constants for Identity and No-op

[Mark S. Miller]

On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman <e...@eliperelman.com> wrote:

> I can understand the sentiment of wanting brevity and avoiding unnecessary
> abstraction, but in some cases I think it comes at the cost of readability
> or good practice. This is why variables exist at all: to store commonly
> used values either for reuse or to cut down on unnecessary allocation.
>
> Sure, I could write code to ensure my numbers did go over a certain limit
> with `Math.min(userInput, 9007199254740991)`, but readability and
> abstraction give me something without having to keep this knowledge
> internally and create my own allocation, e.g. `Math.min(userInput,
> Math.MAX_SAFE_INTEGER`.
>

My message is about tradeoffs -- weighing costs against benefits. The costs
I raise are cognitive burden.

`x => x` has lower cognitive burden than `Function.IDENTITY`
`9007199254740991` has much higher cognitive burden than
`Math.MAX_SAFE_INTEGER`
`3.141592653589793` has much higher cognitive burden than `Math.PI`
`3` has lower cognitive burden than `Math.THREE`




>
> Now obviously it would be trivial for me to declare these constants in
> userland code like I already do, e.g. `const NOOP = () => {}`
>


If there was a reason to do that, then it might make sense to consolidate
these. However, this definition looks to me like a userland

`const THREE = Math.THREE;`

Whether in userland or not, such an "abstraction" only subtracts value.




> , but in projects where it's needed in several files, I'll have to put
> that in a module or re-declare everywhere. This is not a huge inconvenience
> but something that could easily allocated for in the language.
>
> > The semantics of the named forms can be guessed rather well from the
> names, but one cannot be sure without looking up or remembering their
> definitions.
>
> This is true of anything; you know what you know, and are unsure of what
> you are unsure of. Those that understand what a no-ops and identity
> functions are will not need to look it up, and those that do not will look
> it up until they know it. Just like my personal enemies `Array#shift` and
> `Array#unshift`, I have to look those up every single time, and just
> because I can't remember which is which or their individual case doesn't
> mean they don't have value or that I resort to other tricks to avoid their
> usage. All that to say, I don't think lack of knowledge is a valid argument
> for these constants' non-inclusion. :)
>
> > Only pay these costs when the potential benefits are real.
>
> I think my allusion to potential benefits is avoidance of re-declaration
> (DRY) and allocation.
>
> Just my thoughts. :)
>
> Eli Perelman
>
>
>
> On Wed, Aug 10, 2016 at 9:08 AM Mark S. Miller <erig...@google.com> wrote:
>
>> On Wed, Aug 10, 2016 at 2:10 AM, Isiah Meadows <isiahmead...@gmail.com>
>> wrote:
>>
>>> I'll note that it's longer than just typing them out manually (and close
>>> if they're aliased):
>>>
>>> ```js
>>> Function.IDENTITY
>>> IDENTITY
>>> x => x
>>>
>>> Function.NOOP
>>> NOOP
>>> () => {}
>>> ```
>>>
>>> Not sure if it adds anything.
>>>
>>
>> Even aside from brevity, `x => x` and `() => {}` are more readable than
>> `Function.IDENTITY` and `Function.NOOP` for a very simple reason. The
>> semantics of the shorter forms are obvious and clear, give knowledge only
>> of the core language. The semantics of the named forms can be guessed
>> rather well from the names, but one cannot be sure without looking up or
>> remembering their definitions. As we all know, abstraction has tremendous
>> potential benefits. But it also has these costs -- the need to learn the
>> meaning of new definitions. Only pay these costs when the potential
>> benefits are real.
>>
>> Also, other things being equal, a briefer form is easier to read. In this
>> case, other things are not equal but both considerations point in the same
>> direction.
>>
>>
>>> On Tue, Aug 9, 2016, 14:44 Eli Perelman <e...@eliperelman.com> wrote:
>>>
>>>> I'm not sure if something like this has been proposed before, but I
>>>> often find myself declaring constants for the identity function and the
>>>> no-op function. I think it would be useful to have constants available on
>>>> Function containing these values. For example `Function.IDENTITY` and
>>>> `Function.NOOP`. Essentially these constants would map to:
>>>>
>>>> ```js
>>>> Function.IDENTITY = (a) => a;
>>>> Function.NOOP = ()

Re: Function constants for Identity and No-op

[Mark S. Miller]

What's the issue with document.createElement('object')?


On Wed, Aug 10, 2016 at 7:20 AM, Michał Wadas <michalwa...@gmail.com> wrote:

> Using instanceof Function can be confusing, because there are objects
> that are callable but not instanceof Function (document.all,
> document.createElement('object'), any cross-realm function).
>
> Function.isFunction? :D
>
> On Wed, Aug 10, 2016 at 4:00 PM, Mark S. Miller <erig...@google.com>
> wrote:
>
>>
>>
>> On Wed, Aug 10, 2016 at 4:53 AM, Andy Earnshaw <andyearns...@gmail.com>
>> wrote:
>>
>>> On Wed, 10 Aug 2016 at 12:42 Michał Wadas <michalwa...@gmail.com> wrote:
>>>
>>>> Function.prototype is no-op (run Function.prototype.toString() for
>>>> more information)
>>>>
>>>
>>> That's true, but using `Function.prototype` can be confusing
>>>
>>
>> Indeed.
>>
>> > Function.prototype instanceof Function
>> false
>>
>>
>>
>>> when passed to a function as a callback:
>>>
>>> someFunc(Function.prototype);
>>>
>>> It's not immediately clear that `someFunc` is expecting a callback
>>> function in this case, whereas `Function.NOOP` or `() => {}` are pretty
>>> obvious.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
>


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

Re: Function constants for Identity and No-op

[Mark S. Miller]

On Wed, Aug 10, 2016 at 2:10 AM, Isiah Meadows 
wrote:

> I'll note that it's longer than just typing them out manually (and close
> if they're aliased):
>
> ```js
> Function.IDENTITY
> IDENTITY
> x => x
>
> Function.NOOP
> NOOP
> () => {}
> ```
>
> Not sure if it adds anything.
>

Even aside from brevity, `x => x` and `() => {}` are more readable than
`Function.IDENTITY` and `Function.NOOP` for a very simple reason. The
semantics of the shorter forms are obvious and clear, give knowledge only
of the core language. The semantics of the named forms can be guessed
rather well from the names, but one cannot be sure without looking up or
remembering their definitions. As we all know, abstraction has tremendous
potential benefits. But it also has these costs -- the need to learn the
meaning of new definitions. Only pay these costs when the potential
benefits are real.

Also, other things being equal, a briefer form is easier to read. In this
case, other things are not equal but both considerations point in the same
direction.


> On Tue, Aug 9, 2016, 14:44 Eli Perelman  wrote:
>
>> I'm not sure if something like this has been proposed before, but I often
>> find myself declaring constants for the identity function and the no-op
>> function. I think it would be useful to have constants available on
>> Function containing these values. For example `Function.IDENTITY` and
>> `Function.NOOP`. Essentially these constants would map to:
>>
>> ```js
>> Function.IDENTITY = (a) => a;
>> Function.NOOP = () => null; // or:
>> Function.NOOP = () => {};
>> ```
>>
>> These could then be used in places where non-user-controlled APIs need
>> default functions need to be executed, or as placeholders for default
>> values that may be executed before a function has been supplied. For
>> example:
>>
>> ```js
>> // third-party API requires a callback or throws, but no functionality
>> really needs to done:
>> thirdParty.action(Function.NOOP);
>>
>> // Function needs a default which *may* execute prior to having a
>> different one specified (contrived):
>> const action = (handler = Function.IDENTITY, value = 10) =>
>> handler(value);
>> ```
>>
>> Thoughts? Seems like something simple with positive value. Thanks!
>>
>> Eli Perelman
>> ___
>> 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
>
>


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

Re: Function constants for Identity and No-op

[Mark S. Miller]

On Wed, Aug 10, 2016 at 4:53 AM, Andy Earnshaw 
wrote:

> On Wed, 10 Aug 2016 at 12:42 Michał Wadas  wrote:
>
>> Function.prototype is no-op (run Function.prototype.toString() for more
>> information)
>>
>
> That's true, but using `Function.prototype` can be confusing
>

Indeed.

> Function.prototype instanceof Function
false



> when passed to a function as a callback:
>
> someFunc(Function.prototype);
>
> It's not immediately clear that `someFunc` is expecting a callback
> function in this case, whereas `Function.NOOP` or `() => {}` are pretty
> obvious.
>
> ___
> 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: Object.freezing proxies should freeze or throw?

[Mark S. Miller]

On Mon, Aug 8, 2016 at 1:35 PM, Tom Van Cutsem  wrote:

> Claude's additional example is indeed evidence that Object.freeze is not
> to blame, but rather that the invariant checks of
> [[GetOwnPropertyDescriptor]] and [[DefineOwnProperty]] are too weak. The
> culprit is, as far as I can tell, that we re-used the state transitions
> allowed by DefineOwnProperty, which allows the transition from
> non-configurable,writable (-c+w) to non-configurable,non-writable (-c-w)
> and which is unwanted here, as Claude rightfully concludes *[to better
> understand the state transitions involved, see MarkM's lucid state
> transition chart of property attributes
>  >. I wish
> this diagram were in the spec btw, once you know how to read it, it is
> significantly easier to understand than the DefineOwnProperty algorithm
> itself]*
>

I would like to see it in the spec too.


>
> I like the simplicity of Claude's suggestion, but I think that check is
> too tight. Technically if the descriptors are both -c+w data descriptors,
> their value attributes need not be identical to honor the spec invariants.
> Instead I would propose to tackle the problem head-on and explicitly
> disallow a proxy from reporting a -c-w property if the corresponding target
> property is -c+w. We already have a similar check in place in precisely
> those two algorithms to test if the configurable attribute matches. It is
> just a matter of tightening that check to also verify the writable
> attribute.
>
> This would entail the following changes to the ES2015 spec (new or
> modified text in bold):
>
>
> 9.5.5 [[GetOwnProperty]] (P)
>   ...
>   22. If resultDesc.[[Configurable]] is false, then
> a. If targetDesc is undefined or targetDesc.[[Configurable]] is true,
> then
>   i. Throw a TypeError exception.
> *b. If resultDesc.[[Writable]] is false and targetDesc.[[Writable]] is
> true, then*
> *  i. Throw a TypeError exception.*
>
> NOTE [[GetOwnProperty]] for proxy objects enforces the following
> invariants:
>
>   ...
> *  * A property cannot be reported as non-configurable, non-writable if it
> exists as a non-configurable, writable own property on the target object.*
>
>
> 9.5.6 [[DefineOwnProperty]] (P, Desc)
>   ...
>   20. Else targetDesc is not undefined,
> a.  If IsCompatiblePropertyDescriptor(extensibleTarget, Desc ,
> targetDesc) is false, throw a TypeError exception.
> *b. If settingConfigFalse is true*
> *  i. If targetDesc.[[Configurable]] is true, throw a TypeError
> exception.*
> *  ii. If Desc.[[Writable]] is false and targetDesc.[[Writable]] is
> true, throw a TypeError exception.*
>
> NOTE [[DefineOwnProperty]] for proxy objects enforces the following
> invariants:
>
>   ...
> *  * A property cannot be successfully set to non-configurable,
> non-writable if the corresponding own property of the target object is
> non-configurable, writable.*
>
> WDYT?
>
> Regards,
> Tom
>
> 2016-08-08 15:37 GMT+02:00 Claude Pache :
>
>>
>> > Le 8 août 2016 à 11:02, Claude Pache  a écrit :
>> >
>> > Here is another test case, with [[GetOwnPropertyDescriptor]]:
>> >
>> > ```js
>> > var target = Object.seal({x: 2});
>> > var proxy = new Proxy(target, {
>> >getOwnPropertyDescriptor(o, p) {
>> >var d = Reflect.getOwnPropertyDescriptor(o, p)
>> >if (d && 'writable' in d)
>> >d.writable = false
>> >return d
>> >}
>> > });
>> >
>> > Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 2, writable:
>> false, configurable: false }
>> >
>> > Object.defineProperty(proxy, 'x', { value: 3 })
>> >
>> > Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 3, writable:
>> false, configurable: false }
>> > ```
>> >
>> > IMHO, the most robust fix is the following: Both the
>> [[DefineOwnProperty]] and the [[GetOwnPropertyDescriptor]] contain the
>> following check:
>> >
>> > * If IsCompatiblePropertyDescriptor(extensibleTarget, resultDesc,
>> targetDesc) is false, throw a TypeError exception.
>> >
>> > I think there should be also the following check (except when
>> targetDesc is undefined, in which case another appropriate check is used):
>> >
>> > * If IsCompatiblePropertyDescriptor(extensibleTarget, targetDesc,
>> resultDesc) is false, throw a TypeError exception.
>> >
>> > That would replace the weaker adhoc check about the [[Configurable]]
>> attribute (search for settingConfigFalse) in those algorithms.
>> >
>> > (Alternatively, in order to avoid double checks, define an
>> AreBothWaysCompatiblePropertyDescriptors(extensibleTarget, desc1, desc2)
>> abstract operation.)
>> >
>> > —Claude
>> >
>>
>> Looking closer, it seems that using IsCompatiblePropertyDescriptor is in
>> fact an overkill, because we probably don’t want the special case of
>> conditionally mutable [[Writable]] attribute 

Re: Object.freezing proxies should freeze or throw?

[Mark S. Miller]

Hi Raul, yes it would. The invariants apply to all objects.

If someone would like to write up the spec bug and fix, I'll happily
represent and advance it at upcoming meetings.


On Sun, Aug 7, 2016 at 6:49 AM, Raul-Sebastian Mihăilă <
raul.miha...@gmail.com> wrote:

> Would be a good idea to do the test for any kind of exotic objects
> (including host defined ones), not only for proxies?
>
> On Sun, Aug 7, 2016 at 4:33 PM, Tom Van Cutsem  wrote:
>
>> Good catch. This appears to be a genuine spec bug.
>>
>> First, I thought that the problem simply was due to sloppy-mode silent
>> failures, as a call to Object.isFrozen revealed that the proxy is not
>> actually frozen after the call to Object.freeze. When your script is run in
>> strict mode, it fails:
>>
>> on Chrome: Uncaught TypeError: 'set' on proxy: trap returned falsish for
>> property 'x'
>> on Firefox: TypeError: proxy set handler returned false for property '"x"'
>>
>> However, this error can easily be avoided by adding a `return true` to
>> the set trap. At this point, your example still runs in strict mode, which
>> worried me.
>>
>> The culprit is not that the proxy's "x" property can still be updated,
>> but rather that Object.freeze(proxy) doesn't actually freeze the proxy yet
>> still returns without throwing. Thus, a shorter testcase of the problem is:
>>
>>   "use strict";
>>   const target = Object.seal({x: 2});
>>   const proxy = new Proxy(target, {
>> defineProperty() {
>>   return true;
>> }
>>   });
>>   Object.freeze(proxy);
>>   console.log(Object.isFrozen(proxy)); // expected true, but is false
>>
>> Tracing through the ES2015 spec, the spec 'call stack' is roughly:
>>
>> 19.1.2.5 Object.freeze ( O )
>> calls 7.3.14 SetIntegrityLevel (O, level = "frozen")
>>  calls 7.3.7 DefinePropertyOrThrow (O, P = "x", desc = {configurable:
>> false, writable: false})
>>   calls 9.5.6 [[DefineOwnProperty]] (P, Desc)
>>calls 9.1.6.2 IsCompatiblePropertyDescriptor (Extensible, Desc,
>> Current)
>> calls 9.1.6.3 ValidateAndApplyPropertyDescriptor (O, P, extensible,
>> Desc, current)
>>  where O = undefined, P = undefined, extensible = false,
>> Desc = {configurable: false, writable: false},
>> current = { value: 2, writable: true, enumerable: true,
>> configurable: false }
>>
>> The ValidateAndApplyPropertyDescriptor, when called via
>> IsCompatiblePropertyDescriptor, essentially checks whether it is legal
>> to update an existing property descriptor `current` to a new state
>> described by `Desc`, without actually performing the update.
>>
>> Tracing through the details of that algorithm, it turns out the above
>> property descriptors are indeed compatible. It is legal to update a data
>> property {writable: true, configurable: false} to {writable: false,
>> configurable: false}. IIRC, this is somewhat of an exception as it is the
>> only state transition allowed on a non-configurable data property.
>>
>> Because IsCompatiblePropertyDescriptor returns true, the
>> [[DefineOwnProperty]] call on the proxy completes successfully, signaling
>> to SetIntegrityLevel that the property appears to be successfully updated
>> to {configurable: false, writable: false} (even though it didn't in this
>> case, as the proxy's "defineProperty" trap simply returned `true` without
>> actually performing the update).
>>
>> The quick fix appears to be to change the SetIntegrityLevel algorithm as
>> follows, by updating step 10:
>>
>> 10. If O is a Proxy, return TestIntegrityLevel(O, "frozen"), otherwise
>> return true.
>>
>> With this change, the call to SetIntegrityLevel ends with a call to
>> TestIntegrityLevel, which will notice that O is in fact not frozen and thus
>> cause the call to Object.freeze to fail.
>>
>> To summarize: the error here is not with the proxy invariant checks (the
>> proxy is still unfrozen), but rather that because of the exceptional
>> allowed state transfer from writable,non-configurable to
>> non-writable,non-configurable, SetIntegrityLevel fails to detect that the
>> proxy object being frozen in fact remains unfrozen.
>>
>> Cheers,
>> Tom
>>
>> 2016-08-06 21:09 GMT+02:00 Raul-Sebastian Mihăilă > >:
>>
>>> Initially posted on github (https://github.com/tc39/ecma262/issues/652),
>>> but I think the mailing list is more appropriate.
>>>
>>> Usually methods on Object that change some internal state of the
>>> objects/properties of the objects either succeed or throw. However,
>>> Object.freeze can fail to freeze proxies without throwing:
>>>
>>> ```js
>>>   const target = Object.seal({x: 2});
>>>   const proxy = new Proxy(target, {
>>> defineProperty() {
>>>   return true;
>>> },
>>>
>>> set(target, prop, value) {
>>>   target[prop] = value;
>>> }
>>>   });
>>>
>>>   Object.freeze(proxy);
>>>   console.log(proxy.x); // 2
>>>   proxy.x = 

Bad advice on confirming the existence of bugs.

[Mark S. Miller]

On Wed, Jul 27, 2016 at 10:20 AM, Alex Vincent  quoted:

>
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
>


I rarely comment on these incidental aphorisms, but this one is so wrong
that it is worth pointing out. You can confirm the existence of many bugs
by
  * demonstration via failing test case,
  * finding the bug,
  * having a plausible explanation for why it is incorrect,
  * writing a fix with a plausible explanation for why it fixes the
problem, and
  * demonstrating that the fix repairs the demonstrated test case.

However hard this is, it is vastly easier than confirming that there are no
bugs in your own code.

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

Can strict parameters shadow strict function names?

[Mark S. Miller]

var foo = function bar(bar) {'use strict'};

On all version of Safari/JSC I just tested, this code gives a
SyntaxError: Invalid parameters or function name in strict mode.

On all versions of Chrome/v8 and FF/SpiderMonkey I just tested, this code
is accepted without error.

Which behavior is incorrect? Is this an ES5 vs ES2015 issue? Are there
currently any existing bug reports about this? Any test262 tests?

We are running into this when loading the output of a minifier as strict
code.

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

Re: Process of proposing targeted deconstruction

[Mark S. Miller]

ES2015 was the last version for which the short for ("ES6") was also in
common use. After that, there is only ES2016 etc. There is no such thing as
ES7.


On Wed, Jun 1, 2016 at 3:03 PM, John Gardner  wrote:

> I'd like to propose a simple yet potent syntax addition
> 
> for /ECMAScript\d+/. What's the most direct approach to get this
> officially considered? I've seen differing procedures mentioned in places
> and I'm unsure.
>
> BTW, am I the only one getting confused by the year-based naming
> convention? I skip over intermediate letters when reading and only absorb
> the last digit, which makes me mistake ES2017 as ES7, which is actually
> ES2016, which I get mixed up with ES6, which is ES2015.
>
> ___
> 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: Observing whether a function is strict

[Mark S. Miller]

On Thu, May 26, 2016 at 1:23 PM, Mark S. Miller <erig...@google.com> wrote:

>
>
> On Thu, May 26, 2016 at 11:25 AM, Claude Pache <claude.pa...@gmail.com>
> wrote:
>
>>
>> > Le 26 mai 2016 à 10:43, G. Kay Lee <
>> balancetraveller+es-disc...@gmail.com> a écrit :
>> >
>> > I was under the impression that strict mode is a (temporary) workaround
>> to get rid of unwanted bad parts of the language without instantly breaking
>> anything. The long term question thus should be: do we have a timeline on
>> the final removal of non-strict behavior from the language, and establish
>> the "strict mode" as the one and only standard behavior. If so, then
>> introducing any additional language feature to help detecting
>> strict/non-strict is certainly not ideal.
>>
>> AFAIK, there is no plan to remove non-strict mode.
>>
>
There are indeed no plans to remove sloppy mode. Fortunately, the desire to
make *new* features available in sloppy mode is waning. Sloppy mode should
be seen only as an ES3 compatibility mode. It is unfortunate that we were
not able to convince the committee not to extend new ES2015 features to
sloppy mode. The result has cost both implementors and users. It cost
implementors a substantial amount of extra work. (In side conversations I
heard shockingly high estimates.) It hurt users by giving extra life to
sloppy mode. None of this was needed for compat. The only compat
requirement at the time was not to break pre-ES2015 sloppy code.
Syntactically, that is essentially identical to ES3.

Hopefully we can avoid repeating this mistake moving forward from here. Let
sloppy mode remain where it is while the rest of the language moves forward.


>> And to be clear about my intentions, what I have in the back of my head
>> was certainly not "introducing any additional language feature to help
>> detecting strict/non-strict" (yuck!), but whether it makes sense to think
>> about a possible way to remove that leak from `Function#arguments` and
>> `Function#caller`. But it would be premature to consider that issue without
>> *at least* an answer to my original question: Are there other ways...?
>>
>
> Hi Claude, what do you mean by "remove that leak"? Hypothetically, let's
> say you had such a test and that it was reliable. How would you use it
> remove the leak? (This is probably also the best way to clarify what
> precisely you mean by removing the leak.)
>
>
>
>>
>> —Claude
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> Cheers,
> --MarkM
>



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

Re: Observing whether a function is strict

[Mark S. Miller]

On Thu, May 26, 2016 at 11:25 AM, Claude Pache 
wrote:

>
> > Le 26 mai 2016 à 10:43, G. Kay Lee <
> balancetraveller+es-disc...@gmail.com> a écrit :
> >
> > I was under the impression that strict mode is a (temporary) workaround
> to get rid of unwanted bad parts of the language without instantly breaking
> anything. The long term question thus should be: do we have a timeline on
> the final removal of non-strict behavior from the language, and establish
> the "strict mode" as the one and only standard behavior. If so, then
> introducing any additional language feature to help detecting
> strict/non-strict is certainly not ideal.
>
> AFAIK, there is no plan to remove non-strict mode.
>
> And to be clear about my intentions, what I have in the back of my head
> was certainly not "introducing any additional language feature to help
> detecting strict/non-strict" (yuck!), but whether it makes sense to think
> about a possible way to remove that leak from `Function#arguments` and
> `Function#caller`. But it would be premature to consider that issue without
> *at least* an answer to my original question: Are there other ways...?
>

Hi Claude, what do you mean by "remove that leak"? Hypothetically, let's
say you had such a test and that it was reliable. How would you use it
remove the leak? (This is probably also the best way to clarify what
precisely you mean by removing the leak.)



>
> —Claude
>
> ___
> 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: Disabling nonstandard RegExp functionalities for proper subclasses of RegExp

[Mark S. Miller]

Sorry, none of these examples are persuasive. Such non-local causality is a
nightmare on many grounds. If we did want to provide equivalent
functionality somehow, we should find a non-stupid way to package it.

I like Claude's proposal as stated: Annex B normative *optional*,
configurable and actually deletable, no contamination of cross-realm or
subclasses. The only reason to admit even that is legacy. Claude's proposal
is a clean proposal that accommodates legacy while minimizing further
impact.


On Tue, Apr 26, 2016 at 9:50 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> My 2 cents.
>
> I always had the feeling people complaining about `RegExp.$1` and friends
> never really used them.
>
> For instance, your example:
>
> ```js
> /(a)/.exec('a')
> Object.keys(bar)
> RegExp.$1
> ```
>
> might have side effects but it's also made up and, I believe, not a
> real-world concern.
> If you use `re.exec` you address it, otherwise you go `re.test` while if
> you use `re.test` you (or at least *me*) are aware of possible side effects
> and will use the `RegExp.$1` or other property *instantly* after.
>
> Following just a simple example:
>
> ```js
> if (/^item-(\d+)$/.test(id)) {
>   let num = parseInt(RegExp.$1, 10);
>   // the rest of the code
> }
> ```
>
> I'm not saying these properties are cool, always safe, or anything, I'm
> just saying there are few useful cases for them.
>
> However, while I agree the problem is that these modify the globally
> shared constructor, I also think that having these magic properties
> available in a subclass only, would be probably the key to solve pretty
> much all problems described in that page.
>
> ```js
> reg.exp = class extends RegExp {};
> function reg(source, ...flags) {
>   return typeof source === 'string' ?
> new reg.exp(...[source, ...flags]) :
> new reg.exp(source.source, source.flags);
> }
>
> if (reg(/^item-(\d+)$/).test(id)) {
>   let num = parseInt(reg.exp.$1, 10);
>   // the rest of the code
>
>   RegExp.$1 === reg.exp.$1; // false
>   // the extended RegExp didn't modify
>   // the global RegExp
> }
> ```
>
> Of course this would still suffer same, or very similar, problems in case
> `re.class` is exported as module and consumed by many different libraries,
> but I would be surprised if subclassing `RegExp` will create a limited
> subset or, at least, I wouldn't call that an extend.
>
> After all, if "safe" is the main concern, writing `class SRegExp extends
> RegExp {}` on top of a module that uses RegExp in various ways doesn't look
> like a big piece of extra code to write, it's like a function declaration
> and it will make your code immune from global RegExp gotchas.
>
> Or ... doesn't it?
>
> Best Regards
>
>
>
>
>
>
>
>
>
> On Tue, Apr 26, 2016 at 7:20 PM, Claude Pache 
> wrote:
>
>> Hi,
>>
>> About the bad old nonstandard RegExp functionalities:
>>
>> * `RegExp.prototype.compile()` — currently in Annex B;
>> * `RegExp.$1`, `RegExp.leftContext`, etc. — currently unspecced.
>>
>> Although we could probably not get rid of them for plain regexps, I think
>> it is a good idea to disable them for proper subclasses of RegExp (e.g.,
>> `class MyRegExp extends RegExp {}`).
>>
>> Basically, the reason is that these methods break encapsulation (they
>> operate on the raw regexp), leading to potential bugs when using them.
>> Moreover `RegExp.$1` and friends have the additional troublesome property
>> of relying on a global state that could be unexpectedly modified. For
>> concrete examples of what could go wrong, see the
>> subclass-restriction-motivation.md subpage in the proposal linked below.
>>
>> Here is a link to a possible specification for the regexp statics
>> (RegExp.$1, ...), that includes the disabling of bad legacy features for
>> proper subclasses of RegExp (and for some edge-cases around cross-realm
>> interactions):
>>
>>  https://github.com/claudepache/es-regexp-legacy-static-properties
>>
>> What do you think? Are implementations willing to try?
>>
>> —Claude
>>
>>
>> ___
>> 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
>
>


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

Re: Do await statements unblock synchronously?

[Mark S. Miller]

Not necessarily "the next tick", but some future tick. Definitely not in
this tick or the tick in which the promise is resolved. Definitely in its
own tick.

And yes, engines can always do whatever unobservable optimizations they
want.


On Mon, Apr 11, 2016 at 6:00 PM, Jordan Harband  wrote:

> As I understand it, `await` always fires in the next tick, if it's
> observable.
>
> The opportunity to optimize that to "same tick" exists if an engine can
> prove it's not observable.
>
> On Mon, Apr 11, 2016 at 9:54 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> > I suppose I'm asking for cases where the await statement's promise is
>> unresolved.
>>
>> isn't that a "forever pending"? then AFAIK it should "forever await" ...
>> right?
>>
>> On Mon, Apr 11, 2016 at 5:50 PM, /#!/JoePea  wrote:
>>
>>> Is code that follows an await statement supposed to get executed in
>>> the same tick in which the statement's awaited promise is resolved?
>>> F.e.:
>>>
>>> ```js
>>> let resolve = null
>>> const somePromise = new Promise(r => resolve = r)
>>>
>>> ~async function() {
>>>   await somePromise
>>>   doSomething()
>>> }()
>>>
>>> // ... time passes
>>> resolve()
>>> ```
>>>
>>> Should `doSomething()` fire in that same tick as when `resolve()` is
>>> called? I already know that if this is true, there's at least one
>>> exception: `await Promise.resolve()`, in that the await statement must
>>> still defer to a future tick even though the given Promise is already
>>> resolved. I suppose I'm asking for cases where the await statement's
>>> promise is unresolved.
>>>
>>> - Joe
>>> ___
>>> 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
>>
>>
>
> ___
> 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: Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

[Mark S. Miller]

On Tue, Mar 29, 2016 at 7:02 AM, Mark S. Miller <erig...@google.com> wrote:

> [...]The main reason for listing something in Annex B:
>
>   * It is normative optional -- if the feature exists at all, it must
> exist like so.
>

As the proposal says:

Some of the elements of Annex B are safe and likely mandatory in practice,
> independent of host environment:
>
>- escape and unescape
>
>
>- Object.prototype.__proto__
>
>
>- String.prototype.substr
>
>
>- The String.prototype methods defined in terms of the internal
>CreateHTML: anchor, big, ..., sup
>
>
>- Date.prototype.getYear and Date.prototype.setYear
>
>
>- Date.prototype.toGMTString
>
>
>- __proto__ Property Names in Object Initializers
>
> <http://www.ecma-international.org/ecma-262/6.0/#sec-__proto__-property-names-in-object-initializers>
>
> Some of these are messy but none are unsafe or inherently stateful. I
would welcome an investigation into which of these are in fact normative
mandatory in practice, independent of host environments. For those, I would
welcome proposals to move them into the main normative mandatory text.
However, I do not have the energy to pursue that myself. Thanks.


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

Re: Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

[Mark S. Miller]

On Tue, Mar 29, 2016 at 6:50 AM, Mark S. Miller <erig...@google.com> wrote:

> Good question!
>
> Regarding the existing global, the frozen realm API proposal does not say
> anything at all -- it is concerned only about TheFrozenRealm and realms
> descendant from it. Outside of the frozen realm proposal, I would indeed
> like us to pin this down better for globals in general. Why only in the
> Annex? If we can get agreement to pin it down, I would prefer that it be in
> the main normative-mandatory text.
>
> Regarding the global of TheFrozenRealm, I did not intend to underspecify
> that. This is an oversight that I will fix. When I said "the global of
> TheFrozenRealm is a plain object" I had in mind that it would inherit
> directly from Object.prototype. I will revise to say that explicitly.
>

Done.



> Thanks!
>
>
>
>
> On Tue, Mar 29, 2016 at 6:34 AM, Bradley Meck <bradley.m...@gmail.com>
> wrote:
>
>> Does this mandate that the global inherit from any specific prototype?
>> Most cases in the wild inherit from Object at some point, but I feel that
>> should only be in the Annex. Several large libraries depend on this, but it
>> is not strictly required for all libraries.
>>
>
>
>
> --
> Cheers,
> --MarkM
>



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

Re: Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

[Mark S. Miller]

On Tue, Mar 29, 2016 at 6:54 AM, Bradley Meck <bradley.m...@gmail.com>
wrote:

> This requirement is not specified in EcmaScript, and I have started
> playing around with `null` inheriting globals. I do not want it explicitly
> mandated by this if ES does not mandate it. Is there a reason it is a
> mandate and not an Annex that is there due to some parts of the ecosystem?
>

If we can get general agreement, to minimize pointless variations after
that agreement, mandating the agreed state is generally better. If we
can't, then we probably can't get enough agreement for an Annex B entry.
The main reason for listing something in Annex B:

  * It is normative optional -- if the feature exists at all, it must exist
like so.

Since the global object must exist, the normative optional rationale would
not seem to apply.




>
> On Tue, Mar 29, 2016 at 8:50 AM, Mark S. Miller <erig...@google.com>
> wrote:
>
>> Good question!
>>
>> Regarding the existing global, the frozen realm API proposal does not say
>> anything at all -- it is concerned only about TheFrozenRealm and realms
>> descendant from it. Outside of the frozen realm proposal, I would indeed
>> like us to pin this down better for globals in general. Why only in the
>> Annex? If we can get agreement to pin it down, I would prefer that it be in
>> the main normative-mandatory text.
>>
>> Regarding the global of TheFrozenRealm, I did not intend to underspecify
>> that. This is an oversight that I will fix. When I said "the global of
>> TheFrozenRealm is a plain object" I had in mind that it would inherit
>> directly from Object.prototype. I will revise to say that explicitly.
>> Thanks!
>>
>>
>>
>>
>> On Tue, Mar 29, 2016 at 6:34 AM, Bradley Meck <bradley.m...@gmail.com>
>> wrote:
>>
>>> Does this mandate that the global inherit from any specific prototype?
>>> Most cases in the wild inherit from Object at some point, but I feel that
>>> should only be in the Annex. Several large libraries depend on this, but it
>>> is not strictly required for all libraries.
>>>
>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
>


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

Re: Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

[Mark S. Miller]

Good question!

Regarding the existing global, the frozen realm API proposal does not say
anything at all -- it is concerned only about TheFrozenRealm and realms
descendant from it. Outside of the frozen realm proposal, I would indeed
like us to pin this down better for globals in general. Why only in the
Annex? If we can get agreement to pin it down, I would prefer that it be in
the main normative-mandatory text.

Regarding the global of TheFrozenRealm, I did not intend to underspecify
that. This is an oversight that I will fix. When I said "the global of
TheFrozenRealm is a plain object" I had in mind that it would inherit
directly from Object.prototype. I will revise to say that explicitly.
Thanks!




On Tue, Mar 29, 2016 at 6:34 AM, Bradley Meck 
wrote:

> Does this mandate that the global inherit from any specific prototype?
> Most cases in the wild inherit from Object at some point, but I feel that
> should only be in the Annex. Several large libraries depend on this, but it
> is not strictly required for all libraries.
>



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

Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

[Mark S. Miller]

At https://github.com/FUDCo/ses-realm

Since I last posted this, I have received much useful feedback of this
proposal, especially from Daniel Ehrenberg, Ojan Vafai, Elliott Sprehn,
Alex Russell, and Dave Herman. Thanks!

This revision addresses this feedback in a variety of ways:

  * By overemphasizing security, the previous version underemphasized the
utility for normal non-security robustness.
  * In accord with extensible web principals, it proposes a lower level API
not specific to ocaps, that can support ocaps and other security models.
  * It reconciles this proposal with the old Realms API proposal at
https://gist.github.com/dherman/7568885
  * By generalizing the spawning of descendant realms, this API supports
the creation of polyfilled realms derived from TheFrozenRealm.

Enjoy!

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

Re: Fwd: Are Zones Global State? Do they provide a dangerous communications channel?

[Mark S. Miller]

On Mar 21, 2016 4:36 AM, "Raul-Sebastian Mihăilă" 
wrote:

> Wouldn't it be enough to prevent access from normal SES realms to the
> proto-SES realm's Zone primordial in order to keep SES as an ocap
> environment (by having the global objects from normal SES realms inherit
> from a proxy of the global object from proto-SES, instead of inheriting
> directly from the proto-SES global object)?
>

Hi Raul, recall that Reflect.theProtoGlobal provides direct access to the
proto-SES realm's global itself (the so-called "proto-global"). If Zone is
found there, then it is pervasively available. The hard question is, is it
safe for this observably mutable global to be pervasively available? At
first I thought the answer was "of course not". Now, due to Dean's
observation, the answer is that it may indeed be safe. This is sufficiently
likely that we should consider the case seriously.

If we decide not to share a global Zone but do decide that it is safe to
have on individual SES realms, then we can treat it more like eval,
Function, Math, and Date: Arrange for it to be absent or crippled on the
proto-global, and instead have separate Zone objects to appear on each SES
realm's global. As with eval and Function, this could be by built-in
initialization. Or as with Date and Math, it could be by user-level
pattern. But before worrying about how to fall back to this more
conservative position, let's continue to critically examine the more
radical hypothesis.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proxy handler.has() does not have a receiver argument?

[Mark S. Miller]

I agree with Allen. I am certainly willing -- often eager -- to revisit and
revise old design decisions that are considered done, when I think the cost
of leaving it alone exceeds the cost of changing it. In this case, the
arguments that this extra parameter would be an improvement seem weak. Even
without the revising-old-decision costs, I am uncertain which decision I
would prefer. Given these costs, it seems clear we should leave this one
alone.

Unless it turns out that the cost of leaving it alone is much greater than
I have understood. If so, please help me see what I'm missing.






On Fri, Mar 18, 2016 at 12:17 PM, Allen Wirfs-Brock 
wrote:

>
> On Mar 18, 2016, at 9:24 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> Agreed with everybody else the `receiver` is always needed and `Proxy` on
> the prototype makes way more sense than per instance.
>
>
> I don’t agree.  While you certainly can imagine a language where each
> object’s “prototype” determines that object’s fundamental behaviors and
> provides the MOP intercession hooks(in fact that’s how most class-based
> languages work).  But that’s not the JS object model.  Each JS object is
> essentially a singleton that defines it’s own fundamental behaviors.
> Whether or this model is better or worse than the class-based model isn't
> really relevant, but in the context of JS there are advantage to
> consistently adhering to that model,
>
> For example, in Michael’s  desired approach, the instance objects of his
> ArrayView abstraction are “ordinary objects”.  One of the fundamental
> behavioral characteristics of ordinary objects is that all of there own
> properties are defined and available to the implementation in a standard
> way. Implementations certainly make use of that characteristic for
> optimization purposes. Michael’s approach would make such optimizations
> invalid because every time an own property needed to be access a prototype
> walk would have to be performed  because there might be an exotic object
> somewhere on the prototype chain that was injecting own property into the
> original “receiver”.
>
> Michael’s preferred approach also introduces observable irregularity into
> the standard JS inheritance model for ordinary objects.
>
> Consider an object created using Michael’s preferred approach:
>
> ```js
> var arr = [0, 1];
> console.log(Reflect.has(arr,”0”));  //true, arr has “0” as an own property
> var subArr = Object.create(arr);
> console.log(Reflect.has(subArr,”0”));  //true, all unshadowed properties
> of proto visible from ordinary objects
>
> var b = new ArrayView2(arr);
> console.log(Reflect.has(b,”0”));  //true, prototype proxy makes array
> elements visible as if properties of b
> var subB= Object.create(b);
> console.log(Reflect.has(subB,”0”));  //false, some unshadowed properties
> of proto is not visible from subB
> ```
>
> Note the his original Proxy implementation does not have this undesirable
> characteristic.
>
> So what about the use of `receiver` in [[Get]]/[[Set]].  That’s a
> different situation.  [[Get]]/[[Set]] are not fundamental, rather they are
> derived (they work by applying other more fundamental MOP operations). The
> `receiver` argument is not used by them to perform property lookup (they
> use [[GetOwnProperty]] and [[GetPrototypeOf]]) for the actual property
> lookup).  `receiver` is only used in the semantics of what happens after
> the property lookup occurs.  Adding a `receiver` argument to the other MOP
> operations for the purpose of changing property lookup semantics seems like
> a step too far. The ES MOP design is a balancing act between capability,
> implementability, and consistency. I think adding `receiver` to every MOP
> operation would throw the design out of balance.
>
> Finally,
>
> Note that we are not really talking about a new capability here.
> Michael’s first design shows that ES proxies already have the capability to
> implement the object level semantics he desires. So, we are only talking
> about exactly how he goes about using Proxy to implement that semantics. He
> would prefer a different Proxy design than what was actually provided by
> ES6. But that isn’t what was specified or what has now been implemented. We
> can all imagine how many JS features might be “better” if they worked
> somewhat differently. But that generally isn’t an option. The existing
> language features and their implementations are what they are and as JS
> programmers we need to work within that reality.
>
> Allen
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Also the `getPrototypeOf` trap is really pointless right now
>
> ```js
> function Yak() {}
> Yak.prototype = new Proxy(Yak.prototype, {
>   getPrototypeOf: (target) => console.log('lulz')
> });
>
> var yup = new Yak;
> Object.getPrototypeOf(yup);
> ```
>
> The `target` is actually the original `Yak.prototype` which is already the
> `yup` prototype: useless trap if used in such way.
>
> Being also 

Draft Proposed Standard SES (Secure EcmaScript)

[Mark S. Miller]

Chip Morningstar and I would like to announce a new proposal, on the agenda
for the upcoming March meeting:

Draft Proposed Standard SES (Secure EcmaScript)

It is now ready for comments at https://github.com/FUDCo/ses-realm

Feedback welcome, both here on this list and on that proposal's issue
tracker. Enjoy!

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

Provide hooks for Content Security Policy (CSP)?

[Mark S. Miller]

At https://github.com/tc39/ecma262/issues/450 we have started discussing
whether a discussion is warranted. Perhaps a discussion is not warranted,
in which case a thread on es-discuss is not needed, as some claim. However,
since we are now discussing this very question, the question of whether we
should have a discussion is moot. We have already started the
meta-discussion. Let's move it here to es-discuss where it belongs.

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

Re: Why Proxy "apply" trap limited to function only?

[Mark S. Miller]

We maintain the invariant that the typeof of an object is stable -- it
never varies over time. An object is callable iff its typeof is 'function'.
By making the callability *and* the typeof of the proxy dependent on its
target, the two stay consistent.

On Wed, Mar 2, 2016 at 6:51 AM, Олег Галабурда  wrote:

> Yes, correct. I want to be able to make a callable Proxy for non-callable
> objects and don't understand why Proxies are having these restrictions.
> As you can see I, and any other developer, can easily bypass this
> restriction and make a wrapper function that actually will be never called
> and just redirect calls made on Proxy to a method of an object.
>

Exactly. You are doing the right thing. This demonstrates that there is no
loss of intended generality from imposing this restriction. It imposes a
minor inconvenience for an uncommon case, as the price of being more
straightforward for common cases.




> If "apply" trap will be allowed for any type of targets this will make
> life easier :)
>
> 2016-03-02 16:19 GMT+02:00 Claude Pache :
>
>>
>> Le 2 mars 2016 à 13:21, Олег Галабурда  a écrit :
>>
>> Hi!
>>
>> I'm currently working on project that allows to manipulate objects passed
>> from Worker.
>> https://github.com/burdiuz/js-worker-interface
>>
>> It creates wrapper objects that record actions applied to this object and
>> send commands to Worker. The problem is, when request is made I cannot know
>> what kind of object is this, so in case of function I should give ability
>> to make calls on the wrapper object.
>> As example, this code:
>>
>> var api = new WorkerInterface('../webworker.js');
>> api.requestTime();
>>
>> When "requestTime" was requested, it calls "get" and immediately returns
>> new Proxy to serve function call. But at time when Proxy is created I do
>> not know if that is function or not. Now I passed "apply" limitation by
>> adding wrapper function and make Proxy think it works with function.
>>
>> https://github.com/burdiuz/js-worker-interface/blob/master/source/interface/proxy.js
>>
>>
>> If I guess correctly your issue, you would like to have something similar
>> to:
>>
>> foo.bar // not-a-function
>>
>> and:
>>
>> foo.bar() // a method call
>>
>> ? Indeed, that is not possible in JavaScript (and that limitation is not
>> restricted to proxies).
>>
>>
>> I found in discussions why "call" trap was rejected, but didn't find
>> anything about restricting "apply" trap to functions only.
>>
>>
>> Probably because "X is a function" is, by design, strictly equivalent to
>> "X is callable"?
>>
>> —Claude
>>
>>
>
>
> --
> Oleg Galaburda
> http://blog.actualwave.com/
> http://jsinterface.googlecode.com/
> http://guibuilder.org/
>
> ___
> 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: Error stack strawman

[Mark S. Miller]

On Thu, Feb 25, 2016 at 6:45 PM, Gary Guo  wrote:

> Things became more complicated when considering async & generators. For
> async calls as mentioned before somewhere in the thread, only Firefox
> Nightly build includes histories of the frame, while all other browsers
> don't. It could be useful to include that in stack trace, but it will then
> be a special case to a general rule, so not all functions are treated as
> the same. Also, including this information can be costly. Similar reasoning
> about usefulness can be extended to generators & async functions. Shall we
> include a copy of history frames at the time the function is called? (If we
> use FF's SavedFrame format, then in this case both `parent` and
> `asyncParent` will be set) Again, this will be costly as well. In these two
> cases, it could be useful to developers if these information are available,
> but generally these will be costly to collect. Making these optional can be
> a choice, by simply not including unsupported fields in the returned
> object. I suppose `isTailCall` can be made optional as well.
>

All important issues. My current stance:

  * We should separate the issue of obtaining the shallow synchronous
within-a-turn stacks from the gathering of multiple of these together into
deep stacks or graphs of asynchronous causality.

  * The getStack and getStackString apis, and the corresponding normative
optional deletable Error.prototype.stack accessor, should only provide
shallow within-turn stacks.

In thinking about how Causeway stitches these separate shallow synchronous
stacks into an overall picture of asynchronous causality, including deep
stacks, I think the next steps are something like:

  * The stack object format should contain one additional thing -- a turn
identifier, identifying the turn that stack occurred in. To avoid leaking
unnecessary implementation details, say that this turn identifier is a
large random number.

  * There be some way to declare that a certain scope of activity (realm?)
is to be instrumented, i.e., that certain significant events generate
notifications to some kind of logging apparatus. This issue already arises
with onerror and unhandled rejection notifications.

  * When instrumented, an action in one turn that schedules something to
happen in another turn also emits a log-notification containing:

* the stack of the scheduling action within the scheduling turn,
including the turn identifier of the scheduling turn.
* the turn identifier of the scheduled turn.

When the scheduling turn and the scheduled turn both happen in the same
vat, then stitching the shallow stacks together into a deep stack creates
exactly the kinds of deep stack we see on FF. However, I purposely phrased
that last bullet so that it also applies to inter-vat causality. For
example, if instrumented worker A does a postMessage to instrumented worker
B, the postMessage event in worker A logs, in A,

  * the stack in A where A did the postMessage, including the identifier of
the A turn in which this happened.
  * the identifier of the turn in worker B where this message will be
processed.

There is much more to be said and explored, but I think that would be a
start. It naturally breaks up into two separable proposals -- the first two
bullets and the rest.

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

Re: Error stack strawman

[Mark S. Miller]

On Wed, Feb 24, 2016 at 2:37 PM, Boris Zbarsky  wrote:

> On 2/24/16 5:35 PM, Boris Zbarsky wrote:
>
>> Clearly this Just
>> Works with a value property, across all browsers at that point, so we
>> made it work with the accessor too.
>>
>
> Oh, and we made it work the way [Replaceable] stuff on window works: the
> setter defines a value property on the object which thereafter shadows the
> prototype's getter.



It is ugly so I would hope we don't need to preserve it. But if it is
needed for web compat, as a normative-optional deletable accessor, I have
no fundamental objection.


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

Re: Error stack strawman

[Mark S. Miller]

Huh, weird. From the discussions that led to <
https://github.com/claudepache/es-regexp-legacy-static-properties> being
proposed and the discussion on that issue, for me to take a consistent
position, I must sadly concede the following:

We allowed a grossly leaky api (the RegExp statics, which leak non-local
information from RegExp instances <https://github.com/google/caja/issues/531>)
to be proposed for standardization as "normative optional", i.e., Annex B,
and deletable. This way, and environment that deletes it still leaves a
conforming system in its wake. Many people think they want error.stack
because it seems to do something on all the browsers -- though their
behaviors are tremendously different from each other. Nevertheless,
whatever behavior we specify for getStackString, we could likewise spec a
normative optional and deletable Error.prototype.stack accessor property,
like Firefox's[1]. As with makeWeakRef and the leaky RegExp statics, we
could specify the getter of this accessor only to work on Error objects
from the same realm[2]. Since errors inherit from the Error.prototype of
their own realm anyway, this does not impede normal usage. We need to
impose the same restriction on getStack and getStackString anyway, for the
same reasons.

FF demonstrates that it is already web compatible to provide error.stack
only by providing a deletable Error.prototype.stack accessor.

On FF, my polyfill <
https://github.com/tvcutsem/es-lab/blob/master/src/ses/debug.js> makes use
of the fact that Error.prototype.stack is an accessor, both to censor the
property on initialization, be deleting it, and to reserve for itself the
ability to inspect stacks, by utilizing the getter it took away. That is
how it implements getStack without providing ambient access to the stack.


[1] For some reason the FF stack accessor has both getter and setter. I
don't see any reason for a setter.
[2] This solves only one of the cross-realm issue with stacks. It does
nothing to address worries about cross-realm stacks.



On Wed, Feb 24, 2016 at 12:37 PM, Mark S. Miller <erig...@google.com> wrote:

> On Wed, Feb 24, 2016 at 11:40 AM, Steve Fink <sph...@gmail.com> wrote:
>
>> On 02/19/2016 01:26 AM, Andreas Rossberg wrote:
>>
>> On 19 February 2016 at 03:13, Gary Guo <nbdd0...@hotmail.com> wrote:
>>
>> If we are not going to indicate tail call some way, debugging might be
>>> extremely difficult, and the stack result might be making no sense at all.
>>>
>>
>> A tail call is a jump. Just like other jumps, you shouldn't expect their
>> history to be visible in the continuation (which is what a stack trace
>> represents). I agree that JS programmers might be surprised, and will have
>> to relearn what they know. But wrt to debugging the situation is the same
>> as for loops: you can't inspect their history either. (And functional
>> programmers in fact see loops as just an ugly way to express self tail
>> recursion. :) )
>>
>>
>> To be even more pedantic: the stack trace isn't "the" continuation, it is
>> one possible continuation. Other continuations are possible if you throw an
>> exception. I guess you could say the stack trace plus the code allows you
>> to statically derive the full set of possible continuations.
>>
>> But I agree that it's worthwhile to remember the difference, since what
>> is being requested for stacks really *is* a history, not a continuation.
>> For example, it is desireable to encode "long stacks" or "async stacks" or
>> whatever they're being called these days, where eg for an event handler you
>> get the stack trace at the point the handler was installed. That is not a
>> continuation, that is history. I would be very wary of mandating that full
>> history be preserved, since it's easy for it to prevent optimizations or
>> inadvertently leak details of the underlying implementation (tail calls,
>> inlining, captured environments).
>>
>> Does it work to specify something like "if and only if the information is
>> available, it shall be encoded like this:..."? That can still leak
>> information if not handled carefully, but at least it doesn't inhibit
>> optimizations.
>>
>> For a wild handwavy example of an information leak: say you do not
>> include inlined calls in stack frames, and you only inline a call after the
>> 10th invocation. Further assume that you self-host some JS feature. The
>> caller can now learn something about how many times that self-hosted
>> feature has been used. That feature might happen to be Math.something used
>> only for processing non-latin1 characters in a password, or more likely
>> just some feature used only i

Re: Error stack strawman

[Mark S. Miller]

On Wed, Feb 24, 2016 at 11:40 AM, Steve Fink  wrote:

> On 02/19/2016 01:26 AM, Andreas Rossberg wrote:
>
> On 19 February 2016 at 03:13, Gary Guo  wrote:
>
> If we are not going to indicate tail call some way, debugging might be
>> extremely difficult, and the stack result might be making no sense at all.
>>
>
> A tail call is a jump. Just like other jumps, you shouldn't expect their
> history to be visible in the continuation (which is what a stack trace
> represents). I agree that JS programmers might be surprised, and will have
> to relearn what they know. But wrt to debugging the situation is the same
> as for loops: you can't inspect their history either. (And functional
> programmers in fact see loops as just an ugly way to express self tail
> recursion. :) )
>
>
> To be even more pedantic: the stack trace isn't "the" continuation, it is
> one possible continuation. Other continuations are possible if you throw an
> exception. I guess you could say the stack trace plus the code allows you
> to statically derive the full set of possible continuations.
>
> But I agree that it's worthwhile to remember the difference, since what is
> being requested for stacks really *is* a history, not a continuation. For
> example, it is desireable to encode "long stacks" or "async stacks" or
> whatever they're being called these days, where eg for an event handler you
> get the stack trace at the point the handler was installed. That is not a
> continuation, that is history. I would be very wary of mandating that full
> history be preserved, since it's easy for it to prevent optimizations or
> inadvertently leak details of the underlying implementation (tail calls,
> inlining, captured environments).
>
> Does it work to specify something like "if and only if the information is
> available, it shall be encoded like this:..."? That can still leak
> information if not handled carefully, but at least it doesn't inhibit
> optimizations.
>
> For a wild handwavy example of an information leak: say you do not include
> inlined calls in stack frames, and you only inline a call after the 10th
> invocation. Further assume that you self-host some JS feature. The caller
> can now learn something about how many times that self-hosted feature has
> been used. That feature might happen to be Math.something used only for
> processing non-latin1 characters in a password, or more likely just some
> feature used only if you are logged into a certain site. (Perhaps
> Error.stack is already specced to avoid this, by requiring all frames to be
> included whether inlined or not? Sorry, I don't know anything about it; I'm
> just posting to ask the question about what specifying stack formats
> encompasses.)
>


This information leak is not specific to tail-call variance. It is a
problem with the whole error.stack interface <
http://www.combex.com/papers/darpa-review/security-review.html#UniversalScope>.
Like makeWeakRef , that is why
the getStack and getStackString functions won't be generally available to
confined code, but must instead be virtualizable or deniable. Starting with
KeyKOS, capability practitioners refer to this category as "closely held",
as opposed to "ambient". *Everything* in the ES6 standard itself is
ambient, since we postponed spec'ing anything that needs to be closely
held. Now is that time .

Again, as with makeWeakRef, by treating getStack and getStackString as
closely held, it is also less damaging[1] for them to leak implementation
non-determinacy that may carry side channels or covert channels.

[1] It is less damaging when the leakage is limited to intra-realm, since
one realm is not in a position to police another. For getStack and
getStackString, this is yet another reason we need to think hard about
cross-realm stacks. I, for one, have not yet done so.

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

Re: non-self referencial cyclical promises?

[Mark S. Miller]

On Wed, Feb 24, 2016 at 11:54 AM, Bergi  wrote:

> Bradley Meck wrote:
>
>> I was doing some recursive data structure work and ended up with a
>> cyclical
>> promise that did not use a direct self reference. It can be reduced down
>> to:
>>
>> ```javascript
>> var af, a = new Promise(f=>af=f);
>> var bf, b = new Promise(f=>bf=f);
>>
>> af(b);bf(a); // the problem
>>
>> a.then(_=>_) // some env/libs need this to start checking status
>> ```
>>
>> According to
>> https://tc39.github.io/ecma262/#sec-promise-resolve-functions
>> it looks like this should cause a recursive and infinite set of
>> `EnqueueJob("PromiseJobs",...)`
>>
>
> I fear that's what the standard says, yes. The ES6 spec does too many (and
> in some cases, unreasonably many) `then` calls on promises anyway to be
> followed by an efficient promise implementation.
>
> [Promises/A+](https://promisesaplus.com/) in contrast says
>
> | Implementations are encouraged, but not required, to detect such
> | recursion and reject promise with an informative TypeError as the
> | reason.
>

I think the standard *should* require a deterministic error. E <
https://github.com/kpreid/e-on-java/blob/master/src/jsrc/org/erights/e/elib/ref/ViciousCycleException.java>,
Q, and my own Q-like system <
https://github.com/tvcutsem/es-lab/blob/master/src/ses/makeQ.js#L700> all
do. Within an engine, this technique should be straightforward to implement
without slowing down the non-cyclic case.




> Regards,
>  Bergi
>
> ___
> 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: Weak Reference proposal

[Mark S. Miller]

On Fri, Feb 19, 2016 at 5:36 PM, John Lenz  wrote:

> The finalizer holdings, could itself could hold a reference to the
> weakrefernce correct?
>

The holdings can certainly strongly point to the weakref itself, yes. There
is no reason to think this is a mistake.

By contrast, though we cannot prevent the holdings from strongly pointing
to the target, this would almost certainly be a mistake. It would prevent
the finalization that would involve this holdings. See the four scenarios at

https://github.com/tc39/proposal-weakrefs/issues/5#issuecomment-185955167

If the weakref with these holdings is itself strongly reachable (scenarios
1 and 2) then this will also prevent the target from being collected. If
the holdings is strongly reachable (scenario 4) the target again cannot be
collected. If the weakref and the holdings are both not reachable (scenario
3), then they and the target can all be collected at the same time without
any finalization action involving that holdings. Other weakrefs onto target
(wr3a) can observe target disappear, and can have their own finalization
actions. These will still be triggered.

There is a possible controversy regarding scenario 2, for which I'll refer
you to the issue.


> On Fri, Feb 19, 2016 at 12:30 AM, Dean Tribble  wrote:
>
>> Thanks for your comments.
>>
>> A practical answer to your question:  If you drop references to a
>> subsystem that internally uses weak references, the "finalization" it would
>> engage is just death throes. For example, if you drop an Xml parser, then
>> there's no reason to muck out it's internal cache since that's going to be
>> collected anyway. Thus, this variant is more expressive.
>>
>> It also breaks the retention properties of the system. In order to
>> require the executor to run, *something *has to point at it (and the
>> holdings) strongly. Otherwise for example the holdings and executor might
>> not be retained (and you couldn't run finalization). You can end up with
>> cycles of executors pointing at each other's targets such that neither can
>> ever be collected because the system is keeping them around strongly.
>>
>> On Thu, Feb 18, 2016 at 10:42 PM, John Lenz 
>> wrote:
>>
>>> This seems like a very solid proposal.  I like that the finalizers run
>>> on their own turn (it had to be that way in retrospect).
>>>
>>> I'm unclear about one thing: the reasoning for not running finalizers
>>> when weak-references them become unreferenced.  Did I misunderstand this?
>>> Doesn't this force he "hard" reference to also a soft reference "weak
>>> reference" to insure that finalizer run (such as closing a file, etc)?  If
>>> aren't concerned about non-memory resources is there any point to having
>>> holding at all?
>>>
>>>
>>>
>>> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble 
>>> wrote:
>>>
 I have posted a stage 1 proposal for weak references in ES7 for your
 perusal and feedback.

 https://github.com/tc39/proposal-weakrefs.git

 Thanks to Mark Miller and the authors of earlier proposals for help
 with the document and content!  Finally thanks to a few intrepid early
 reviewers for their edits, comments, and feedback.

 ___
 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
>>>
>>>
>>
>
> ___
> 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: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

[Mark S. Miller]

On Fri, Feb 19, 2016 at 1:17 AM, Coroutines  wrote:

> Hi - I hope I am not suggesting something that has been said before ~
>
> Having Proxy and eventual Weak References makes it possible to build
> Map/WeakMap in plain JS - nothing in hidden, 'native code' (C++).
>

Not quite. This is why ephemeron collection makes such a difference. It can
collect cycles that no arrangement of maps and weak references can collect.
In particular, ephemerons are *essential* to build identity-preserving
membranes with both necessary gc properties:

* While the membrane is up, collect across the membrane transparently, as
if the membrane were not there.
* When the membrane is revoked, sever the reachability of all links
crossing the membrane. A compartment fully inside the membrane can then be
fully collected.

If you don't use ephemeron collection and you use the non-transposed
representation, you will fail to collect membrane crossing cycles.
If you don't use ephemeron collection and do use the transposed
representation (as MS Edge currently does) then you will fail to sever
reachability on revocation, failing to collect logically unreachable
compartments.

Since collection across the membrane needs to happen much more often than
cleaning up after revocation, best is ephemeron collection with the
(Edge-like) transposed representation. Ephemeron collection without the
transposed representation (as I think everyone but Edge currently does)
makes normal collection across the membrane boundary much more expensive.
But at least it does eventually clean up both kinds of garbage.



>
> I'd like to propose basing them off of these when Weak References are a
> 'thing'.
>
> Map's API could just go away and follow traditional Object assignment
> and existence checks:
>
> map[key] = value;
>
> // wish JS had a null-coalescing `?` operator like Coffeescript..
> if (map[key] !== undefined || map[key] !== null) { ... }
>
> It's totally legal in non-Node JS to have Objects as keys in other
> Objects, right? (I forget)
>
> So that's my idea.  Toodles ~
>
> PS: And build Set off of a Proxy + Array.  Just stop being weird. :P
> ___
> 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: Error stack strawman

[Mark S. Miller]

On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo  wrote:

> Andreas  wrote:
> > This would be fairly difficult to support by implementations. In V8, for
> example, we currently have no way of reconstructing that information, nor
> would it be easy or cheap to add that. A frame is created by the callee,
> but that does not know how it got called. Funnelling through that
> information would effectively require a hidden extra argument to _every_
> call.
>
> Placing a boolean flag theoretically should not introduce too much
> overhead. If we are not going to indicate tail call some way, debugging
> might be extremely difficult, and the stack result might be making no sense
> at all.
>
> ---
>
> As for how to distinguish between special code source, such as native, if
> https://github.com/tc39/ecma262/issues/395 is resolved, we can use the
> built-in module name for the "source" field, and hopefully we can reserve
> some special built-in module name for native code, cross realm code, etc,
> and then we can have a unified representation of all frames.
>

I like that! At least for the native case. I don't yet have coherent
thoughts regarding the cross-realm issues.



>
> ___
> 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: Error stack strawman

[Mark S. Miller]

On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo  wrote:

> The strawman looks very old, so I've created a new one.
>
> Repo: https://github.com/nbdd0121/es-error-stack
>
> I've collected many information about current implementation from IE,
> Edge, Chrome and Firefox, but missing Safari's. Many thanks if some one can
> collect these info and create a pull request.
>
> I haven't write anything for API part, as you will see from the "concerns"
> part, there are many edge cases to be considered: cross-realm, native,
> global, eval, new Function, anonymous and tail call. All of these need to
> be resolved before we can trying to design an object representation of
> stack frame.
>
> Personally I suggest "(global code)" for global, "(eval code)"  for eval,
> "(Function code)" for new Function, "(anonymous function)" for anonymous
> function/lambda. For native call, we can simply replace filename & line &
> column by "(native)". For tail call I suggest add "(tail)" some where. I
> also suggest adding "(other realm)" or something alike to indicate realm
> boundary is crossed.
>
> For object representation, I hope something like
> ```
> {
>   name: 'string', // (global code), etc for special case, with parenthesis
>   source: 'url', // (native) for native code, with parenthesis
>   line: 'integer',
>   column: 'integer',
>   isTail: 'boolean'
> }
> ```
>

Unless the object representation is primary, we will need to agree on
comprehensive escaping rules, and corresponding parsing rules, so that
these stack strings can be unambiguously scraped even when file names and
function names contain parens, slashes, angle brackets, at-signs, spaces,
etc. Therefore, we should focus on the object representation first.

Your object representation above looks like a good start. It is similar to
the extended Causeway stack format I mentioned earlier

stacktrace ::= {calls: [frame*]};
frame ::= {name: functionName,
   source: source,
   span: [[startLine,startCol?],[endLine,endCol?]?]};
functionName ::= STRING;
startLine, startCol, endLine, endCol ::= INTEGER
source ::= STRING | frame;

with the following differences:

* You added an isTail. This is probably a good thing. I'd like to
understand better what you have in mind.

* Rather than have a single "span" property with a nested array of numbers
as value, you define separate line and column property names. As long as we
represent all that we need unambiguously, I'm indifferent to minor surface
syntax differences.

* Causeway's format has room for both start(line,col) and end(line,col).
The format must include room for this, and I would hope any future standard
would mandate that they be included. Such span information makes a huge
usability improvement in reporting diagnostics.

* The extended Causeway "source" field could be either a string as with
your's, or a nested frame. This is necessary to preserve the information
currently provided on both FF and Chrome of the nested positions in a
single frame, when a call happens at position X in an eval string that was
evaled by an eval call at position Y. (That is what the "extended" means.
Causeway originally only has strings as the value of their "source"
property.)

The proposed[1] API is:

System.getStack(err) -> stack-representation
Reflect.stackString(stack-representation) -> stack-string
System.getStackString(err) -> stack-string

where getStackString is just the obvious composition of getStack and
stackString.



> And null entry indicating crossing realm. BTW, shall we add reference to
> function in the object representation?
>

What do you mean by "reference to" above?


[1] Hopefully https://github.com/tc39/ecma262/issues/395 will resolve in
time that none of these need to be rooted in globals.



>
> Gary Guo
>
> ___
> 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: Garbage collection in generators

[Mark S. Miller]

Everyone, please keep in mind the following distinctions:

General GC is not prompt or predicable. There is an unspecified and
unpredictable delay before anything non-reachable is noticed to be
unreachable.

JavaScript GC is not specified to be precise, and so should be assumed
conservative. Conservative GC may never notice that any particular
unreachable thing is unreachable. The only reliable guarantee is that it
will never collect anything which future computation will reach, i.e., it
will not cause a spontaneous dangling reference. Beyond this, it provides
only unspecified and, at best, probabilistic and partial cleanup.

C++ RAII and Python refcounting are completely different: they are precise,
prompt, predictable, and deterministic.



On Wed, Feb 17, 2016 at 12:59 AM, Benjamin Gruenbaum 
wrote:

>
>
> On Wed, Feb 17, 2016 at 10:51 AM, Andreas Rossberg 
> wrote:
>
>> On 17 February 2016 at 09:40, Benjamin Gruenbaum 
>> wrote:
>>
>>> If you starve a generator it's not going to get completed, just like
 other control flow won't.

>>>
>>> I'm not sure starving is what I'd use here - I definitely do see users
>>> do a pattern similar to:
>>>
>>> ```js
>>> function getResults*() {
>>>  try {
>>>  var resource = acquire();
>>>  for(const item of resource) yield process(item);
>>>  } finally {
>>>  release(resource);
>>>  }
>>> }
>>> ```
>>>
>>
>> Yes, exactly the kind of pattern I was referring to as "bogus forms of
>> resource management". This is an anti-pattern in ES6. It won't work
>> correctly. We should never have given the illusion that it does.
>>
>
> What is or is not an anti-pattern is debatable. Technically if you call
> `.return` it will run the finally block and release the resources (although
> if the finally block itself contains `yield` those will also run).
> Effectively, this will have the same sort of consequences that "acquire()"
> and "release()" had to begin with - so I would not say it makes things
> worse but I definitely agree that it creates a form of false expectation.
>
> Still - I'm very curious why languages like Python have chosen to call
> `finally` blocks in this case - this was not a hindsight and according to
> the PEP. They debated it and explicitly decided to call `release`. I'll see
> if I can email the people involved and ask about it.
>
>
>
>> garbage collection is a form of automatic resource management.
>>
>>
>> Most GC experts would strongly disagree, if by resource you mean anything
>> else but memory.
>>
>
> Memory is most certainly a resource. Languages that are not GCd like C++
> really don't make the distinction we make :)
>
> Garbage collection can and does in fact manage resources in JavaScript
> host environments right now. For example, an XMLHttpRequest *may *abort
> the underlying HTTP request if the XMLHttpObject is not referenced anywhere
> and gets garbage collected.
>
>
> ___
> 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: Weak Reference proposal

[Mark S. Miller]

What are the GC semantics specified for DOM? How are these observable?


On Tue, Feb 16, 2016 at 7:04 PM, Isiah Meadows 
wrote:

> I know this is only tangentially related, but I just remembered weak refs
> are required for a fully conforming DOM implementation because of their GC
> semantics. I feel this is relevant with the semi-recent DOM-in-JS efforts.
>
> On Tue, Feb 16, 2016, 20:24 Allen Wirfs-Brock 
> wrote:
>
>> Ecma International needs to capture a accurate historical archive  of the
>> contributions and deliberation that goes into TC39’s design decisions.  The
>> current “policy” of TC39 is that once a proposal reaches Stage 1 is MUST be
>> hosted on the TC39 github site.  However, when a proposal, like this one,
>> is actively being developed using contributions (eg, discussion) by
>> multiple TC39 members it seems like the record of that SHOULD be included
>> in the Ecma archives.  The best way to ensure that is for such discussion
>> to be hosted on the TC39 github account, even if the proposal is only at
>> stage 0.
>>
>> Allen
>>
>>
>> ___
>> 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: Weak Reference proposal

[Mark S. Miller]

On Tue, Feb 16, 2016 at 4:26 PM, Kevin Smith  wrote:

> I have no problem with that, but do wonder, why? What is the downside of
>>> proposals being on the tc39 hub starting at an earlier stage, if the
>>> authors are so inclined? The upside is fewer broken links.
>>>
>>
> Because having the tc39 "brand" on things sends a signal to the broader
> community about the future state of ecma262?
>

Makes sense.


>
> Also, github forwards URLs when the repo is transferred, so we're good
> there.  Case in point:  https://github.com/zenparsing/async-iteration
>
>>
Cool! I did not know that.


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

Re: Weak Reference proposal

[Mark S. Miller]

On Tue, Feb 16, 2016 at 3:52 PM, Kevin Smith <zenpars...@gmail.com> wrote:

> I suggest that this one be left on tc39 since it's already there and there
> is a history of weakref proposals anyway.  But in general we should only
> move proposals to tc39 at stage .
>

I have no problem with that, but do wonder, why? What is the downside of
proposals being on the tc39 hub starting at an earlier stage, if the
authors are so inclined? The upside is fewer broken links.



>
> On 6:32PM, Tue, Feb 16, 2016 Mark S. Miller <erig...@google.com> wrote:
>
>> On Tue, Feb 16, 2016 at 2:02 PM, Daniel Ehrenberg <
>> dehrenb...@chromium.org> wrote:
>>
>>> I think this proposal is currently at Stage 0, right?
>>
>>
>> Right. It is stage 0.
>>
>>
>>> Do we typically
>>> put Stage 0 proposals on the TC39 GitHub? My understanding was that
>>> proposals typically get moved after Stage 2.
>>>
>>
>> Typically yes. My assumption is that our desire here was one way -- we
>> want to ensure it is on the (tc39) hub once it is at stage 2. I was
>> assuming there was no issue in the opposite direction, i.e., that we do not
>> actively want to ensure that it is or is not on the hub prior to stage 2.
>> Perhaps I misunderstood. Is there anything about this in our process docs
>> or prior discussions?
>>
>> Certainly, if for some reason we wish to ensure that earlier proposals
>> are not on the hub, it would be easy to move off, and then back on later.
>> This has a cost in broken links. What is the compensating benefit?
>>
>>
>>
>>>
>>> Dan
>>>
>>> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble <trib...@e-dean.com>
>>> wrote:
>>> > I have posted a stage 1 proposal for weak references in ES7 for your
>>> perusal
>>> > and feedback.
>>> >
>>> > https://github.com/tc39/proposal-weakrefs.git
>>> >
>>> > Thanks to Mark Miller and the authors of earlier proposals for help
>>> with the
>>> > document and content!  Finally thanks to a few intrepid early
>>> reviewers for
>>> > their edits, comments, and feedback.
>>> >
>>> > ___
>>> > 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
>>>
>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>> ___
>> 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: Weak Reference proposal

[Mark S. Miller]

On Tue, Feb 16, 2016 at 2:02 PM, Daniel Ehrenberg 
wrote:

> I think this proposal is currently at Stage 0, right?


Right. It is stage 0.


> Do we typically
> put Stage 0 proposals on the TC39 GitHub? My understanding was that
> proposals typically get moved after Stage 2.
>

Typically yes. My assumption is that our desire here was one way -- we want
to ensure it is on the (tc39) hub once it is at stage 2. I was assuming
there was no issue in the opposite direction, i.e., that we do not actively
want to ensure that it is or is not on the hub prior to stage 2. Perhaps I
misunderstood. Is there anything about this in our process docs or prior
discussions?

Certainly, if for some reason we wish to ensure that earlier proposals are
not on the hub, it would be easy to move off, and then back on later. This
has a cost in broken links. What is the compensating benefit?



>
> Dan
>
> On Sun, Feb 14, 2016 at 11:35 PM, Dean Tribble  wrote:
> > I have posted a stage 1 proposal for weak references in ES7 for your
> perusal
> > and feedback.
> >
> > https://github.com/tc39/proposal-weakrefs.git
> >
> > Thanks to Mark Miller and the authors of earlier proposals for help with
> the
> > document and content!  Finally thanks to a few intrepid early reviewers
> for
> > their edits, comments, and feedback.
> >
> > ___
> > 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
>



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

Re: Why are ES6 class methods not automatically bound to the instance?

[Mark S. Miller]

Hi Jordan, this is an excellent point. I can't say I remember it being
raised, but it would certainly have been adequate to kill any proposal that
this be the default behavior.



On Wed, Feb 10, 2016 at 8:22 AM, Jordan Harband  wrote:

> One of the wonderful features of many prototype methods is that they can
> be borrowed and .call-ed on other objects (imagine if you couldn't
> `Array.prototype.slice.call(arguments)`!). Auto binding would cripple this
> feature, and it seems like opting out would be harder than opting in.
>
> I'm not sure if that was part of the reasoning or not, but I believe it
> was definitely the right decision.
>
>
> On Wednesday, February 10, 2016, Sam Gluck  wrote:
>
>> Hi all,
>>
>> Hope this is the right place for a purely out-of-interest query - if not,
>> apologies, please ignore!
>>
>> Why are methods on an ES6 class not automatically bound to their
>> instance? Is there any public documentation/conversation, or reasoning,
>> that can explain this decision? (I couldn't find any on esdiscuss.org.)
>>
>> Thank you.
>>
>> Best
>> Sam
>>
>
> ___
> 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: Why are ES6 class methods not automatically bound to the instance?

[Mark S. Miller]

On Wed, Feb 10, 2016 at 7:11 AM, Sam Gluck  wrote:

> Hi all,
>
> Hope this is the right place for a purely out-of-interest query - if not,
> apologies, please ignore!
>
> Why are methods on an ES6 class not automatically bound to their instance?
> Is there any public documentation/conversation, or reasoning, that can
> explain this decision? (I couldn't find any on esdiscuss.org.)
>

That is an excellent question. Several of the early class proposals did so,
as they were starting with the semantics of es5 objects-as-closures and
classes as compositions-of-instance-traits.

http://wiki.ecmascript.org/doku.php?do=search=traits

The idea was that language support would make this semantics efficient,
avoiding the need to eagerly allocate a closure per method per instance.

However, for reasons I understand, these failed to gain traction. Instead,
we moves towards sugar for the dominant es5 pattern of encoding classes
into prototype inheritance. Initially, we tried to have this purely be
sugar, so that people could painlessly refactor code in that dominant
pattern into classes.

As we wrestled with the detailed semantics around super and construction,
es6 classes deviated from being pure sugar. But this deviation only
prevents painless refactoring from es6 classes into the dominant es5
pattern. Practically, it remains painless to refactor from the es5 pattern
into es6 classes.

At  we realized
we could still have had methods bind on extraction -- accounting for the
behavior by decreeing that methods are installed on the prototype as
accessors whose getter binds. However, this realization came too late for
es6. Since it would have made the refactoring into classes more hazardous
-- more of a semantic change -- it is not clear it would have flown even if
we had thought of it in time. Instead, under all variations of the
decorator designs, one can write such a decorator so that decorated methods
are bind-on-extraction, by explicitly creating this accessor property.
However(!), if implemented as a user-land decorator, this has much worse
performance than objects-as-closures!! Objects-as-closures have higher
allocation cost when allocating the object.

http://jsperf.com/creating-stateful-objects

But are quite efficient at using the object once the object is created:

http://jsperf.com/strict-where-state

(Note that jsperf is misidentifying Edge 28.14257.1000.0 as Chrome
46.0.2486. This is worth noting because Edge uses the transposed
representation for WeakMaps, and so WeakMap-based usage of private state
has much less penalty on Edge. Though this is besides the point of this
thread.)

To make a decorator for binding-on-extraction efficient, an implementation
would need some kind of special case somewhere to avoid the allocation when
the method is being immediately invoked, rather than being observably
extracted. The only thing TC39 needs to do to enable this is to standardize
such a decorator so that implementations can provide it as a builtin that
they recognize.


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

Re: `await null` to stay in the same tick?

[Mark S. Miller]

On Sun, Feb 7, 2016 at 1:51 PM, Kris Kowal  wrote:

> Await yields to the event loop unconditionally. This is useful for
> spreading CPU-bound work across multiple events. You can explicitly await
> conditionally.
>
> ```
> if (guard) { await guard; }
> ```
>

Good example, thanks.



>
> On Sun, Feb 7, 2016 at 1:39 PM /#!/JoePea  wrote:
>
>> I'm not sure where's the best place to ask, but if I
>>
>> ```
>> await null
>> ```
>>
>> in an async function does that guarantee that the following code will
>> execute immediately (control flow will not go anywhere else)?
>>
>> - Joe
>> ___
>> 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
>
>


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

Re: monadic extension to do-notation

[Mark S. Miller]

Since the non-monadic way won, I don't know that it is worth arguing about
why. But it is ergonomic issues much deeper than convenience, and much more
important than compatibility with existing libraries -- even if those two
were adequate considerations by themselves.

The behavior of promises was inspired (via Joule channels) by the behavior
of logic variables in concurrent logic programming languages (FCP, Parlog,
GHC, Vulcan, Janus, ToonTalk). An unbound logic variable, like a variable
in logic, is a placeholder representing some ground value. Which ground
value is yet to be determined. An unbound logic variable is not itself a
ground value. Equating two logic variables means that the same ground
value, whatever that is, must be the solution to both of them. A concurrent
process waiting for a logic variable to be solved (fulfilled, bound) is not
triggered when it is merely equated to another logic variable.

The fact that the API is monad-like is an imperfect analogy I liked when it
happened. But I now regret it because it has caused endless confusion.
Likewise, I regret naming Ephemeron Tables "WeakMaps" (although anything is
better than "Ephemeron Tables") because people tried to read into it a
stronger analogy to weak references than was meant.

Having a promise become its value, as in E, would also only be possible if
they were non-monadic, because it would make them *more* like concurrent
logic programming logic variables.


To avoid a rehash of things we have already argued to exhaustion, I refer
everyone to previous discussions. Please only respond here if you have
something to say that has not already been said in those previous
discussions, or if you'd like to provide links to those previous
discussions.


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

Re: `await null` to stay in the same tick?

[Mark S. Miller]

On Sun, Feb 7, 2016 at 1:38 PM, /#!/JoePea  wrote:

> I'm not sure where's the best place to ask, but if I
>
> ```
> await null
> ```
>
> in an async function does that guarantee that the following code will
> execute immediately (control flow will not go anywhere else)?
>

Absolutely not. The continuation of an await always runs in another
turn/job, i.e., it always starts with an empty stack. between the awaiting
turn and the resumption at the await point, other jobs will interleave.



>
> - Joe
> ___
> 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: Extending spread operators to work with numbers

[Mark S. Miller]

The double dot ("..") is the traditional infix operator for
inclusive,inclusive integer ranges, going back to Pascal (the language, not
the mathematician). This has all the benefits you seek, including visual
clarity, without overloading the meaning of an existing token.

Whether double or triple dot, the problem is that programming patterns in
zero-index-origin languages want inclusive,exclusive ranges, which
naturally wants an asymmetric syntax to suggest the distinction. The
traditional math notation [0, 4) would be unambiguous, since of course we
never otherwise allow a closing paren to match an opening square bracket.
But, in a programming language context I find it too jarring.

E has ".." for inclusive,inclusive ranges, just like Pascal. E also has
"..!" for inclusive,exclusive ranges. The second operator was used much
more than the first. I don't think "..!" is great but I don't have anything
better to suggest.

Finally, we must ask whether this problem is worth solving with any syntax
or at all. We can already express these well enough with APIs. I think this
is one of those issues where the benefit of any new syntax here does not
pay for its complexity costs. See *The Tragedy of the Common Lisp, or, Why
Large Languages Explode* <
https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks
>.

See also .






On Fri, Jan 22, 2016 at 10:20 PM, John Gardner 
wrote:

> Probably a stupid idea, and I can see it already being brought up several
> times... but why not extend spread operators to work with numeric ranges?
>
> let a = [ 0 ... 3 ];
> // Expands to: [ 0, 1, 2, 3 ]
>
> This wouldn't be a groundbreaking feature, but it would allow better
> readability when plotting a range of values:
>
> let esVersions = [ 1 ... 5, 2015 ];
>
> It might also be used to extract a range of values:
>
> array[ 3 ... 6 ] = "ABCDEFGH";
> // [ "D", "E", "F", "G" ]
>
> Which I find far more readable than this:
>
> array[ , , , , 3, 4, 5, 6 ] = "ABCDEFGH";
>
> Since it would require two numbers to be explicitly supplied on each side,
> there's no risk of it being misinterpreted as an attempt to spread an
> array. Decimal components would be dropped:
>
> let a = [ 1 ... 3.9 ];
> // [ 1, 2, 3 ]
>
> This would complement Alican's suggested syntax for slicing an array of
> values, which modifies the original array.
>
> Thoughts? Just throwing crap out there.
>
>
> ___
> 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: Error stack strawman

[Mark S. Miller]

On Tue, Jan 19, 2016 at 6:35 PM, Jonathan Kingston <jonat...@jooped.co.uk>
wrote:

> Hi Mark,
>
> Sorry for the delay, thank you for that response it was very useful.
>
> Do you think it would make sense to open an API for Error stack that would
> be purely based upon user agent implementation? I'm not familiar with the
> internals of the traces but I have seen comments mentioning performance
> issues of complete parity across browsers due to their implementation
> differences.
>
> It would however still be useful to standardise: lineNumber, columnNumber
> and fileName.
>
> Perhaps that would be a simpler first step?
>


I think I was too discouraging in my earlier email. I actually meant to be
encouraging, though as always including weaknesses, cautions, requirements,
and caveats. I did not mean to scare anyone off. The downside of starting
with too small a part of the problem in isolation is that we are likely to
paint ourselves into a corner that we cannot fix later. I think the useful
thing to do is to standardize the extended Causeway stack trace format:


stacktrace ::= {calls: [frame*]};
frame ::= {name: functionName,
   source: source,
   span: [[startLine, startCol?], [endLine, endCol?]?]};
functionName ::= STRING;
startLine, startCol, endLine, endCol ::= INTEGER
source ::= STRING | frame;


that I showed in the previous message, as well as the APIs derived from <
https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js
>:


System.getStack(error) -> extended-causeway-stack | undefined

Reflect.stackString(extended-causeway-stack) -> stacktrace-string

System.getStackString = error =>
Reflect.stackString(System.getStack(error));


This places the privilege-bearing operations on System, as do other
proposals such as

System.global
System.defaultLoader
System.WeakRef

The only operation above that's fundamental is System.getStack, which,
given an error object encapsulating stack trace info, returns that stack
trace info in extended Causeway stacktrace format. debug.js shows how to
polyfill a decent approximation of this by scraping this info from the
divergent stack traces provided by today's major platforms.

Reflect.stackString renders an extended Causeway stack into a multiline
string, one per stackframe. It is fully non-privileged and polyfillable,
but I propose that the std provide it, in order to harmonize the current
crazy divergence of these formats between platforms. The one provided by
debug.js uses a vaguely v8-like concrete syntax, but that is merely a
starting point of discussion. Anything we can all agree on, that reliably
represents all the information from the extended Causeway stacktrace info,
would be great. We put stackString on Reflect because by itself it provides
no privilege.

System.getStackString is a mere convenience, composing together stackString
with getStack. I expect that most callers will just call this and ignore
the two lower level ones.


The hard part will be the escaping conventions needed in stackString, as
this goes beyond any precedent set by current platforms. The scraping that
the polyfill in debug.js does is grossly unreliable because it relies on
characters such as "(" and "@" to recognize what part of the existing
stackframe strings are filenames and function-or-method names. However,
these characters can be present in filenames, function names, and method
names, in which case this scraping will fail. Neither the current scraping
nor rendering code in debug.js does anything yet about this need to escape
significant characters.

Fortunately, once a reliable getStack is provided directly (instead of a
polyfill scraping non-escaped strings), consumers of the extended Causeway
format it returns will have reliable access to this structured data,
without any more need to do their own scraping.


The other hard but necessary part is that any such standard should be
coordinated -- ideally co-proposed -- with a proposed standard sourcemap <
https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?hl=en_US=1=1>,
which also needs to codify the meaning of at least filename and start/end
line/col.

A transpiler translating esN+1 to esN, producing an esN to esN+1 sourcemap,
should also provide to the esN+1 code a virtualized System.getStack and
System.getStackString that maps back through that sourcemap, so that the
esN+1 code sees stack trace info in terms of positions in its own esN+1
sources.



What all of this needs is someone who will take the lead writing a
proposal. It is important, but I do not have the time. If someone does
volunteer to take the lead, I will happily help, advise, ensure that all
requirements are met, and to champion this proposal on the committee.
Volunteers? Jonathan?




> Thanks
> Jonathan
>
> On Tue, Jan 12, 2016 at 6:32 A

Re: Annex B.3.3 substantially changes strict vs non-strict semantics

[Mark S. Miller]

On Tue, Jan 19, 2016 at 9:54 AM, Kevin Gibbons 
wrote:

> I'm not sure if this is well-known; it was certainly surprising to me.
>
> Consider the following program:
> `let func = () => 0;
>
> (function(){
>   {
> function func() {
>   return 1;
> }
>   }
>   return func();
> })();`
>
> The return value of the second function depends on whether this program is
> evaluated in strict mode or not. In strict mode (for example, as a Module),
> annex B.3.3 does not apply, so it returns 0. In sloppy mode (for example,
> as a Script), annex B.3.3 applies and it returns 1.
>
> You can see how the semantics change on the scope analysis demo we've just
> put up at
> shift-ast.org/scope.html?code=let%20func%20%3D%20()%20%3D%3E%200%3B%0A%0A(function()%7B%0A%20%20%7B%0A%20%20%20%20function%20func()%20%7B%0A%20%20%20%20%20%20return%201%3B%0A%20%20%20%20%7D%0A%20%20%7D%0A%20%20return%20func()%3B%0A%7D)()%3B#demo
> : as a Module the last `func` identifier refers to the outer `func`, and as
> a Script it refers to the inner one.
>
> Is it considered acceptable to have such large changes in strict vs
> non-strict semantics for unremarkable code?
>

That is the right question. The answer is yes. Sloppy mode exists only to
avoid breaking crappy legacy code, rather than to have any coherent
semantics. All new code should be strict, especially if you want it to work
or to have anyone understand it.




> If not, should B.3.3 be made to apply in strict mode?
>

ABSOLUTELY NOT!

(Or rather since the answer to your first question is yes, and you started
this one with "If not", the answer to this one is Mu ;).)



> ___
> 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: Error stack strawman

[Mark S. Miller]

On Mon, Jan 11, 2016 at 10:05 PM, Mark S. Miller <erig...@google.com> wrote:

> I am very interested. See the extended Causeway stack format in
> https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js
>

>From that page, the JSON Schema-ish in an ad-hoc notation:


stacktrace ::= {calls: [frame*]};
frame ::= {name: functionName,
   source: source,
   span: [[startLine, startCol?], [endLine, endCol?]?]};
functionName ::= STRING;
startLine, startCol, endLine, endCol ::= INTEGER
source ::= STRING | frame;




and the logic for scraping this information from the various stacktraces
> available on today's major platforms.
>
> The "extended" is about the multiple source position layers present when
> an "eval" in one place evals a string that, at some position in the string,
> does the call. Both FF and Chrome provide these nested positions, but
> differently.
>


The nesting is represented as the recursion through "frame" in the above
grammar.



>
> See the attachments for the information successfully scraped when visiting
> <https://rawgit.com/tvcutsem/es-lab/master/src/ses/contract.html> on each
> of the platforms, converted to Causeway extended stack trace format, and
> then re-rendered in a common textual format. As you see, even with all the
> work at canonicalizing this information, it still differs substantially
> between platforms.
>
>
>
>
> On Mon, Jan 11, 2016 at 7:10 PM, Jonathan Kingston <jonat...@jooped.co.uk>
> wrote:
>
>> Hey all,
>>
>> Does anyone know if there is an active interest in revisiting the
>> Error.stack strawman proposal?
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>>
>> I ask because CSP wanted an algorithm for getting the non standard
>> properties defined in Error objects:
>> https://w3c.github.io/webappsec-csp/#issue-f447ede5
>>
>> A simpler start may be possible in standardising just: lineNumber,
>> columnNumber and fileName
>>
>> Kind regards
>> Jonathan
>>
>


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

Re: Automatically giving symbols descriptions

[Mark S. Miller]

Yup. Consider

const foo = x();

where x happens to have the original value of Symbol.

Or

const foo = Symbol()

where Symbol is not bound to the original value of Symbol.






On Wed, Jan 6, 2016 at 4:44 PM, Jordan Harband  wrote:

> One difference is that functions are syntax - I don't believe `var foo =
> new Function();` will have a "name" property inferred. Because `Symbol` is
> an identifier that has to be looked up on the global object, might there be
> difficulty inferring what the name should be?
>
> Hopefully someone with more knowledge on the subject will confirm or
> correct my belief and my question :-)
>
> On Wed, Jan 6, 2016 at 4:07 PM, Axel Rauschmayer 
> wrote:
>
>> I love how ES6 automatically gives anonymous function definitions names
>> (via the variables they are assigned to etc.). Wouldn’t the same make sense
>> for symbols?
>>
>> Hypothetical example:
>>
>> ```js
>> const foo = Symbol();
>> console.log(Symbol('foo').toString()); // Symbol(foo)
>> ```
>>
>> --
>> Dr. Axel Rauschmayer
>> a...@rauschma.de
>> rauschma.de
>>
>> ___
>> 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
>
>


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

Re: [ small request - Javascript for javaing]

[Mark S. Miller]

This discussion does not belong on this list. Please take it elsewhere.


On Fri, Jan 1, 2016 at 10:42 AM, Sander Deryckere 
wrote:

> There are also a lot of coders working in JavaScript (see
> http://githut.info/), and JavaScript can also be used as a backend (see
> node.js). So why shouldn't Java become a subset of JavaScript?
>
> The ES design makes it very clear to not "break the web". That means that
> any code working today, should also work tomorrow. As such, removing
> prototypes (which are clearly more flexible than Java classes) or removing
> the generic number class (instead of int, float, double, ...) or removing
> other things Java doesn't have or Java does differently, isn't an option at
> all.
>
> Regards,
> Sander
>
> 2016-01-01 16:27 GMT+01:00 Bradley Meck :
>
>> JavaScript (an implementation of EcmaScript) has different semantics than
>> Java, it is not a subset and so it would break all sorts of backwards
>> compatibility (and lose some functionality) to act as if it is a subset of
>> Java.
>>
>> Basically, the languages are not directly related so it is not possible,
>> and mostly comes up from a naming confusion.
>>
>> On Fri, Jan 1, 2016 at 8:51 AM, Norbert Korodi 
>> wrote:
>>
>>> Hello Guys!
>>>
>>> I have always been a backend developer(Java, python, c++,c) and for a
>>> long time I haven't had the privilige to play with native javascript... so
>>> You can imagine when I was forced to code in javascript.
>>> After a couple of hours I had a really simple thought coming up from my
>>> spine: es6 is great and es7 will be great... but could you pls make it more
>>> like Java?
>>> I mean, it's great that es6 and 7 are getting closer and closer to
>>> normal languages then why not be simply Java?
>>> I and my team used GWT (when we were forced to code frontend) and other
>>> tools to avoid scripting but this time(standardization is somewhere close
>>> to the right track) You can actually make a difference and create a
>>> standard language that could be used everywhere. Not because there are
>>> already a lot of coders working in Java (and other high-level programming
>>> languages), just because it is a really pain in the a$$ to learn the not so
>>> important differences what es has compared to other languages...  and they
>>> give nothing in return.
>>>
>>> Okay, I know it is a scripting language so it can not be as verbose as
>>> Java... then just simply take stuff away from Java, and please don't add
>>> anything else for sugaring syntax.Please add syntax only for adding new
>>> features.
>>>
>>> As I reread my letter I have to admit that I might sound arrogant /
>>> offensive (and I am sorry for that , at least I am honest ) but I am really
>>> tired of reading about "new"-ish es features which are only new to this
>>> platform.
>>>
>>> Br,
>>> --
>>> Norbert Korodi
>>> Big data developer
>>>
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> 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: Aren’t membranes incompatible with private data via WeakMaps?

[Mark S. Miller]

Answering the question in the subject line, no. The key is the difference
between a standalone proxy and a membrane. With a membrane, the key is that
the:

* Countdown class
* Countdown.prototype
* Countdown.prototype.dec
* instances of the Countdown class
* the WeakMaps used by the Countdown class to store it private state
(_counter, _action)

are all on one side of the membrane. As is conventional, let's call that
the wet side, and the other side the dry side. Say both a Countdown
instance c and the WeakMap _action get passed through the membrane. Let's
name the corresponding dry proxies dry_c and dry_action. If, on the dry
side, someone does

dry_action.get(dry_c)

then this would trap on dry_action, passing dry_c back through the
membrane, resulting in the dry_action handler performing, on the wet side

const r = _action.get(c)

The wet result, r, of this invocation would get passed back through the
membrane, leading to the original expression returning dry_r.

Alternatively, let's say that someone on the dry side does

dry_c.dec()

This traps on dry_c, which looks up c's inherited "dec" method, passes that
back through the membrane, resulting in a dry_dec proxy for that method.
When that is invoked with dry_c as its this, it traps, invoking the wet dec
method with c as its this.

Conclusion: it all works fine.







On Sat, Nov 21, 2015 at 3:02 PM, Axel Rauschmayer 
wrote:

> Take, for example, the following class, which uses WeakMaps for its
> private data:
>
> ```js
> let _counter = new WeakMap();
> let _action = new WeakMap();
> class Countdown {
> constructor(counter, action) {
> _counter.set(this, counter);
> _action.set(this, action);
> }
> dec() {
> let counter = _counter.get(this);
> if (counter < 1) return;
> counter--;
> _counter.set(this, counter);
> if (counter === 0) {
> _action.get(this)();
> }
> }
> }
> ```
>
> If you wrap an instance of `Countdown` with a revocable Proxy (e.g. when
> it is returned by a method inside a membrane) that resets its private
> state, because its `this` changes.
>
> Right? If yes then I’d expect that to cause problems for code that uses
> WeakMaps for private data.
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
> ___
> 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: Is \u006eew a valid Identifier?

[Mark S. Miller]

On Mon, Nov 9, 2015 at 12:05 PM, Allen Wirfs-Brock 
wrote:

>
> On Nov 9, 2015, at 6:55 AM, Andreas Rossberg  wrote:
>
> Allen, what was the motivation for allowing random escapes in
> identifiers but not in keywords? AFAICS, it would be simpler and more
> consistent to allow them anywhere and render "escape normalisation" a
> uniform prepass before tokenisation. IIUC, that's what other languages
> do. The current ES rules are far from ideal, and require jumping
> through extra hoops, in particular, to handle context-dependent
> keywords like `yield`.
>
> /Andreas
>
>
> see:
>
> Here are some references:
>
> https://github.com/tc39/tc39-notes/blob/master/es6/2013-11/nov-20.md#42-clarification-of-the-interaction-of-unicode-escapes-and-identification-syntax
>
> https://bugs.ecmascript.org/show_bug.cgi?id=277
>
> https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour
>
> https://esdiscuss.org/topic/this-vs-thi-u0073
>
> there are many others, and also there were earlier TC39 meeting
> discussions that I didn’t find in my quick search.
>
> It’s a usability vs. implementor convience trade-off.  the TC39 was to go
> with usability (and in particular readability).
>

Yes.


>
> (Also, my recollection is that in some TC39 discussions (that I didn’t
> find in my search) there were security concerns raised WRT allowing unicode
> escapes in keywords. Probably concerns about code injection filters not
> recognizing escaped keywords)
>

Yes.

This was extensively discussed. Consensus was reached and declared. Other
tools were then built that rely on these decisions. Let us not change these.

TC39 decided this the right way. Even if they did not, the arguments
against do not outweigh the arguments for stability and against spec
thrashing this late in the game. It is way too late to revisit this if the
counter-arguments are only moderate implementor inconvenience.


>
> In ES6 (and I believe that Waldemar would claim in previous editions)
> unicode escapes cannot be handled with such a prepass. Essentially, escaped
> and non-escaped *IdentifierName* characters are only equated when doing
> identifier binding or property name lookups. It’s probably a misperception
> of the lexical grammar and static semantics that leads some implementors
> down the path of thinking that  such a preps is reasonable.
>
> Regarding `yield`, if it is written containing unicode escapes it is never
> a contextual keyword.
>
> BTW, personally I I would be just fine with never allowing unicode escapes
> within IdentiferName. But that would be a web breaking change.
>

Yes and yes.



>
> Allen
>
>
>
> ___
> 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: An update on Object.observe

[Mark S. Miller]

On Tue, Nov 3, 2015 at 11:27 AM, lycheeJS Engine <
lycheejs+esdisc...@gmail.com> wrote:

> I think we still need Object.observe as a specification to implement
> proper sandboxing of feature-detecting closures.
>

What do you mean by "sandbox"?

(I was not able to make sense of the rest of this message using my normal
understanding of "sandbox".)




>
> For example, in lycheeJS we have a sandboxing system that can inject
> definitions (and their variants) at runtime, replaces them intelligently at
> runtime. The definition closures have, for that purpose, all a supports()
> and exports() method. Both are using a referenced object that is sandboxed.
> The global property therefore is just a reference to a custom object, so
> that we can trace the properties, data types and causes of the errors.
>
> The implementation got stuck because of missing support for ES6 Proxies in
> the wild, but the idea is to use them to figure out if an implementation is
> doing something like window.addEventListener('asdasd') in the background
> and escalating an error up to a delegation handler that figures out what to
> do and what to inject to run it again. It is necessary to not only track
> properties and their data type; we need a feature to track if it was a
> function that threw an error or not.
>
>
> Easy use case:
>
> Imagine a var sandbox = { setTimeout: window.setTimeout }; This would
> throw a context error and we would need that information with proper
> description on what happened in order to isolate setTimeout and inject our
> In-JS Debugger there.
>
> We think Object.observe is an essential feature to have the simulation
> part of this, because we need desperately the capabilities to have a
> in-JS-written Debugger that can find such issues for our training of the
> Graph NN. The execution time aspect of this is a show-stopper if it would
> not be possible.
>
>
> Advanced use case:
>
> We don't use a RendererFactory that is executed once a new Renderer is
> instantiated, we have multiple Renderer implementations for multiple
> platforms available. Each Renderer has its own platform
> (fertilizer)-specific implementation. Those implementations are called
> alternative Definitions.
>
> Each definition has a supports() method that is called once the runtime
> error-determination algorithm tries to inject a new instance of the
> Renderer somewhere or de-reference an old, now slowly running Renderer.
>
> The supports() method can have all kinds of ES5 / ES6 code in order for
> the determination; it is the essential point to determine the capabilities
> of the runtime - at the given execution time, not compile time.
>
> If, for example, the canvas binding in the runtime on Android has problems
> now and throws some errors; there might be a fallback implementation
> available (SDL / OpenGL / GLUT / whatever) and then the Environment sandbox
> updates its dependencies accordingly and tries out "if one of the fallback
> implementation would be supported right now".
>
> Therefore, we think that Object.observe is quite necessary for our
> live-update-and-inject algorithms to determine compatibility problems for
> out-rolled updates _before_ they are applied to have proper feedback for
> our NN on the other peer-side of things.
>
>
> PS:
>
> In case anyone is interested, the problem for which we would need
> Object.observe and ES6 Proxies available, is here:
> https://github.com/Artificial-Engineering/lycheeJS/blob/development-0.9/lychee/source/core/Environment.js#L112
>
>
> But I could be totally all-wrong with this. If the described features are
> possible to be implemented with ES6 Proxies alone, I'm fine with
> deprecating Object.observe and with switching to ES6 Proxies. But the
> features are essential for us to choose ES6/ES7 as a language and I hope
> that others have similar feature requests.
>
> ~Chris
>
> ___
> 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: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

[Mark S. Miller]

On Mon, Nov 2, 2015 at 6:02 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Not sure I've got your idea right but I think the main point of
> WeakAnything is to forget about GC and have them **not** observable "at all
> costs"
>


That is true of WeakMap and WeakSet. But there is a separate WeakReference
proposal in which GC would be observable.

The WeakReference proposal will once again be visible if wiki.ecmascript.org
ever comes online again. What is the prognosis for that? There are many
strong references into that wiki, so it should not have been collected.




>  unless I've misunderstood the intent itself, Object.observe as it has
> been proposed wouldn't help much anyway.
>
> Regards
>
> On Mon, Nov 2, 2015 at 10:34 PM, Coroutines  wrote:
>
>> I was referred to es-discuss after filing a feature request here to
>> support observing WeakMaps and WeakSets.  (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1206584 )
>>
>> I was linked this message:
>> https://mail.mozilla.org/pipermail/es-discuss/2015-November/044684.html
>>
>> Please save Object.observe().
>>
>> When I read that above posting it sounds like O.o() is to be removed
>> because it has not been popularly used.  It is proposed for ES7 - it's
>> not even part of an accepted standard yet.  I think it's strange to
>> remove something because it's not used much... because it's
>> experimental.  Who would depend on something non-standard?  Sure
>> there's a polyfill but it polls an object for changes with timers -
>> this sounds ridiculously inefficient.  If it doesn't get accepted
>> there will be no way to watch changes as they happen, instead of after
>> the fact.
>>
>> I come from Lua.  In Lua we make proxy objects with metamethods.  You
>> create an empty table/object and define a metatable with a __index and
>> __newindex to catch accesses and changes when a key/property doesn't
>> exist.  I would primarily use this in sandboxes where I wanted to
>> track the exact series of operations a user was performing to modify
>> their environment (the one I'd stuck them in).  The important part to
>> remember is that I didn't know what properties of which objects they
>> would be accessing.  I couldn't just define a static list of getters
>> and setters and hope they make use of my limited, catching interface.
>> I think Object.observe() is very important for situations where you
>> want to watch all changes, because you don't know which properties
>> will be used.
>>
>> I have a further proposal:  I wish it were possible to watch changes
>> on WeakMaps and WeakSets.
>>
>> In Lua you can have weak references by setting the __mode = 'kv' (k
>> for key, v for value) in the object's metatable.  The only way I could
>> get weak references in JS was with WeakMaps and WeakSets.  Lua also
>> lets you set a __gc in the metatable to handle when a pair is
>> collected by the GC.  I wanted the ability to "see" when memoized
>> function calls are forgotten, but I can't do that with just
>> Object.observe() - as you can't observe a WeakSet or WeakMap.  I'd
>> love for this to be possible.
>>
>> For debugging reasons it would be excellent to be able to watch when
>> things get collected (through weak references).  Finalizers in general
>> would be nice.  I mean in the sense that I want to do something
>> independent of the object being collected, not that I need to destroy
>> the object in a special way before collection.  I feel like there's a
>> vague difference between finalizer and destructor.
>>
>> Please save Object.observe(), make WeakMap/WeakSet observable, and
>> save the whales too or something.
>>
>> Toodles ~
>> ___
>> 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
>
>


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

Re: Calling toString on function proxy throws TypeError exception

[Mark S. Miller]

Notice that whatever we decide on the issue, functionProxy.toString() will
work regardless, since you'd be getting the toString method itself through
the membrane. functionProxy.toString will be a function proxy for the
target.toString method. The invocation on the toString proxy with
functionProxy as this will be translated by the membrane back into an
invocation of target.toString with target as this.

The issue we're debating is only relevant on an edge case -- when
explicitly invoking F.p.toString.call(functionProxy).



On Tue, Oct 27, 2015 at 10:04 AM, Claude Pache 
wrote:

>
> > Le 27 oct. 2015 à 14:14, Boris Zbarsky  a écrit :
> >
> > On 10/27/15 4:35 AM, Claude Pache wrote:
> >> it is that, for any callable object, it will return a string and not
> throw, because it was so since the dawn of JS.
> >
> > It's totally false for random "host objects" with a [[Call]] in ES5, per
> spec and in at least some implementations.  As you can tell in Firefox for
> example:
> >
> >  Function.prototype.toString.call(document.createElement("object"))
> >
> > (though it does not throw for document.all in Firefox, for interesting
> implementation reasons).
> >
> >> That function will work (in the sense of: will return an answer; I'm
> not judging the quality of that answer) with anything reasonable fed to it
> (where "reasonable" excludes things like `(class { static toString() {
> throw "pwnd!" }})`).
> >
> > Won't work with an HTMLObjectElement in at least some browsers.  How
> "reasonable" that is, who knows.
> >
> > -Boris
>
> You're right. But since `document.createElement("object")` does not
> inherit from `Function.prototype`, the code (`f.toString()`) accidentally
> works after all.
>
> (I've tried not to be too smart in my example by writing `f.toString()`
> instead of `Function.prototype.toString.call(f)`. Maybe I should have been
> even less smart by defining an instance method on `Function.prototype`
> instead of a static method on `Function`...)
>
> —Claude
> ___
> 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: Duplicate super call behaviour

[Mark S. Miller]

On Sat, Oct 24, 2015 at 8:00 PM, Sebastian McKenzie 
wrote:

> I was recently reading the specification on the behaviour of duplicate
> super() calls in derived constructors. Reading the grammar the following is
> valid:
>
> ```
> class Foo {
>   constructor() {
> console.log("foobar);
>   }
> }
>
> class Bar extends Foo {
>   constructor() {
> super();
> super();
>   }
> }
>
> new Bar;
> ```
>
> However my reading of the runtime semantics, it will actually execute the
> constructor body *twice. *And so "foo" will be printed two times.
>
> This is because the only thing I've found stopping duplicate super calls
> is step 10 of SuperCall in 12.3.5.1
> 
> :
>
>1. Let newTarget be GetNewTarget().
>2. If newTarget is undefined, throw a ReferenceError exception.
>3. Let func be GetSuperConstructor().
>4. ReturnIfAbrupt(func).
>5. Let argList be ArgumentListEvaluation of Arguments.
>6. ReturnIfAbrupt(argList).
>7. Let result be Construct(func, argList, newTarget).
>8. ReturnIfAbrupt(result).
>9. Let thisER be GetThisEnvironment( ).
>10. Return thisER.BindThisValue(result).
>
> Since BindThisValue will throw a ReferenceError if `this` has already been
> initialised:
>
>
>1. Let envRec be the function Environment Record for which the method
>was invoked.
>2. Assert: envRec.[[thisBindingStatus]] is not "lexical".
>3. If envRec.[[thisBindingStatus]] is "initialized", throw a
>ReferenceError exception.
>
> But this check is performed at step 10 whereas the super constructor is
> actually evaluated at step 7.
>
> Is my reading correct? If so, to me this behaviour seems quite unexpected.
>

I'm surprised. Good catch! Frankly, this case had never occurred to me and
I do not remember discussing it. I would certainly prefer that it be an
error without constructing twice.




>
> Any insight (or correction) is extremely appreciated, thank you!
>
> ___
> 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: Calling toString on function proxy throws TypeError exception

[Mark S. Miller]

I know that's true in general. But we made a few exceptions, especially for
functions and arrays. I thought F.p.toString was one, but maybe not. I just
don't remember.


On Thu, Oct 22, 2015 at 2:36 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>
wrote:

>
> On Oct 22, 2015, at 11:23 AM, Mark S. Miller <erig...@google.com> wrote:
>
> Tom, this doesn't sound right to me. Didn't we intend 
> Function.prototype.toString
> to be transparent thru function proxies?
>
> cc'ing Allen and Brian
>
>
> There is nothing unique to `toString` going on there.  This is just the
> problem that the default proxy handlers are not transparent across method
> calls in that they pass the proxy object rather than the target object as
> the `this` value to function that they ultimately invoke.  If that method
> needs to access internal slots of its `this` value or has `this` identify
> dependencies they don’t work.  It turns out that most Function.prototype
> methods have such dependencies.
>
> Allen
>



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

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

[Mark S. Miller]

On Thu, Oct 22, 2015 at 8:54 PM, Caitlin Potter <caitpotte...@gmail.com>
wrote:

> > JavaScript does not have string interpolation. It has arbitrary value
> interpolation.
>
> Disagree. `foo ${bar} baz` is string interpolation. `${bar}` becomes
> `ToString(bar)`. Tagged templates were an addition
>

That is not the history.



> that weren’t really needed.
>

Disagree. They were and are the main motivation. The fact that the unmarked
case does string interpolation is just icing on the cake.




> Since they exist, great, people can come up with some clever uses for
> them. But they’re hardly the common use case, which is definitely string
> interpolation
>
> On Oct 22, 2015, at 8:43 PM, Mark S. Miller <erig...@google.com> wrote:
>
> JavaScript does not have string interpolation. It has arbitrary value
> interpolation.
>
>
> On Thu, Oct 22, 2015 at 8:34 PM, Caitlin Potter <caitpotte...@gmail.com>
> wrote:
>
>> Okay, but usability wise, this kind of sucks. There's a reason it's not
>> what people expect, and why other languages with string interpolation
>> behave differently.
>>
>> On Oct 22, 2015, at 8:24 PM, Allen Wirfs-Brock <
>> allen.wirfsbr...@gmail.com> wrote:
>>
>>
>> On Oct 22, 2015, at 4:55 PM, Mark Miller <erig...@gmail.com> wrote:
>>
>>
>>
>> On Thu, Oct 22, 2015 at 7:20 PM, Caitlin Potter <caitpotte...@gmail.com>
>> wrote:
>>
>>> Cute, but nobody is realistically going to do that.
>>>
>>
>> Since `${}` is a static error, what do you realistically think people
>> will do? Especially if they meant `${''}`, how do you expect them to react
>> to the static error?
>>
>>
>> Just like they do if they have a line of code that reads:
>>
>> ```js
>> str = ;
>> ```
>>
>> when they meant
>>
>> ```js
>> str = ‘’;
>> ```
>>
>> It’s just a syntax error.  I probably have syntax errors in 50% of the
>> lines that I initially type.  I parse, and then fix.
>>
>> Allen
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
>
>


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

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

[Mark S. Miller]

JavaScript does not have string interpolation. It has arbitrary value
interpolation.


On Thu, Oct 22, 2015 at 8:34 PM, Caitlin Potter 
wrote:

> Okay, but usability wise, this kind of sucks. There's a reason it's not
> what people expect, and why other languages with string interpolation
> behave differently.
>
> On Oct 22, 2015, at 8:24 PM, Allen Wirfs-Brock 
> wrote:
>
>
> On Oct 22, 2015, at 4:55 PM, Mark Miller  wrote:
>
>
>
> On Thu, Oct 22, 2015 at 7:20 PM, Caitlin Potter 
> wrote:
>
>> Cute, but nobody is realistically going to do that.
>>
>
> Since `${}` is a static error, what do you realistically think people will
> do? Especially if they meant `${''}`, how do you expect them to react to
> the static error?
>
>
> Just like they do if they have a line of code that reads:
>
> ```js
> str = ;
> ```
>
> when they meant
>
> ```js
> str = ‘’;
> ```
>
> It’s just a syntax error.  I probably have syntax errors in 50% of the
> lines that I initially type.  I parse, and then fix.
>
> Allen
>
>


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

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

[Mark S. Miller]

On Thu, Oct 22, 2015 at 8:58 PM, Caitlin Potter <caitpotte...@gmail.com>
wrote:

> The history does not matter.
>

Excuse me. "Tagged templates were an addition" sounded like a claim about
history.



> It doesn’t make a difference what someone presented or argued for to a
> room full of people. What matters is how they’re actually used in practice.
>
> There are some libraries which do some clever things with them. They are
> not common, there are not a lot of them, and they don’t necessarily perform
> their tasks easier than a simple recursive descent parser would.
>
> The main use is absolutely string interpolation.
>
> On Oct 22, 2015, at 8:56 PM, Mark S. Miller <erig...@google.com> wrote:
>
>
>
> On Thu, Oct 22, 2015 at 8:54 PM, Caitlin Potter <caitpotte...@gmail.com>
> wrote:
>
>> > JavaScript does not have string interpolation. It has arbitrary value
>> interpolation.
>>
>> Disagree. `foo ${bar} baz` is string interpolation. `${bar}` becomes
>> `ToString(bar)`. Tagged templates were an addition
>>
>
> That is not the history.
>
>
>
>> that weren’t really needed.
>>
>
> Disagree. They were and are the main motivation. The fact that the
> unmarked case does string interpolation is just icing on the cake.
>
>
>
>
>> Since they exist, great, people can come up with some clever uses for
>> them. But they’re hardly the common use case, which is definitely string
>> interpolation
>>
>> On Oct 22, 2015, at 8:43 PM, Mark S. Miller <erig...@google.com> wrote:
>>
>> JavaScript does not have string interpolation. It has arbitrary value
>> interpolation.
>>
>>
>> On Thu, Oct 22, 2015 at 8:34 PM, Caitlin Potter <caitpotte...@gmail.com>
>> wrote:
>>
>>> Okay, but usability wise, this kind of sucks. There's a reason it's not
>>> what people expect, and why other languages with string interpolation
>>> behave differently.
>>>
>>> On Oct 22, 2015, at 8:24 PM, Allen Wirfs-Brock <
>>> allen.wirfsbr...@gmail.com> wrote:
>>>
>>>
>>> On Oct 22, 2015, at 4:55 PM, Mark Miller <erig...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Thu, Oct 22, 2015 at 7:20 PM, Caitlin Potter <caitpotte...@gmail.com>
>>>  wrote:
>>>
>>>> Cute, but nobody is realistically going to do that.
>>>>
>>>
>>> Since `${}` is a static error, what do you realistically think people
>>> will do? Especially if they meant `${''}`, how do you expect them to react
>>> to the static error?
>>>
>>>
>>> Just like they do if they have a line of code that reads:
>>>
>>> ```js
>>> str = ;
>>> ```
>>>
>>> when they meant
>>>
>>> ```js
>>> str = ‘’;
>>> ```
>>>
>>> It’s just a syntax error.  I probably have syntax errors in 50% of the
>>> lines that I initially type.  I parse, and then fix.
>>>
>>> Allen
>>>
>>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
>
>


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

wiki.ecmascript.org

[Mark S. Miller]

What's up, er down, with wiki.ecmascript.org ?

http://downforeveryoneorjustme.com/wiki.ecmascript.org

Still down. ETA?

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

Is anyone able to reach wiki.ecmascript.org ?

[Mark S. Miller]

Seems to be down. Not answering pings.

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

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

[Mark S. Miller]

On Mon, Sep 28, 2015 at 1:20 PM, Geoffrey Garen <gga...@apple.com> wrote:

> I don’t object to the idea of levels of severity when throwing an
> exception, but I don’t think it will be sufficient to defend against
> attacks either.
>

Agreed that if you're throwing, then you are vulnerable to attacks. The
levels-of-severity idea is that THROW is the least severe and all more
severe levels do not throw. Let's examine in terms of Filip's suggestion
that we only have THROW and ABORT_EVENT_LOOP. If anyone participating in
the event loop wants ABORT_EVENT_LOOP then that's what we have. Only
ABORT_EVENT_LOOP
claims to provide any defense.




>
> An attacker that wants to infer information about the target VM or stop
> execution in some target code at a point of inconsistent state will still
> be able to do so even if the attacker can’t immediately catch the
> exception. The attacker can pre-arrange a user event handler, timer,
> animation callback, worker, network response, onerror callback, etc. in
> order to resume execution after the attack has completed.
>
> To some extent, this problem may be unsolvable.
>
> To the extent that this problem can be solved, I think the VM would need
> to halt all further execution within the webpage/world/realm after an
> out-of-stack or out-of-heap exception.
>

Yes, that's what ABORT_EVENT_LOOP must do.



>
> Halting execution is draconian, but its downsides are limited by the fact
> that the webpage was probably not going to function correctly after the
> exception anyway. The main downside I see to halting all execution is that
> client-side error analytics will not be able to report on out-of-heap and
> out-of-stack errors.
>

That's a very good point. In systems with this kind of architecture,
collaborators outside the terminated unit receive some signal indicating
what allegedly went wrong inside the terminated unit. E leverages its
promise-based communications model for this purpose. The action of aborting
a vat carries a simple data string, not a general object. The vat itself is
preemptively aborted without any further computation within the condemned
vat. All remote promises into the terminated vat transition into (in JS
terminology) rejected promises, where the rejection reason is that string
-- the alleged reason for termination.

This does provide a so-called "termination side channel" to these
collaborators. But our primary concern is integrity. On confidentiality,
neither E nor JS is in a good position to make strong claims about outward
signaling[*] on non-overt (side or covert) channels, and we should not try.
This side channel is low bandwidth, and only inter-vat collaborators can
read it. Those objects at the boundaries between vats already have access
to other non-pluggable non-overt channels.

[*] Two caveats:
1) As Waldemar points out, we must be careful about high bandwidth non-over
channels.
2) E does make strong claims about limiting the listening to non-overt
channels, by use of "fail-stop loggable non-determinism". I am becoming
hopeful that JS may as well. But this is a topic for another day.



>
> Geoff
>
> On Sep 27, 2015, at 10:09 AM, Mark S. Miller <erig...@google.com> wrote:
>
>
>
> On Sun, Sep 27, 2015 at 9:57 AM, Filip Pizlo <fpi...@apple.com> wrote:
>
>> Hi Mark,
>>
>> It seems that most of the benefit for fail-faster behavior for VM errors
>> is security.
>>
>> To what extent do you think the security problem could be addressed by
>> VMs simply randomizing the point at which stack overflow or OOM happens?  I
>> think this would be more desirable, since it requires no language changes.
>>
>
> It would help, but not enough. The defender would have some window of
> memory budget within which it randomizes. The attacker could repeatedly
> probe in order to get a statistical sense of the range and shape of that
> window. Then, say, the attacker could repeatedly allocate until it got,
> say, into the 80 percentile of that window without failing, and then call
> the defender. If the defender then does a delicate operation that happens
> to allocate more that the remaining 20 percentile of that window, then the
> attacker has broken the defender's integrity in a way the attacker may be
> able to exploit.
>
> Nevertheless, it does help a lot. It would be a nice speed bump until a
> real defense can be designed, agreed on, and put in place.
>
> We also need real experiments to determine how hard these attacks actually
> are to mount. And once successful, how hard they are to commodify, so that
> other less skilled attackers can reuse these attacks. As always, if you do
> this as a white hat, please engage in responsible disclosure for a
> reasonable finite period before making a successful attack

Re: Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

[Mark S. Miller]

On Sun, Sep 27, 2015 at 9:57 AM, Filip Pizlo <fpi...@apple.com> wrote:

> Hi Mark,
>
> It seems that most of the benefit for fail-faster behavior for VM errors
> is security.
>
> To what extent do you think the security problem could be addressed by VMs
> simply randomizing the point at which stack overflow or OOM happens?  I
> think this would be more desirable, since it requires no language changes.
>

It would help, but not enough. The defender would have some window of
memory budget within which it randomizes. The attacker could repeatedly
probe in order to get a statistical sense of the range and shape of that
window. Then, say, the attacker could repeatedly allocate until it got,
say, into the 80 percentile of that window without failing, and then call
the defender. If the defender then does a delicate operation that happens
to allocate more that the remaining 20 percentile of that window, then the
attacker has broken the defender's integrity in a way the attacker may be
able to exploit.

Nevertheless, it does help a lot. It would be a nice speed bump until a
real defense can be designed, agreed on, and put in place.

We also need real experiments to determine how hard these attacks actually
are to mount. And once successful, how hard they are to commodify, so that
other less skilled attackers can reuse these attacks. As always, if you do
this as a white hat, please engage in responsible disclosure for a
reasonable finite period before making a successful attack public. Thanks.




>
> More comments inline...
>
> On Sep 27, 2015, at 8:46 AM, Mark S. Miller <erig...@google.com> wrote:
>
> [-whatwg, +es-discuss]
> Reposting to es-discuss, as Anne's more general question is best seen as a
> JS issue rather than a browser specific one
>
>
>
> On Sun, Sep 27, 2015 at 8:30 AM, Mark S. Miller <erig...@google.com>
> wrote:
>
>> On Sat, Sep 26, 2015 at 7:34 AM, Anne van Kesteren <ann...@annevk.nl>
>> wrote:
>>
>>> On Fri, Sep 25, 2015 at 4:48 PM, Justin Novosad <ju...@google.com>
>>> wrote:
>>> > Currently there is no spec'ed behavior for handling out-of memory
>>> issues
>>> > for the specific case of attempting to allocate a large buffer through
>>> > image data APIs.
>>>
>>> Actually, there is no specified behavior for out-of-memory behavior,
>>> period. This is a problem that starts with the ECMAScript standard and
>>> everything that builds upon it.
>>>
>>> I have seen Mark Miller discuss some of the issues surrounding this
>>> and perhaps even the necessity to eventually define it, but so far
>>> this has not happened. Not sure if the full story is documented
>>> somewhere. Mark?
>>>
>>>
>>> https://esdiscuss.org/topic/using-max-stack-limit-to-determine-current-js-engine-and-revision#content-7
>>> indicates there may be security issues with throwing out-of-memory
>>> exceptions.
>>
>>
>> Well, the full story is never documented ;). However, that post and the
>> links from there:
>>
>> http://www.eros-os.org/pipermail/e-lang/2007-January/011817.html
>> https://github.com/google/caja/issues/460
>>
>> are a good start. The security issue is serious and needs to be fixed. It
>> cannot practically be fixed by libraries without additional help by the
>> platform. The problem is that
>>
>> * In a language that implicitly allocates everywhere, like
>> JavaScript, Java, and many other oo languages, it is impossible to prevent
>> a code from causing OOM
>> * If OOM is thrown (see the first link for Java/Joe-E issues), and
>> the language has try/finally, it is impossible to prevent the OOM being
>> masked.
>> * In such languages, it is impossible to program defensively against
>> the pervasive possibility of OOM -- if execution simply resumes in that
>> context as if nothing bad happened.
>>
>> In Joe-E we took the painful step of outlawing the Java try/finally from
>> the Joe-E subset of Java for this reason. There was no other reason to
>> outlaw try/finally as there's nothing else inherently unsafe about it. We
>> really tried to find another solution but under our constraints -- no
>> rewriting of the Java nor change to the JVM -- we could not.
>>
>> By preventing Joe-E code from catching VirtualMachineErrors and from
>> doing a try/finally, the Joe-E code was preemptively terminated immediately
>> on occurrence of a VirtualMachineError. Only the spawner of the Joe-E
>> computation could react to this termination of the computation it spawned.
>>
>> This mirrors one of the many thing that 

Death Before Confusion (was: [whatwg] Handling out of memory issues with getImageData/createImageData)

[Mark S. Miller]

[-whatwg, +es-discuss]
Reposting to es-discuss, as Anne's more general question is best seen as a
JS issue rather than a browser specific one



On Sun, Sep 27, 2015 at 8:30 AM, Mark S. Miller <erig...@google.com> wrote:

> On Sat, Sep 26, 2015 at 7:34 AM, Anne van Kesteren <ann...@annevk.nl>
> wrote:
>
>> On Fri, Sep 25, 2015 at 4:48 PM, Justin Novosad <ju...@google.com> wrote:
>> > Currently there is no spec'ed behavior for handling out-of memory issues
>> > for the specific case of attempting to allocate a large buffer through
>> > image data APIs.
>>
>> Actually, there is no specified behavior for out-of-memory behavior,
>> period. This is a problem that starts with the ECMAScript standard and
>> everything that builds upon it.
>>
>> I have seen Mark Miller discuss some of the issues surrounding this
>> and perhaps even the necessity to eventually define it, but so far
>> this has not happened. Not sure if the full story is documented
>> somewhere. Mark?
>>
>>
>> https://esdiscuss.org/topic/using-max-stack-limit-to-determine-current-js-engine-and-revision#content-7
>> indicates there may be security issues with throwing out-of-memory
>> exceptions.
>
>
> Well, the full story is never documented ;). However, that post and the
> links from there:
>
> http://www.eros-os.org/pipermail/e-lang/2007-January/011817.html
> https://github.com/google/caja/issues/460
>
> are a good start. The security issue is serious and needs to be fixed. It
> cannot practically be fixed by libraries without additional help by the
> platform. The problem is that
>
> * In a language that implicitly allocates everywhere, like JavaScript,
> Java, and many other oo languages, it is impossible to prevent a code from
> causing OOM
> * If OOM is thrown (see the first link for Java/Joe-E issues), and the
> language has try/finally, it is impossible to prevent the OOM being masked.
> * In such languages, it is impossible to program defensively against
> the pervasive possibility of OOM -- if execution simply resumes in that
> context as if nothing bad happened.
>
> In Joe-E we took the painful step of outlawing the Java try/finally from
> the Joe-E subset of Java for this reason. There was no other reason to
> outlaw try/finally as there's nothing else inherently unsafe about it. We
> really tried to find another solution but under our constraints -- no
> rewriting of the Java nor change to the JVM -- we could not.
>
> By preventing Joe-E code from catching VirtualMachineErrors and from doing
> a try/finally, the Joe-E code was preemptively terminated immediately on
> occurrence of a VirtualMachineError. Only the spawner of the Joe-E
> computation could react to this termination of the computation it spawned.
>
> This mirrors one of the many thing that Erlang gets right. When a program
> is confused, that program is the last one you want to ask to recover from
> the confusion, since it is already impaired by its own confusion. If you
> don't know what is still true, you are unlikely to engage in repair actions
> correctly. Better to preemptively terminate some large unit containing the
> confusion and recover by
> * restarting from earlier known good state, or
> * if this is not yet feasible, propagating the termination to a yet
> larger granularity of computation.
>
> This is the "fail stop" philosophy of "Death Before Confusion". The
> contrasting philosophy appropriate for some computation is "best efforts".
> Some JavaScript code is best served by one and some by the other. Security
> enforcing code must maintain its own integrity at the price of termination
> (and restart from some coarser grain). Web pages using JavaScript only to
> spice up the user experience are often best served by best efforts. Erlang
> itself is an interesting case study, as its original motivating problem --
> telephone switches -- places a higher priority on uptime than on integrity.
> Nevertheless, both Erlang and the Tandem non-stop architecture found that
> uptime in the large is best served by fail-stop in the small combined with
> coarser-grain recovery logic.
>
> Because JavaScript comes from such a long legacy of de facto best efforts
> architecture, I think a direct du jure shift to fail-stop is unlikely.
> Instead, what we need is a trap-handling mechanism (Erlang "supervisor".
> KeyKOS "keeper"), where different policies can be expressed by user-defined
> trap handlers. When multiple policies co-exist, the platform obeys the
> more severe policies. For concreteness, I'll make here a first sketch:
>
> On OOM, the platform first scans the stack to enume

Re: Exponentiation operator precedence

[Mark S. Miller]

I like #4. Normally in a situation like this I would still argue for #1. #4
is a complicated special case that breaks the normal pattern of operator
precedence elsewhere in the language. The need for ** is not great enough
to justify introducing a new special case for users to learn.

However, in this case, #4 is only technically complicated -- for those
writing or reading spec docs like us. For normal users, the only complexity
is a rarely encountered surprising static error. With a decent (and easy to
generate) error message, these users will immediately know what they need
to do to repair their program.

Significant programs are read much more than they are written. Both #2 and
#3 will lead many readers to misread programs. For programs that are not
rejected, #4 is no more confusing than #1. Altogether, for readers, #4 is
better than #1 because ** is more readable than Pow.

+1 on #4.



On Thu, Sep 24, 2015 at 7:55 AM, Brendan Eich  wrote:

> Here's a nicely formatted jsbin version of my message:
>
> http://jsbin.com/bihilaveda
>
> Sorry about the mess, mail user agents (at least Postbox) and archive
> software do not like explicit indentation.
>
> /be
>
>
>
>


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

Re: Exponentiation operator precedence

[Mark S. Miller]

I won't try to guess where the rendering problem is, but see the attached
screenshots. This is how I'm seeing your page on my Chrome and Firefox.

On Thu, Sep 24, 2015 at 8:19 AM, Brendan Eich  wrote:

> Even nicer:
>
> http://jsbin.com/baquqokujo
>
> I hate email.
>
> /be
>
>
> Brendan Eich wrote:
>
>> Here's a nicely formatted jsbin version of my message:
>>
>> http://jsbin.com/bihilaveda
>>
>> Sorry about the mess, mail user agents (at least Postbox) and archive
>> software do not like explicit indentation.
>>
>> /be
>>
>
>


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

Re: Exponentiation operator precedence

[Mark S. Miller]

On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache 
wrote:

>
> Le 24 sept. 2015 à 16:11, Brendan Eich  a écrit :
>
> And indeed apart from dot (a special form whose right operand must be a
> lexical identifier-name) and square brackets (which isn't an infix operator
> per se), unary operators bind tighter than binary in JS as in C and other
> C-derived languages.
>
>
> I just wonder why it is important that unary binds tighter? For instance,
> before I carefully studied the issue of this thread, I have never expected
> that unary minus binds tighter than binary
>


Before Jason pointed out the discrepancy:
  * all of us on the committee who were engaged with the proposal
  * including myself,
  * all those who reviewed the proposal,
  * and all those who implemented the proposal
had the opposite naive expectation. That's the point. In the absence of
learning about this case specifically, many people will be unpleasantly
surprised by #2, and many by #3. Therefore #4 wins. (Actually, it just won
;).)





> multiplication operator in expressions like `-2*x` (although it does not
> matter in that case).
>
>
> without having to parenthesize unduly, but one cannot write
>
> let z = -x ** y;
>
> The user is forced by an early error to write either (-x)**y or -(x**y).
>
>
> In traditional math notation, when you mean `(-x)**n`, you write (-x)ⁿ
> with mandatory parentheses, so I don’t expect that many people will be
> tempted to miswrite it `-x ** n`.
>
> Making the parentheses mandatory here will be somewhat annoying in
> perfectly reasonable expressions, where you usually don’t use parentheses
> in real math notation., like:
> ```
> let s2 =  - x**2 - y**2 - z**2 +  t**2
> ```
>
> —Claude
>
>
>


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

Re: Template strings as a template language.

[Mark S. Miller]

On Sun, Sep 13, 2015 at 7:08 AM, Thomas <thomasjamesfos...@bigpond.com>
wrote:

> What I've been doing:
>
> export const template = ({title, content}) => `template string for
> ${title}`;
>
> Or variations thereof. I then import that module wherever I need to use
> the template and call it as a function.
>

If you were not to call it as a function, where would it get its bindings
for title and content?



>
> Using eval and having the template string as a normal string (so, read the
> template from file as a string, wrap it with back ticks, and then pass it
> to eval) at the moment is risky since it's possible for input to
> prematurely end the template string and do nasty stuff*. Ideally there
> would be a variant of eval where the string to be evaluated must be a
> template string expression.
>
> Thomas
>
> * I'm aware that someone could still put something inside a template
> string and do nasty stuff, but I'm not sure if that's a easily solved
> problem.
>
> On 13 Sep 2015, at 10:08 PM, Mark S. Miller <erig...@google.com> wrote:
>
> On Sun, Sep 13, 2015 at 2:42 AM, Thomas <thomasjamesfos...@bigpond.com>
> wrote:
>
>> I'd really like to use Template strings as a templating language, but
>> unless I include a lot of boilerplate code (export a template string
>> wrapped in a function from a file)
>
>
> Hi Thomas, could you give a concrete example of the boilerplate you have
> in mind and what it accomplishes?
>
>
>
>> or use eval after loading a file as a string it's pretty much impossible.
>>
>> Is there a simpler way to be doing this? Or any plans for a type of eval
>> that only executes it's argument as a template string?
>
>
> I am unaware of any such plans. Could you give an example of what it looks
> like and what it would accomplish? Thanks.
>
>
> --
> Cheers,
> --MarkM
>
>


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

Re: Template strings as a template language.

[Mark S. Miller]

On Sun, Sep 13, 2015 at 2:42 AM, Thomas 
wrote:

> I'd really like to use Template strings as a templating language, but
> unless I include a lot of boilerplate code (export a template string
> wrapped in a function from a file)


Hi Thomas, could you give a concrete example of the boilerplate you have in
mind and what it accomplishes?



> or use eval after loading a file as a string it's pretty much impossible.
>
> Is there a simpler way to be doing this? Or any plans for a type of eval
> that only executes it's argument as a template string?


I am unaware of any such plans. Could you give an example of what it looks
like and what it would accomplish? Thanks.


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

Re: Template strings as a template language.

[Mark S. Miller]

How is explicitly passing a scope different from calling the function with a

{title, content}

object?



On Sun, Sep 13, 2015 at 7:24 AM, Alexander Jones <a...@weej.com> wrote:

> Same place as `eval`. Arguably both should have the option of explicitly
> passing a scope, for extra strictness, like Python's.
>
> On 13 September 2015 at 15:15, Mark S. Miller <erig...@google.com> wrote:
>
>>
>>
>> On Sun, Sep 13, 2015 at 7:08 AM, Thomas <thomasjamesfos...@bigpond.com>
>> wrote:
>>
>>> What I've been doing:
>>>
>>> export const template = ({title, content}) => `template string for
>>> ${title}`;
>>>
>>> Or variations thereof. I then import that module wherever I need to use
>>> the template and call it as a function.
>>>
>>
>> If you were not to call it as a function, where would it get its bindings
>> for title and content?
>>
>>
>>
>>>
>>> Using eval and having the template string as a normal string (so, read
>>> the template from file as a string, wrap it with back ticks, and then pass
>>> it to eval) at the moment is risky since it's possible for input to
>>> prematurely end the template string and do nasty stuff*. Ideally there
>>> would be a variant of eval where the string to be evaluated must be a
>>> template string expression.
>>>
>>> Thomas
>>>
>>> * I'm aware that someone could still put something inside a template
>>> string and do nasty stuff, but I'm not sure if that's a easily solved
>>> problem.
>>>
>>> On 13 Sep 2015, at 10:08 PM, Mark S. Miller <erig...@google.com> wrote:
>>>
>>> On Sun, Sep 13, 2015 at 2:42 AM, Thomas <thomasjamesfos...@bigpond.com>
>>> wrote:
>>>
>>>> I'd really like to use Template strings as a templating language, but
>>>> unless I include a lot of boilerplate code (export a template string
>>>> wrapped in a function from a file)
>>>
>>>
>>> Hi Thomas, could you give a concrete example of the boilerplate you have
>>> in mind and what it accomplishes?
>>>
>>>
>>>
>>>> or use eval after loading a file as a string it's pretty much
>>>> impossible.
>>>>
>>>> Is there a simpler way to be doing this? Or any plans for a type of
>>>> eval that only executes it's argument as a template string?
>>>
>>>
>>> I am unaware of any such plans. Could you give an example of what it
>>> looks like and what it would accomplish? Thanks.
>>>
>>>
>>> --
>>> Cheers,
>>> --MarkM
>>>
>>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>> ___
>> 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: Template strings as a template language.

[Mark S. Miller]

The great achievement of modern js module systems including the es6 std
module system is to end the greatest pain of prior js: linkage through side
effects to the shared global scope. Good riddance.

If you're talking about a scope other than the global one, how would a
template come to be evaluated in that scope? If the answer is that it is
textually nested in that scope, then isn't that what template strings
already do?





On Sun, Sep 13, 2015 at 7:24 AM, Thomas <thomasjamesfos...@bigpond.com>
wrote:

> They would be whatever they are in the scope in which the template string
> is evaluated.
>
> Thomas
>
> On 14 Sep 2015, at 12:15 AM, Mark S. Miller <erig...@google.com> wrote:
>
>
>
> On Sun, Sep 13, 2015 at 7:08 AM, Thomas <thomasjamesfos...@bigpond.com>
> wrote:
>
>> What I've been doing:
>>
>> export const template = ({title, content}) => `template string for
>> ${title}`;
>>
>> Or variations thereof. I then import that module wherever I need to use
>> the template and call it as a function.
>>
>
> If you were not to call it as a function, where would it get its bindings
> for title and content?
>
>
>
>>
>> Using eval and having the template string as a normal string (so, read
>> the template from file as a string, wrap it with back ticks, and then pass
>> it to eval) at the moment is risky since it's possible for input to
>> prematurely end the template string and do nasty stuff*. Ideally there
>> would be a variant of eval where the string to be evaluated must be a
>> template string expression.
>>
>> Thomas
>>
>> * I'm aware that someone could still put something inside a template
>> string and do nasty stuff, but I'm not sure if that's a easily solved
>> problem.
>>
>> On 13 Sep 2015, at 10:08 PM, Mark S. Miller <erig...@google.com> wrote:
>>
>> On Sun, Sep 13, 2015 at 2:42 AM, Thomas <thomasjamesfos...@bigpond.com>
>> wrote:
>>
>>> I'd really like to use Template strings as a templating language, but
>>> unless I include a lot of boilerplate code (export a template string
>>> wrapped in a function from a file)
>>
>>
>> Hi Thomas, could you give a concrete example of the boilerplate you have
>> in mind and what it accomplishes?
>>
>>
>>
>>> or use eval after loading a file as a string it's pretty much impossible.
>>>
>>> Is there a simpler way to be doing this? Or any plans for a type of eval
>>> that only executes it's argument as a template string?
>>
>>
>> I am unaware of any such plans. Could you give an example of what it
>> looks like and what it would accomplish? Thanks.
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
>


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

Re: Template strings as a template language.

[Mark S. Miller]

On Sun, Sep 13, 2015 at 8:58 AM, Bob Myers  wrote:

> Templating languages typically "compile" templates into functions through
> various lexical transformations.
>
> Consider a template file foo.tem:
>
> ```
> My name is ${this.name}.
> ```
>
> Lexically transform this into
>
> ```
> function foo() {
>   return `My name is ${this.name|}.`;
> }
>
> Then invoke the template as eg
>
> ```
> foo.call({name: 'Bob'})
> ```
>
> Having said that, I doubt if ES6 template strings serve as a useful basis
> for a full-fledged templating system. To take just one basic example, how
> would one implement the equivalent of `{{#if}}`?
>

What does `{{#if}}` mean?


>
> Bob
>
>
> ___
> 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: Object id, hash, etc?

[Mark S. Miller]

See Labeler at
http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#unique_labeler



On Tue, Sep 8, 2015 at 11:16 AM, joe  wrote:

> Didn't send to list, something is wrong with my reply all. Sorry about
> that. Stupid mobile gmail.
> -- Forwarded message --
> From: "joe" 
> Date: Sep 8, 2015 11:15 AM
> Subject: Re: Object id, hash, etc?
> To: "Garrett Smith" 
> Cc:
>
> I agree with this request. This is the logical complement to valueof, I
> think. And yes, for most ID use cases this isn't a good fit, but we're not
> talking about the general case, just the cases where a python style id()
> function *is* appropriate.
>
> Joe
> On Sep 8, 2015 9:08 AM, "Garrett Smith"  wrote:
>
>> On 9/8/15, Michael McGlothlin  wrote:
>> > Is there a reason not to provide an object id and hash value as other
>> > languages often do? I find myself defining an identity symbol on objects
>> > with a value from a simple global counter. It makes it easier to debug
>> if I
>> > can just look at a log and see what objects and functions were active.
>> >
>> > Likewise a hash value would simplify a lot of comparisons and make it
>> easier
>> > to debug.
>> >
>> > I especially find the ID useful when working with bound functions as
>> they
>> > can be difficult to tell apart. I like to change toString() to provide
>> the
>> > ID followed by the code (flattened to one line).
>> >
>> >
>>
>> NFE's are safe to use where IE8 support isn't needed*.
>> (function aa(){}).name; // "aa"
>>
>> As for using Object IDs and Object Pooling, lexically-scoped values
>> have benefits over global ID generators (as your counter). The values
>> can be passed in as a parameter to the Factory (useful with Private
>> Proxy). There other benefits to this pattern regarding memory
>> management and application design. Contact me if you'd like to learn
>> more.
>>
>> * https://kangax.github.io/nfe/
>> --
>> Garrett
>> @xkit
>> ChordCycles.wordpress.com
>> garretts.github.io
>> personx.tumblr.com
>> ___
>> 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
>
>


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

Re: Object id, hash, etc?

[Mark S. Miller]

On Tue, Sep 8, 2015 at 1:57 PM, Michael McGlothlin <
mike.mcgloth...@gmail.com> wrote:

> I try to keep it pretty simple. It's not fancy but the times you want fast
> and dirty information like this are the same times you don't want to have
> to define it manually.
>
>  Symbol.identity = Symbol( 'Symbol.identity' );
>  const identity = Symbol( 'identity' );
>  var OBJECT_ID = 0;
>  Object.defineProperty( Object.prototype, Symbol.identity, {
>   get: () => {
>if ( !Object.hasOwnProperty.call( this, identity ) ) {
> this[ identity ] = ++OBJECT_ID;
>

Does not work on frozen objects.



>}
>return this[ identity ];
>   }
>  } );
>
> On Tue, Sep 8, 2015 at 1:44 PM, Mark S. Miller <erig...@google.com> wrote:
>
>> See Labeler at
>> http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#unique_labeler
>>
>>
>>
-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object id, hash, etc?

[Mark S. Miller]

Hi Tab, then you get the Labeler, which this message is responding to.

On Tue, Sep 8, 2015 at 2:12 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote:

> On Tue, Sep 8, 2015 at 2:07 PM, Mark S. Miller <erig...@google.com> wrote:
> > On Tue, Sep 8, 2015 at 1:57 PM, Michael McGlothlin
> > <mike.mcgloth...@gmail.com> wrote:
> >>
> >> I try to keep it pretty simple. It's not fancy but the times you want
> fast
> >> and dirty information like this are the same times you don't want to
> have to
> >> define it manually.
> >>
> >>  Symbol.identity = Symbol( 'Symbol.identity' );
> >>  const identity = Symbol( 'identity' );
> >>  var OBJECT_ID = 0;
> >>  Object.defineProperty( Object.prototype, Symbol.identity, {
> >>   get: () => {
> >>if ( !Object.hasOwnProperty.call( this, identity ) ) {
> >> this[ identity ] = ++OBJECT_ID;
> >
> >
> > Does not work on frozen objects.
>
> Of course, it's trivial to switch it to WeakMap'ing the key.
>
> ~TJ
>



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

Re: Weak References

[Mark S. Miller]

On Mon, Sep 7, 2015 at 10:19 AM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> Resending this as a new message because of my apparently broken
> WYSIWYDG (what you see is what you don't get) email client... :-(
>
> Hopefully this doesn't itself get corrupted...
>
> > My original email featured a use case, although I had to rewrite it to
> use explicit garbage collection. I need a way to watch for when the object
> is garbage collected.
> >
> > ```js
> > function rotateStream(interval, format) {
> > const res = {}
> > setStream(res, format)
> >
> > let stream = new WeakReference(res) , format)
>

Unbalanced parens.


> >
> > let timer = setInterval(() => {
> > setStream(stream.get(), format)
> > }, interval)
> >
> > stream.onCollect(() => {
> > // reference is dead, clear this timer
> > clearTimer(timer)
> > // break local strong references
> > timer = stream = null
> > })
> >
> > // Return a strong reference
> > return res
> > }
> > ```
> >
> > The complicating part is that I also need the interval callback to
> weakly reference the value. Otherwise, I've always got one active strong
> reference to the stream. This is with a listener for when the value is
> garbage collected.
> >
> > Here's the version without a listener (it's simpler, but more crude):
> >
> > ```js
> > function rotateStream(interval, format) {
> > const res = {}
> > setStream(res, format)
> >
> > let stream = new WeakReference(res)
> >
> > setInterval(function () {
> > try {
> > setStream(stream.get(), format)
> > } catch (e) {
> > // reference is dead, clear this timer
> > clearInterval(this)
> >
> > // break strong reference to weak one
> > stream = null
> > }
> > }, interval)
> >
> > // Return a strong reference
> > return res
> > }
> > ```
> >
> > Sorry for the ambiguity.
> >
> > (edited out a few bugs from the original)
>
> (it got corrupted when saving somehow :-( )
>
>
> On Sun, Sep 6, 2015 at 11:34 PM, Mark S. Miller <erig...@google.com>
> wrote:
> >
> >
> > On Sun, Sep 6, 2015 at 8:04 PM, Isiah Meadows <isiahmead...@gmail.com>
> > wrote:
> >>
> >> My original email featured a use case, although I had to rewrite it to
> use
> >> explicit garbage collection. I need a way to watch for when the object
> is
> >> garbage collected.
> >>
> >> ```js
> >
> > [...Somehow reformatted in transit...]
> >
> >>
> >> ```
> >
> >
> > Hi Isiah, the text in the above code block somehow got reformatted in
> > transit. You can see the problem at
> > https://mail.mozilla.org/pipermail/es-discuss/2015-September/044141.html
> > https://esdiscuss.org/topic/weak-references#content-10
> >
> > Since the code below does not have the callback, I don't yet have enough
> > context to understand your message. When the GC notifies that the stream
> is
> > to be collected, by notifying some callback, why does that callback need
> to
> > access the stream? What does the callback do with the stream during the
> > notification that the stream is condemned?
> >
> > Is the interval callback somehow related to the GC notification
> callback? As
> > you see, I just don't get it yet.
> >>
> >>
> >> The complicating part is that I also need the interval callback to
> weakly
> >> reference the value. Otherwise, I've always got one active strong
> reference
> >> to the stream. This is with a listener for when the value is garbage
> >> collected.
> >>
> >> Here's the version without a listener (it's simpler, but more crude):
> >>
> >> ```js
> >> function rotateStream(interval, format) {
> >> const res = {}
> >> setStream(res, format)
> >>
> >> let stream = new WeakReference(res)
> >>
> >> setInterval(function () {
> >> try {
> >> setStream(stream.get(), format)
> >> } catch (e) {
> >> // reference is dead, clear this timer
> >> clearInterval(this)
> >>
> >> // break strong reference to weak one
> >> stream = null
> >> }
> >> }, interval)
> >>
> >> // Return a strong reference
> >> return res
> >> }
> >> ```
> >>
> >> Sorry for the ambiguity.
> >>
> >> (edited out a few bugs from the original)
> >>
> >>
> >
> > --
> > Cheers,
> > --MarkM
>
>
>
> --
> Isiah Meadows
>



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

Re: Weak References

[Mark S. Miller]

I also don't get the purpose of this code. What is it trying to achieve?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss