Re: Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

[Mark Miller]

Template is transitively frozen, so it cannot be mutated in place.


On Wed, Jan 9, 2019 at 11:49 AM T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Wed, Jan 9, 2019 at 7:40 PM Andrea Giammarchi
>  wrote:
> > I dare saying tags are another issue here, 'cause "abc" === "abc",
> >  and with an identity function such `const id = o => o`,
> > `id("abc") === id("abc")` but due latest changes to template
> > literals, id`abc` !== id`abc` so it's easily misleading in the
> > tagged case.
>
> Very good point, but at least tagging is its own thing.
>
> What "recent changes" are you referring to? Surely
>
> ```js
> id`abc` === id`abc`
> ```
>
> with that version of `id` was always `false`? You can't reuse the
> array from the first call to call the tag function the second time,
> what if the function modified the array? (Presumably if it *is* a
> change, that's *why* it was changed... :- ) )
>
> -- 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: String identity template tag

[Mark Miller]

I think this is the right question. I agree that String.cook or whatever it
is called with typically be called explicitly rather than used
syntactically as a tag. However, putting the optional mapping function
aside for a moment, if the job it is doing is equivalent to that done by a
tag function, and if there are similar existing tags that can be called as
a function to do a similar job, I think it would be better for them to have
a similar signature and be used in an API compatible way.

In this case, if we choose a name like "cook" or "cooked" in order to make
the analogy with String.raw, then it should have the same API surface as
String.raw. Otherwise, there's too much to remember.

As for the optional mapping function, there's nothing about that which is
more relevant to cooked base strings than to raw base strings. We should be
able to apply mapping functions to either, as well as to other base tags,
in a similar way. This suggests tag combinators:

```js
const mapTag = (baseTag, mapFn) => (template, ...aubs) => baseTag(template,
...subs.map(mapFn));

mapTag(String.cooked, escapeHTML)`...`
```




As a completely separate point, this way of escaping html is not context
sensitive, and likely horribly unsafe. Much of the motivation for template
literals in the first place is to support context sensitive escaping, where
the escaping of the x data in

```js
safeHTML`${x}`
```

depends on where in the html parsing of the literal parts it is
encountered. See the work of Mike Samuel (cc'ed).



On Thu, Dec 13, 2018 at 10:44 AM T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Thu, Dec 13, 2018 at 6:37 PM T.J. Crowder
>  wrote:
> >
> > But called normally, it's a useful helper, for instance in
> > Isiah's `escape`...
>
> Going through the process of the example for my message just now made me
> think more about this function. Suppose it:
>
> 1. Accepted an array of substitutions rather than a rest parameter, and
>
> 2. Accepted an optional mapping function
>
> Then, what I wrote on my last message as:
>
> ```js
> const escape = (strings, ...subs) => {
> return String.cook(strings, ...subs.map(escapeHTML));
> };
> ```
>
> would be
>
> ```js
> const escape = (strings, ...subs) => *String.cook(strings, subs,
> escapeHTML)*;
> ```
> (http://jsfiddle.net/n6p7xcvm/1/)
>
> ...while still supporting the earlier usage (just without spread) if
> desired.
>
> -- T.J. Crowder
>


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

Re: String identity template tag

[Mark Miller]

I like String.cooked best. While I agree that method names should generally
be verbs, I suggest this rule should *not* be used for template literal tag
names. Rather, the tag name should generally be descriptive, naming the
language being parsed or the way it is interpreted or what the value of the
template literal expression will be. Most often, it should name the
language being parsed. By contrast with "raw", "cooked" is the right name
for this language --- the language of escaped characters within a normal
string literal.

Historical note: Template literals derive from E's quasi-literals
http://www.erights.org/elang/grammar/quasi-overview.html . Template literal
tags are E's quasi-parsers. We usually named quasi-parsers according to the
language they were quasi-parsing. This is natural for most JS uses. See
https://github.com/erights/quasiParserGenerator



On Thu, Dec 13, 2018 at 5:42 AM T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Thu, Dec 13, 2018 at 1:03 PM kai zhu
>  wrote:
> > why not copy python's list-zip static-function
>
> The result isn't a string, it's an array you'd then have to join with
> `.join("")`. Not that `zip` isn't a useful function *too*... (At least,
> presumably it is, it shows up in libs a lot. I don't recall having had to
> do it outside a tag function.)
>
> > i'm also against the spread-operator signature.
>
> Good point to raise. (FWIW: It's "rest," not "spread;" and it's not an
> operator.)
>
> An argument in favor of using a rest parameter is it aligns with
> `String.raw`. (It also makes `cook` a valid tag function, though a
> pointless one to use in that way as the result is what you'd get from an
> untagged template.)
>
> An argument against using a rest parameter (taking an array instead) is
> that, to my mind anyway, the primary use case for this function is as a
> tool within other general-purpose tag functions (like Isiah's `debug` and
> `trust` examples). In a general-purpose tag function, since you don't know
> how many substitution values you're going to get, you're likely to have
> used a rest parameter, meaning you already have an array. Passing the array
> directly is more efficient, surely, than spreading it and having `cook`
> gather it up into a rest parameter. (That said, if engines don't already
> aggressively optimize calls using spread with an array that has the default
> iterator to functions using a perfectly-matching rest parameter list,
> presumably they will at some point, or investigations have proved it's not
> worth the trouble.)
>
> I'm not bothered either way.
>
> -- T.J. Crowder
>


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

Re: String identity template tag

[Mark Miller]

On Wed, Dec 12, 2018 at 5:24 PM Isiah Meadows 
wrote:

> The template is being expanded as if the template itself is untagged.


Does this mean that you describe what tagged templates do, or what untagged
templates do, as "expanding" something? If so, what is the intuition behind
that prior usage of "expand"?



> The point of this is a template tag that just does the default untagged
> behavior of coercing all expressions to strings and joining the whole thing
> together.
>

I certainly agree that the name should suggest equivalence to the default
untagged behavior. I just never would have thought to describe that
behavior as "expanding" something. What is it expanded into?



> On Wed, Dec 12, 2018 at 20:21 Mark Miller  wrote:
>
>> What is the intuition behind "expand"? What is being expanded, and what
>> is it expanding into?
>>
>>
>>
>> On Tue, Dec 11, 2018 at 10:59 PM Isiah Meadows 
>> wrote:
>>
>>> Those names a little too generic for my liking here. What about
>>> `String.expand(template, ...params)`?
>>>
>>> And also, let's not try to bake a traditional template engine into the
>>> JS spec - syntactic template strings already work well enough.
>>>
>>> -
>>>
>>> Isiah Meadows
>>> cont...@isiahmeadows.com
>>> www.isiahmeadows.com
>>>
>>> On Wed, Dec 12, 2018 at 1:13 AM Michael Luder-Rosefield
>>>  wrote:
>>> >
>>> > Why not String.tag or .tagged?
>>> >
>>> > While we're at it, is there any good reason not to have something like
>>> this:
>>> >
>>> > ```
>>> > String.template = (template : String,
>>> taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object)
>>> => taggerFn(template, (keys is Array) ? ...keys : keys)
>>> > // apologies for pseudo-semi-functional code
>>> > // having keys be an object allows template to be filled by key name
>>> rather than just index
>>> > ```
>>> > This would make templates closer to the traditional usage, where the
>>> template comes first and is later passed values to be filled in with.
>>> Having the taggerFn as an argument allows for things like Isiah's
>>> escape-then-apply tagging examples.
>>> >
>>> >
>>> > On Wed, 12 Dec 2018 at 12:51 Isiah Meadows 
>>> wrote:
>>> >>
>>> >> I'm not married to `identity`, and I agree the name is probably not
>>> >> ideal. I'm more concerned about functionality, though.
>>> >>
>>> >> -
>>> >>
>>> >> Isiah Meadows
>>> >> cont...@isiahmeadows.com
>>> >> www.isiahmeadows.com
>>> >>
>>> >> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
>>> >>  wrote:
>>> >> >
>>> >> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
>>> >> >  wrote:
>>> >> > >
>>> >> > > It'd be *way* easier to construct simple template tags if there
>>> was a
>>> >> > > built-in identity tag
>>> >> >
>>> >> > Wholeheartedly agree, a couple of months ago I considered posting
>>> something very similar, both for utility reasons and in hopes that it would
>>> be an optimization target (being a standard operation).
>>> >> >
>>> >> > I find the name `identity` unilluminating, though, partially
>>> because it's not quite the same meaning as the usual "identity" function
>>> (`function identity(x) { return x; }`), though it's close. `assemble`?
>>> >> >
>>> >> > -- T.J. Crowder
>>> >> ___
>>> >> 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: String identity template tag

[Mark Miller]

What is the intuition behind "expand"? What is being expanded, and what is
it expanding into?



On Tue, Dec 11, 2018 at 10:59 PM Isiah Meadows 
wrote:

> Those names a little too generic for my liking here. What about
> `String.expand(template, ...params)`?
>
> And also, let's not try to bake a traditional template engine into the
> JS spec - syntactic template strings already work well enough.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Wed, Dec 12, 2018 at 1:13 AM Michael Luder-Rosefield
>  wrote:
> >
> > Why not String.tag or .tagged?
> >
> > While we're at it, is there any good reason not to have something like
> this:
> >
> > ```
> > String.template = (template : String,
> taggerFn=String.identity/tag/tagged : Function) => (keys : Array | Object)
> => taggerFn(template, (keys is Array) ? ...keys : keys)
> > // apologies for pseudo-semi-functional code
> > // having keys be an object allows template to be filled by key name
> rather than just index
> > ```
> > This would make templates closer to the traditional usage, where the
> template comes first and is later passed values to be filled in with.
> Having the taggerFn as an argument allows for things like Isiah's
> escape-then-apply tagging examples.
> >
> >
> > On Wed, 12 Dec 2018 at 12:51 Isiah Meadows 
> wrote:
> >>
> >> I'm not married to `identity`, and I agree the name is probably not
> >> ideal. I'm more concerned about functionality, though.
> >>
> >> -
> >>
> >> Isiah Meadows
> >> cont...@isiahmeadows.com
> >> www.isiahmeadows.com
> >>
> >> On Tue, Dec 11, 2018 at 5:41 AM T.J. Crowder
> >>  wrote:
> >> >
> >> > On Mon, Dec 10, 2018 at 7:08 PM Isiah Meadows
> >> >  wrote:
> >> > >
> >> > > It'd be *way* easier to construct simple template tags if there was
> a
> >> > > built-in identity tag
> >> >
> >> > Wholeheartedly agree, a couple of months ago I considered posting
> something very similar, both for utility reasons and in hopes that it would
> be an optimization target (being a standard operation).
> >> >
> >> > I find the name `identity` unilluminating, though, partially because
> it's not quite the same meaning as the usual "identity" function (`function
> identity(x) { return x; }`), though it's close. `assemble`?
> >> >
> >> > -- T.J. Crowder
> >> ___
> >> 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

POLA Would Have Prevented the Event-Stream Incident

[Mark Miller]

The npm / event-stream incident is the perfect teaching moment for POLA
(Principle of Least Authority), and for the need to support least authority
for JavaScript libraries.
https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99
by Kate Sills (cc'ed) explains the point. The links at the end of Kate's
article are worth following. In particular:

Securing EcmaScript, presentation to Node Security
https://www.youtube.com/watch?v=9Snbss_tawI=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2
is
my presentation explaining many of these issues *prior to* this particular
incident.

At the recent (November 2018) tc39 meeting, I presented on the enhancements
needed to support least authority for JavaScript modules and libraries,
adequate to have prevented this incident.

Besides es-discuss
https://news.ycombinator.com/item?id=18590116
would be a good place to discuss these issues.

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

Re: Module Namespace Objects - "writable"

[Mark Miller]

Ah. Crossed in the mail. Yes, Alan raises the same issues regarding the TDZ
vs non-writable worry.

Thanks for the pointer.

On Wed, Oct 24, 2018 at 11:01 AM Logan Smyth  wrote:

> Here's one other post about this from Allen:
> https://github.com/tc39/ecma262/issues/749#issuecomment-265637923
>
> On Wed, Oct 24, 2018 at 10:42 AM T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> I'm curious if I've inferred the rationale for something correctly.
>>
>> The module namespace object properties for exports have `writable: true`
>> in their property descriptors, but of course, they aren't writable (the
>> module namespace object has its own [[Set]] implementation that returns
>> false). I wondered why they weren't `writable: false`, so I went looking.
>>
>> I found discussion in the March 24 2015 meeting notes about whether to
>> even have `getOwnPropertyDescriptor` work. The consensus was yes, it should
>> work (mixins!), and that it should report a basic data property that isn't
>> configurable -- but is writable. Yahuda Katz points out that:
>>
>> > it is writable, but it's not writable by you
>>
>> though that's not always true (it may be declared `const`; that
>> information isn't leaked from the module, though).
>>
>> In the May 25 2017 notes I found a comment from Mark S. Miller in
>> relation to `writable: true`:
>>
>> > Non-writeable provides guarantee. Writable provides no guarantee.
>>
>> And this exchange between Yahuda Katz, Allen Wirfs-Brock, and Adam Klein:
>>
>> > YK: There is a a new property that we define as writable that is not
>> writable.
>> >
>> > AWB: Not new.
>> >
>> > AK: Since... Proxys!
>>
>> There was some discussion of considering some flag basically saying what
>> YK said, e.g., it's writable, but not by you :-) -- but that was more a
>> brief digression that didn't go anywhere.
>>
>> So, then, what I infer is: They're marked writable because:
>>
>> 1. They may be writable by the exporting module, so code can't assume the
>> value won't change; `writable: false` would make that assumption valid
>> 2. Whether or not they're writable by the exporting module isn't
>> information that should leak out of it
>> 3. Non-writable `writable: true` data properties were already a thing
>> (Proxies)
>>
>> So the most sensible thing was `writable: true` rather than `writable:
>> false`.
>>
>> How'd I do? :-)
>>
>> -- T.J. Crowder
>> ___
>> 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: Module Namespace Objects - "writable"

[Mark Miller]

Extremely good!

But it is more than just a "should" or "sensible". It is a requirement of
the object invariants. If a property is described as a non-configurable
non-writable data property, it must always have the same value.

One issue I think should be open to debate: If the exported variable is
declared const, do we follow the principle you mention:

> 2. Whether or not they're writable by the exporting module isn't
information that should leak out of it

or do we consider the exporting module to be exporting its const-ness as
well? If the latter, then those properties probably should be described as
non-writable non-configurable data properties with, therefore, a stable
value.

However, I say "probably" above because of one issue that gives me pause:
the temporal dead zone. It does *not* violate the invariants for a [[Get]]
or [[GetOwnPropertyDescriptor]] on a non-writable non-configurable data
property to intermittently fail with a thrown error. The stability
guarantee is only regarding what the non-failure cases report. But it is
weird to report that a property is a non-writable non-configurable data
property with a stable value before that value is determined. Worse, given
how the object invariants are enforced on proxies (with the shadow target
bookkeeping), I don't see how a proxy could emulate this behavior. This is
in some sense a flaw in the proxy design: This shows an exotic object
behavior that *is* allowed by the object invariants but not emulatable by
proxies.






On Wed, Oct 24, 2018 at 10:42 AM T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> I'm curious if I've inferred the rationale for something correctly.
>
> The module namespace object properties for exports have `writable: true`
> in their property descriptors, but of course, they aren't writable (the
> module namespace object has its own [[Set]] implementation that returns
> false). I wondered why they weren't `writable: false`, so I went looking.
>
> I found discussion in the March 24 2015 meeting notes about whether to
> even have `getOwnPropertyDescriptor` work. The consensus was yes, it should
> work (mixins!), and that it should report a basic data property that isn't
> configurable -- but is writable. Yahuda Katz points out that:
>
> > it is writable, but it's not writable by you
>
> though that's not always true (it may be declared `const`; that
> information isn't leaked from the module, though).
>
> In the May 25 2017 notes I found a comment from Mark S. Miller in relation
> to `writable: true`:
>
> > Non-writeable provides guarantee. Writable provides no guarantee.
>
> And this exchange between Yahuda Katz, Allen Wirfs-Brock, and Adam Klein:
>
> > YK: There is a a new property that we define as writable that is not
> writable.
> >
> > AWB: Not new.
> >
> > AK: Since... Proxys!
>
> There was some discussion of considering some flag basically saying what
> YK said, e.g., it's writable, but not by you :-) -- but that was more a
> brief digression that didn't go anywhere.
>
> So, then, what I infer is: They're marked writable because:
>
> 1. They may be writable by the exporting module, so code can't assume the
> value won't change; `writable: false` would make that assumption valid
> 2. Whether or not they're writable by the exporting module isn't
> information that should leak out of it
> 3. Non-writable `writable: true` data properties were already a thing
> (Proxies)
>
> So the most sensible thing was `writable: true` rather than `writable:
> false`.
>
> How'd I do? :-)
>
> -- 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: Proxy target/handler access leak in Node

[Mark Miller]

> The Node.js trust model assumes that all code is trusted.

First I want to respond to this sentence out of context. I often hear such
phrases. I know what people mean by this, but the phrase "trusted" here
*always* leads to confusion and muddy thinking. I don't trust the code I
wrote yesterday. Instead, what we mean by this is something like:

"The Node.js  model assumes we are fully vulnerable to all code."

This phrasing helps us notice some of the questions made obscure by the
earlier phrase. What is fully vulnerable to which code? What is meant in
this case is presumably something more like

"...assumes the Node.js process is fully vulnerable to all code it is asked
to run."

Under a traditional OS, a process executes as the account (or "user")
executing that process, and has all the permissions of that user. So this
becomes:

"...assumes the user is fully vulnerable to all code that any Node process
executing as that user is asked to run."

(Which of course includes anything built on Electron, which makes the
situation even worse in some ways.)

Given the way that this body of code is typically selected, by transitive
alleged package dependencies, this is a ridiculously large attack surface.
Fortunately, there is increasing appreciation that such pervasive
vulnerability is problematic.

See
https://www.youtube.com/watch?v=9Snbss_tawI=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2=23

Also relevant
https://www.youtube.com/watch?v=wQHjITxQX0g=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2=18
https://www.youtube.com/watch?v=9WdbTucMaRo=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2=10
https://www.youtube.com/watch?v=pig-sIS8_Wc=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2=20

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

Re: Proxy target/handler access leak in Node

[Mark Miller]

On Mon, Sep 17, 2018 at 8:32 AM Darien Valentine 
wrote:

> Thanks for the context, James. Yes, this thread mainly concerns the issue
> of being able to obtain references to values within the handler/target from
> external code, though I did try to make a case for not having the showProxy
> option in the original issue thread.
>
> I would also not have thought to call it an “attack” vector. Mark would be
> able to say better for sure though. It does make an invariant of the
> language violable though. It’s similar to exposing a function which, given
> only a function object, may return references to arbitrary values from that
> function’s scope.
>

> It’s similar to exposing a function which, given only a function object,
may return references to arbitrary values from that function’s scope.

This is an apt comparison. A debugger has access to such info. Likewise, in
a secure OS, when one process is able to debug another, the first process
can read any data from the address space of the second. There have even
been language implementations that were otherwise supposed to be memory
safe that had "peek" and "poke" operations for reading and writing
arbitrary memory locations from programs in the language. Of course, memory
allocators and garbage collectors typically need such access.

Whether these are "attacks" or "vulnerabilities" depends on how such
permission for debug-level access or peek/poke access is controlled and
provided.

>From a bit of web searching, I found the following worrisome:

https://github.com/nodejs/node/pull/20857
https://github.com/nodejs/node/commit/dadd6e16888baac8fd110432b81f3fd1237be3e1
seemingly in response to
https://github.com/nodejs/node/issues/20821
https://github.com/nodejs/node/issues/22671

Making is a public symbol in this manner means it is almost impossible to
deny. It is still true that "util" is deniable, so this isn't necessarily
fatal. I am not yet oriented enough to understand what the consequences are
of suppressing util; but I am worried.

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

Re: Proxy target/handler access leak in Node

[Mark Miller]

This is indeed quite scary. I have never used of explored the Node `util`
API. What is going on here? Can you explain?

The Realms shim and SES (which build on the Realms shim) create an
environment in which only those globals defined by EcmaScript, not by the
host, are present by default.
https://github.com/Agoric/SES/tree/master/demo
https://rawgit.com/Agoric/SES/master/demo/
Does that mean this attack is impossible from code loaded into a new realm
as made by the shim or SES?



On Sun, Sep 16, 2018 at 12:10 PM Mike Samuel  wrote:

> Nicely done!
>
> One more reason to prefer WeakMaps to properties when relating objects and
> secrets.
>
>
>
> On Sun, Sep 16, 2018 at 2:59 PM Darien Valentine 
> wrote:
>
>> A few weeks ago I’d commented on an open Node github issue regarding
>> Proxies and inspection. While the bulk of the comment concerns an opinion
>> that proxies should not be treated as special case, I included an example
>> of a mechanism by which the current implementation allows outside code to
>> access the target and handler objects of a proxy that it does not own.
>>
>> On reflection I realized this specific issue might be worth drawing more
>> attention to.
>>
>> ```js
>> const util = require('util');
>>
>> const victim = new Proxy({}, {
>>   SECRET: 'Nothing outside can access this'
>> });
>>
>> let secret;
>>
>> const invariantViolator = {
>>   [util.inspect.custom](depth, options) {
>> const { stylize } = options;
>>
>> options.showProxy = true;
>>
>> options.stylize = (value, color) => {
>>   secret = value;
>>   options.stylize = stylize;
>>   return stylize(value, color);
>> };
>>
>> return victim;
>>   }
>> };
>>
>> util.inspect(invariantViolator);
>>
>> console.log(secret); // 'Nothing outside can access this'
>> ```
>>
>> The implication is that even if running Node with no C++ addons, it is
>> presently possible for proxies to be violated using just the standard lib,
>> which may be significant from a security perspective. I’m not sure if
>> that’s the case in practice, but just in case, I figured I should try to
>> get eyes on it.
>>
>> Note that even if this particular hole is patched, the "analog hole" (so
>> to speak) of just analyzing the string output remains.
>> ___
>> 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: Symbol history

[Mark Miller]

There was at some point an attempt at elaborating "symbol" into some kind
of "private name" or "private symbol", which failed for well explained
reasons. However, this is not where symbols started. Symbols started as a
way to introduce new properties while avoiding conflict with possible
property names, IOW, as a way to introduce new property "names" that were
guaranteed not to collide with any existing names. This is still their
primary purpose.


On Mon, May 28, 2018 at 11:09 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> Hi all,
>
> I've tried to glean this from the meeting notes and such, but many who
> were actively involved are on the list, so:
>
> Am I right that Symbols started out as "private Name objects" then over
> time their name was changed, they became primitives, and the privacy aspect
> was dropped; but having guaranteed-unique values was still useful, and
> found application (amongst other places) in solving the problem of adding a
> default iterator to `Array.prototype` without name conflicts with existing
> code in the wild?
>
> 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: Proposal: Add a global Infinitesimal property

[Mark Miller]

See the entire thread at <
https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks>.
While this position is in no way official, several of the reactions on the
thread are from other committee members, and so serves as an indication of
attitudes common on the committee.

See especially the bulleted list at <
https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks#content-22>
which prioritizes these concerns.


On Sat, May 12, 2018 at 10:14 AM, Jordan Harband  wrote:

> They're not written down anywhere, and they change based on the makeup of
> the committee.
>
> However, in general, the wider committee strives to avoid complexity, and
> absolutely will demand a justification for adding anything to JavaScript,
> including for changing the *process by which changes are made* to
> JavaScript.
>
> https://github.com/tc39/proposals is the list of current proposals,
> https://tc39.github.io/process-document/ describes the stage process, and
> https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md describes how
> one can contribute.
>
> I strongly encourage thorough familiarization with all those documents,
> including the spec/language itself, if you want to increase the
> effectiveness of a proposal.
>
> On Sat, May 12, 2018 at 10:12 AM, kdex  wrote:
>
>> A good place to start is [1].
>>
>> [1] https://github.com/tc39/proposals
>>
>> On Saturday, May 12, 2018 7:11:36 PM CEST Abdul Shabazz wrote:
>> > I wasn't aware of the committees view of synonyms and that they perceive
>> > them ad clutter. This unfortunate but i will moderate my future
>> suggestions
>> > accordingly. btw where can i find their submission/proposal guidelines?
>>
>> ___
>> 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: Number.MAX_SAFE_INTEGER incorrect?

[Mark Miller]

I take that back. The rfc says:

   An I-JSON sender cannot expect a receiver to treat an integer whose
   absolute value is greater than 9007199254740991 (i.e., that is
   outside the range [-(2**53)+1, (2**53)-1]) as an exact value.


For the natural interpretation of "treat" as in "operate on or with" I'd
say the rfc is correct. But the language is ambiguous and should be
clarified.




On Sun, May 6, 2018 at 12:34 PM, Mark Miller <erig...@gmail.com> wrote:

> Hi Anders, you are correct. The rfc as stated is incorrect. The EcmaScript
> spec is correct.
>
> 2**53 is indeed exactly representable, which is what the rfc is about. But
> 2**53 is not safe, which what the ecmascript spec is about.
>
>
>
> On Sun, May 6, 2018 at 11:58 AM, Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
>
>> On 2018-05-06 19:57, Logan Smyth wrote:
>> 
>>
>>> I think the best source of truth is likely the spec:
>>> https://www.ecma-international.org/ecma-262/8.0/#sec-number.
>>> max_safe_integer which states
>>>
>>> The value of Number.MAX_SAFE_INTEGER is the largest integer n such that
>>> n and n + 1 are both exactly representable as a Number value.
>>>
>>
>> Right, this is essentially what I'm claiming; Number.MAX_SAFE_INTEGER + 1
>> is a valid (exact) integer which means that
>> https://tools.ietf.org/html/rfc7493#section-2.2 is incorrect.
>>
>> Anders
>> ___
>> 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: Number.MAX_SAFE_INTEGER incorrect?

[Mark Miller]

Hi Anders, you are correct. The rfc as stated is incorrect. The EcmaScript
spec is correct.

2**53 is indeed exactly representable, which is what the rfc is about. But
2**53 is not safe, which what the ecmascript spec is about.



On Sun, May 6, 2018 at 11:58 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2018-05-06 19:57, Logan Smyth wrote:
> 
>
>> I think the best source of truth is likely the spec:
>> https://www.ecma-international.org/ecma-262/8.0/#sec-number.
>> max_safe_integer which states
>>
>> The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n
>> and n + 1 are both exactly representable as a Number value.
>>
>
> Right, this is essentially what I'm claiming; Number.MAX_SAFE_INTEGER + 1
> is a valid (exact) integer which means that https://tools.ietf.org/html/rf
> c7493#section-2.2 is incorrect.
>
> Anders
> ___
> 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: Number.MAX_SAFE_INTEGER incorrect?

[Mark Miller]

Oops. Should be:

if (isSafeInteger(a) && isSafeInteger(b)) {
  const c = a + b;
  if (isSafeInteger(c)) {
// c is actually the sum of a and b
  }
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Number.MAX_SAFE_INTEGER incorrect?

[Mark Miller]

motivation:

if (isSafeInteger(a) && isSafeInteger(b)) {
  const c = a + b;
  if (isSafeInteger(b)) {
// c is actually the sum of a and b
  }
}



On Sun, May 6, 2018 at 10:57 AM, Logan Smyth  wrote:

> To clarify, the "you can still add one to them" is probably the most
> important part in that definition, given your question.
>
> > Anyway, this definition departs from similar definitions in other
> languages and AFAICT, existing JavaScript implementations have no problems
> using 2^53 as an integer.
>
> 2^53 can be represented just fine, but `2**53 + 1 === 2**53` is `true`, so
> adding one to it does not actually increment the value, meaning it does not
> satisfy the definition of `SAFE` in this context.
>
> I think the best source of truth is likely the spec: https://www.ecma-
> international.org/ecma-262/8.0/#sec-number.max_safe_integer which states
>
> > The value of Number.MAX_SAFE_INTEGER is the largest integer n such that
> n and n + 1 are both exactly representable as a Number value.
>
>
> On Sun, May 6, 2018 at 10:47 AM, Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
>
>> On 2018-05-06 18:40, Isiah Meadows wrote:
>>
>>> Technically, "safe" in this context means "can you store this number
>>> *and all numbers below it* without loss of precision", and for every single
>>> one of these numbers, you can still add one to them. When you get up to
>>> 2^53, you can no longer add just 1 - you can only add 2 or more. This is
>>> based on the number of significand bits - 2^53 - 1 has all lower 53 bits
>>> set and its exponent set to 0 (ignoring bias). You can precisely store up
>>> to this number without having to adjust the exponent, no more. This is what
>>> is meant by "safe". (The terminology of "exactly representable" is a
>>> misnomer - the highest integer you can theoretically represent without loss
>>> of precision is `(2^53-1) * (2^971)`.)
>>>
>>
>> Thanx Isiah,
>> I (sort of) understand :-)
>>
>> Anyway, this definition departs from similar definitions in other
>> languages and AFAICT, existing JavaScript implementations have no problems
>> using 2^53 as an integer.
>>
>> > var t = 9007199254740992
>> < undefined
>> > t-1
>> < 9007199254740991
>> > t
>> < 9007199254740992
>>
>> For JavaScript this may be of limited importance but for (I-)JSON
>> canonicalization [1] it is vital that all parties do the same
>> interpretation.
>> That is, for I-JSON the 2^53-1 limitation is simply put wrong.
>>
>> Anders
>>
>> 1] https://github.com/cyberphone/json-canonicalization#json-can
>> onicalization
>>
>>
>>
>>> This SO answer should help explain the situation better:
>>> https://stackoverflow.com/a/1848762
>>>
>>>
>>> -
>>>
>>> Isiah Meadows
>>> m...@isiahmeadows.com 
>>> www.isiahmeadows.com 
>>>
>>> On Sun, May 6, 2018 at 11:58 AM, Anders Rundgren <
>>> anders.rundgren@gmail.com >
>>> wrote:
>>>
>>> If you write
>>> Number.MAX_SAFE_INTEGER
>>> into a browser console it will return
>>> 9007199254740991
>>>
>>> I believe this is wrong, 9007199254740992 the largest correct safe
>>> integer using IEEE-754 double precision.
>>>
>>> Using my own IEEE-754 debugger:
>>>
>>> Input floating point: 9007199254740991
>>> Hex value: 433f
>>> Binary value: 0 1110011 11
>>> 11
>>>
>>> Input floating point: 9007199254740992
>>> Hex value: 4340
>>> Binary value: 0 1110100 00
>>> 00
>>>
>>> Using an external IEEE-754 debugger:
>>> http://www.binaryconvert.com/result_double.html?decimal=0570
>>> 48048055049057057050053052055052048057057050 <
>>> http://www.binaryconvert.com/result_double.html?decimal=057
>>> 048048055049057057050053052055052048057057050>
>>>
>>> Anders
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org 
>>> https://mail.mozilla.org/listinfo/es-discuss <
>>> 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: Web Security Puzzles with a TC39 agenda

[Mark Miller]

Hi Mike, your message end with "In case you’re interested in how the
puzzles tie into the larger point I’m trying to make:" followed by three
unexpandable dots. Copy/paste error?

(Needless to say, I am interested ;).)


On Mon, Apr 30, 2018 at 8:02 AM, Mike Samuel  wrote:

> I put together a short video series of web security puzzles [1] to
> motivate what I'm presenting at the May meeting [2].
>
> cheers,
> mike
>
> [1] https://medium.com/@mikesamuel/puzzling-towards-security-a12b9427124
> [2] https://github.com/tc39/agendas/blob/master/2018/05.md
>
> 
>
> Puzzling Towards Security
>
> If you like computer security puzzles and JavaScript, you’ll like this
> short video series.
>
> It builds on work I and others in Google’s Security Engineering group have
> done to identify and counter the kinds of common mistakes that lead to
> vulnerabilities.
>
> After the puzzles I draw on experiences managing security within a large
> engineering organization that builds static systems and propose language
> tweaks that would enable similar outcomes for dynamic systems.
>
> In case you’re interested in how the puzzles tie into the larger point I’m
> trying to make:
>
> ...
>
> ___
> 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: Set functions

[Mark Miller]

Yes, please do!


On Tue, Apr 10, 2018 at 8:45 AM, Sebastian Malton 
wrote:

> I know that this has been brought up before but nothing seems to have come
> up with it. It also has had a lot of enthusiasm about it. Would me writing
> up a new proposal for adding the following functions to sets be useful? I
> would really like to see this through and would be willing to work for it
> too.
>
> The following functions I propose adding to Sets.
>
> 1. Union
> 2. Intersection
> 3. Difference
> 4. Symmetric Difference
> 5. ForEach
> 6. Map
> 7. Every
> 8. Filter
> 9. Find
> 10. Some
>
> Sebastian Malton
>
> ___
> 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 composition vs pipeline

[Mark Miller]

On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband  wrote:

> As someone who does wear the shoes of a senior programmer responsible
> (along with my team) for overseeing a very very large web project, the
> super trivial and easy answer to this is "use a linter" - eslint can be
> configured to restrict any syntax you like, and since surely your CI
> process is already gating any merges, so too can the linter be used to gate
> merges, which will prevent anyone from any using any syntax you deem
> unclean.
>
> Tons of new syntax can be added to JavaScript forever and it need not have
> a single bit of impact on any of your project's code except a few lines in
> your eslint configuration.
>


Hi Jordan, while I agree with some of your overall point, I think this goes
way too far. The larger the language, and the more diversity there is in
which subset one shop chooses vs another, the more we loose the benefits of
having many developers use a common language. No one shop writes all the JS
they use. They use libraries written by others whose lint rules are
different. They hire programmers from other shops. They read and post to
stackOverflow, etc.

Much better is for the language to omit as much as possible, keeping it
small. I am glad my "Tragedy of the Common Lisp" post is so widely cited
and appreciated. Later in that thread, at
https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks#content-22
I state a hierarchy of different parts of a language with different
pressures towards minimality:


the force of my [minimality] point gets weaker as we move from core
> language to standardizing libraries. The overall standard language can be
> seen as consisting of these major parts:
>
>- fundamental syntax -- the special forms that cannot faithfully be
>explained by local expansion to other syntax
>
>
>- semantic state -- the state than computation manipulates
>
>
>- kernel builtins -- built in library providing functionality that, if
>it were absent, could not be provided instead by user code.
>
>
>- intrinsics -- libraries that semantic state or kernel builtins
>depend on. For example, with Proxies, one might be able to do Array in user
>code. But other kernel builtins already have a dependency on Array
>specifically, giving it a privileged position over any replacement.
>
>
>- syntactic sugar -- the syntax that can be explained by local
>expansion to fundamental syntax.
>
>
>- global convenience libraries -- could be implemented by unprivileged
>user code, but given standard global naming paths in the primordial global
>namespace.
>
>
>- standard convenient library modules
>
> I have listed these in order, according to my sense of the costs of growth
> and the urgency for minimalism. For all of these we still need to exercise
> discipline. But it is only for the last one that we should consider growth
> of absolute size to be unbounded; restricting ourselves only to the rate of
> growth as we wait for candidates to prove themselves first by the de facto
> process. Ideally, TC39 should stop being the bottleneck on the last bullet
> anyway, as external de facto and de jure processes should be perfectly
> capable of independently arguing about and evolving standard convenience
> modules.



Although syntactic sugar is low on the list, it is still costly and best
avoided when there's no compelling need. "Just use a linter" is not a
panacea.



>
> On Mon, Mar 12, 2018 at 8:26 AM, Terence M. Bandoian 
> wrote:
>
>> In my opinion, one of the more significant advances in the C programming
>> language was the increase in the maximum length of identifiers.  To me,
>> this translates to "less cryptic is better".
>>
>> -Terence Bandoian
>>
>>
>>
>> On 3/11/2018 1:09 AM, Peter Jaszkowiak wrote:
>>
>> Personally, I'd push my subordinates to learn this new syntax. But if you
>> dislike it, you can blacklist it in your linter: it's one of the main
>> features of a linter.
>>
>> On Mar 10, 2018 23:37, "kai zhu"  wrote:
>>
>>> @peter, put yourself in the shoes of a senior-programmer responsible
>>> for overseeing an entire web-project.  the project is @ the
>>> integration-stage and you're busy debugging an async
>>> timeout/near-timeout bug preventing the frontend from talking to the
>>> backend (which btw, is one of the most common integration/qa
>>> javascript-bugs).
>>>
>>> while trying to figure out what's causing the timeout-issue, you're
>>> debugging i/o code with operators that look like this:
>>>
>>> ```
>>> const h = ? |> f |> g;
>>> ```
>>>
>>> maybe it is useful for the small-picture sub-problem you were
>>> originally trying to solve. but now that you're a bigger-fish with
>>> bigger-picture integration i/o issues, doesn't this look alot like
>>> technical-debt that no one will have a clue how to debug once a month
>>> or two has passed?
>>>
>>> 

Re: try/catch/else

[Mark Miller]

Hi Claude, that's nice. Whenever I faced this issue I always turned to the
boolean flag variable. But this is strictly better. I expect to use it from
now on. Thanks!


On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache 
wrote:

> What about the following pattern (labelled block + break)?
>
> ```js
> processSuggestions: {
> let suggestions;
> try {
>   suggestions = await fetchSuggestions();
> } catch (e) {
>   alert('Failed to load suggestions');
>   break processSuggestions;
> }
> showSuggestions(suggestions);
> }
> ```
>
> —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

Performance of frozen vs non-frozen objects

[Mark Miller]

At https://github.com/airbnb/javascript/issues/1619#issuecomment-353972202
I wrote:

I tried https://jsperf.com/freeze-vs-seal-vs-normal/3 and
> https://jsperf.com/freeze-vs-seal-vs-normal/28 on Chrome, FF, and Safari.
> I don't know why the bar charts are not updating. I am traveling and do not
> currently have access to a machine running Edge.
>


> Could someone who has access to all four browsers, and knows how to get
> the displayed data to update, try these on all four? Thanks.



Please? The answer could prevent further damage being done by bad advice.
Thanks.


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

Re: Add new function waitFor

[Mark Miller]

On Fri, Nov 17, 2017 at 1:50 PM, Michał Wadas  wrote:

> For me it boils down to "implementations which already don't follow spec
> exactly won't be able to implement such new part of specification"...
>
> Dynamic code generation with access to existing scope (sloppy mode direct
> eval) already puts strong constraints on spec-compliant implementation. Is
> it even considered issue?
>

Technically, in order to accommodate CSP, the EcmaScript spec already
allows an implementation to refuse to dynamically evaluate code via
evaluators, i.e., the eval function, the various function constructors, and
the import expression.




>
> On 17 Nov 2017 10:29 pm, "Isiah Meadows"  wrote:
>
>> Just FYI, I did talk a while back to one of the TC39 people previously
>> about the viability of encoding at least the low-level microtask
>> execution stuff into the spec, and they explained that for both
>> practical and theological reasons, there really was no way of doing it
>> that wouldn't require substantial changes to the HTML spec as well as
>> issues with other embedding use cases. (Node would actually be the
>> *least* affected in this area.)
>>
>> As for things like `setTimeout`/etc., ECMAScript is designed for *way*
>> more than just browsers - it even runs on Arduino boards. Some
>> runtimes that are geared towards embedded stuff deliberately don't
>> even implement any form of dynamic evaluation, like Kinoma XS6 (ES6
>> runtime which also does not retain source code for
>> `Function.prototype.toString` for ES-defined functions), and in those
>> cases, you might only have a single core available in the hardware,
>> making async timers, especially shorter ones, very unreliable and
>> power-hungry to use.
>>
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> www.isiahmeadows.com
>>
>>
>> On Thu, Nov 16, 2017 at 7:37 AM, Michał Wadas 
>> wrote:
>> > I wish we can have annex like "if host environment supports scheduling
>> tasks
>> > to run after certain time, it have to expose Promise.delay method
>> working in
>> > following way:".
>> >
>> > But it's unlikely to happen because TC39 opposes describing
>> communication
>> > with outside world in spec.
>> >
>> > On 16 Nov 2017 1:21 pm, "Naveen Chawla"  wrote:
>> >>
>> >> Wouldn't it be more useful to have an async `delay(milliseconds)`
>> >> function, which simply takes a number (as an alternative to
>> setTimeout),
>> >> instead of having to pass in a function whose code is executed and
>> then the
>> >> code after it??? I have suggested that here before, but it happens to
>> be a
>> >> browser spec feature thing, not a core language thing (at least not
>> yet) -
>> >> since setTimeout itself is not yet in the core language, as far as I
>> know
>> >>
>> >> On Thu, 16 Nov 2017 at 16:50 Eugene Melnikov
>> >>  wrote:
>> >>>
>> >>> It’d be great to see native implementation of `waitFor` function. This
>> >>> function is used a lot in test frameworks and sometimes it’s
>> necessary to
>> >>> wait something via polling. The syntax should be `await
>> >>> waitFor(function/primitives, timeout)`. Once function in first
>> argument
>> >>> return anything except `false`, `null` or `undefined` next line of
>> code will
>> >>> be executed. Second argument means period of time in ms to run
>> function from
>> >>> first argument. Returned value of `waitFor` will be forwarded from
>> executed
>> >>> function. In case first argument if primitive the first argument will
>> be
>> >>> returned after delay specified in second argument. So it will be easy
>> to
>> >>> make simple delay `async waitFor(true, 1000)` instead of `await new
>> >>> Promise(r => setTimeout(r, 1000))`.
>> >>> ___
>> >>> 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
>> >
>>
>
> ___
> 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: Observable GC

[Mark Miller]

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

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).

At least we all already understand that the side channel
information-leakage opened up by SAB is orders of magnitude larger than
that opened up by weakrefs, and so this is not generally raised as an
additional argument against weakrefs for a platform that has already
admitted SAB.

I will start a separate thread on making the computation within an
individual turn more deterministic. SAB aside, the threats to intra-turn
determinism can and should be reduced. All the arguments against
non-determinism in general should be at least as strong against intra-turn
non-determinism specifically.



On Fri, Oct 20, 2017 at 9:54 AM, Dean Tribble  wrote:

> I do think that we need weak references for all the reasons given in the
> proposal. But indeed non-determinism is a concern. The reference Dominic
> pointed at is one of two primary (areas of) considerations. The other is
> just how many amazing things you can do if turns are deterministic (more
> reliable testing, replay debugging, checkpoint/retry in the event of
> component failure, simpler correctness analysis on code, etc.).
>
> Exposing non-determinism only at turn boundaries and controlling access to
> the ability to observe GC both help some with the first motivation above
> (and a lot with the second). However, not enough.  I'm hoping to make
> another run at weakrefs in November with some changes to help concern #1
> further.
>
> On Fri, Oct 20, 2017 at 7:54 AM, Filip Pizlo  wrote:
>
>>
>>
>> > On Oct 20, 2017, at 7:45 AM, Mike Samuel  wrote:
>> >
>> >> On Fri, Oct 20, 2017 at 10:33 AM, Filip Pizlo 
>> wrote:
>> >> For what it’s worth, I have never agreed with this policy. This policy
>> seems
>> >> to be based on feelings not facts.
>> >>
>> >> I remember implementing real time GCs for Java, which changed GC
>> timing and
>> >> behavior a lot, and having zero problem getting that aspect of the GC
>> to
>> >> work well with existing code. It seems like we are using non-problems
>> to
>> >> make excuses to avoid supporting something useful.
>> >>
>> >> In fact, WeakMap is more restrictive constraint on GC algo than weak
>> refs or
>> >> finalization or whatever, since it means that a Siebert-style
>> fine-grained
>> >> incremental GC with O(1) increments is off the table.
>> >
>> > I'm not familiar with Siebert GCs so I apologize if this is beside
>> > your point.   My recollection of those discussions was that we
>> > rejected weak refs in favor of ephemerons because weak references are
>> > still prone to uncollectible cycles that involve a weakly referenced
>> > object being used as both a key and a value.
>>
>> It’s better to have both. Some use cases are not covered by WeakMap, as
>> evidenced by the fact that people still ask for weak refs or a gc trigger
>> or notification.
>>
>> -Filip
>>
>> ___
>> 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: Proxy performance: JIT-compilation?

[Mark Miller]

So from y'all's various implementation perspectives, how does
https://github.com/tvcutsem/es-lab/issues/21 look? Do you think it would
make it easier to achieve much higher performance proxies than we could
without these subtle semantic changes? Or do you think we can as easily
achieve these performance gains with no observable changes at all?

By "subtle", I mean that it is unlikely to affect any normal code.

(Note that, even if the answer is that they don't help, these changes are
still adequately motivated by the cycle-transparency bug. But it would be
good to know.)




On Tue, Aug 8, 2017 at 3:32 PM, Isiah Meadows 
wrote:

> Yes, it's possible to optimize them using specialized ICs on the proxy
> handler itself, but it would be *far* easier to optimize it if the ICs
> weren't necessary in the first place, since you can just build it into
> the proxy's type, almost like a lazily-generated vtable. It's just far
> less work than the otherwise-necessary complex ICs you'd need
> otherwise.
>
> Even though it is in theory possible to optimize such proxies, it's
> pretty complicated to set up, and JS engines aren't exactly magic.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Tue, Aug 8, 2017 at 5:36 PM, Sam Tobin-Hochstadt
>  wrote:
> > On Fri, Aug 4, 2017 at 4:52 PM, Allen Wirfs-Brock 
> wrote:
> >>
> >> On Aug 4, 2017, at 2:22 PM, Mark S. Miller  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.
> >
> > Indeed, this works well in practice with other proxy constructs in
> > other languages -- my collaborators and I have a paper showing this
> > that should be out soon. The only barrier to good proxy performance is
> > implementation work.
> >
> > Sam
> > ___
> > 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: Proxy performance: JIT-compilation?

[Mark Miller]

Alex, I'll just point out that you are already engaged in the best kind of
activity to get implementors to optimize these paths: Building a membrane
library that can get widespread use, which encapsulate the complexity of
proxies behind a more usable API, for which these proxy operations are the
bottleneck. If these costs were sufficient to deter use of your library
this would not be a good strategy. But *many* uses of membranes will be for
cases where membrane crossings are rare compared to direct object-to-object
interaction on either side of the membrane. For most of these, faster
proxies will not matter. But for some of these, proxy performance will not
be enough to deter use, but faster proxies would still produce a noticeably
more pleasant experience.

This is a long term strategy. For the short term, if you can manage it,
make proxy performance significant in some widely used benchmark suite.

None of this is meant to detract from the box of chocolate strategy. Try
everything!



On Fri, Aug 4, 2017 at 4:30 PM, Alex Vincent  wrote:

> So, how many boxes of chocolates do I need to send to the two big vendors
> in Mountain View?  :-)
>
> It's been fifteen years since I seriously tried to profile C++ code, and I
> didn't really know what I was doing back then:  unfamiliar tools, and less
> competence in C++ than I would've liked.  What little knowledge of
> profiling I had back then has long since faded.
>
> Even if I could generate a pretty picture of how long we spent in each
> code path, I wouldn't know how to interpret it.
>
> I recently submitted a patch for improving error reporting in SpiderMonkey
> [1], so I can occasionally dip my toes in the JSAPI code...
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1383630
>
> On Fri, Aug 4, 2017 at 2:52 PM, Allen Wirfs-Brock 
> wrote:
>
>> 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
>>
>
> --
> "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
>
>


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

Re: getOwnPropertyDescriptor side effects

[Mark Miller]

On Thu, Jan 19, 2017 at 10:52 AM, Mark S. Miller  wrote:

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

I meant: the Error.prototype.stack 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
>
>


-- 
  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 Miller]

On Tue, Aug 9, 2016 at 10:58 AM, doodad-js Admin  wrote:

> I think too much validation is not a good idea. Let the proxy lie. If you
> don't, what is the purpose of Proxy?


http://research.google.com/pubs/pub40736.html

Of course, we can still agree that too much, by definition, is not a good
idea ;).




> I have a case where I wanted to force every new property to be read-only
> through a Proxy so that, once created, they can no longer change. But I get
> "TypeError" because of such a validation:
>
> ```js
> "use strict";
> const proxy = new Proxy({}, {
> set(target, property, value, receiver) {
> if (Object.prototype.hasOwnProperty.call(target,
> property)) return false;
> Object.defineProperty(target, property, {configurable:
> false, enumerable: true, writable: false, value: value});
> return true;
> },
> defineProperty(target, property, descriptor) {
> if (Object.prototype.hasOwnProperty.call(target,
> property)) return false;
> descriptor = Object.assign({}, descriptor, {configurable:
> false, enumerable: true});
> if (!descriptor.get && !descriptor.set)
> descriptor.writable = false;
> Object.defineProperty(target, property, descriptor);
> return true;
> },
> });
>
> proxy.a = 1;
> proxy.a = 2; // TypeError: 'set' on proxy: trap returned falsish for
> property 'a'
>
> Object.defineProperty(proxy, 'b', {value: 3});
> Object.defineProperty(proxy, 'b', {value: 4}); // TypeError:
> 'defineProperty' on proxy: trap returned falsish for property 'b'
>

I don't understand the purpose of this code. From your description, don't
you want these TypeErrors? Could you show a hypothetical test case that, if
passed, demonstrates what you are actually trying to accomplish?




> ```
>
> -Original Message-
> From: Claude Pache [mailto:claude.pa...@gmail.com]
> Sent: Tuesday, August 09, 2016 8:44 AM
> To: es-discuss 
> Cc: Mark S. Miller ; Raul-Sebastian Mihăilă <
> raul.miha...@gmail.com>
> Subject: Re: Object.freezing proxies should freeze or throw?
>
> Given a Proxy that pretends to be in state A while its target is
> observably in state B, and assuming that the target satisfies the
> Invariants of the Essential Internal Methods [6.1.7.3], I claim that, in
> order to force the Proxy to satisfy those Invariants, it is necessary and
> sufficient to check that the two following conditions hold:
>
> * it is legal for an object to pass from state A to state B; and,
> * it is legal for an object to pass from state B to state A.
>
> [6.1.7.3]: https://tc39.github.io/ecma262/#sec-invariants-of-
> the-essential-internal-methods
>
>
> Because I am too lazy to write the proof just now, I cowardly leave it as
> an exercice to the reader. Meanwhile, that principle may be used to audit
> the robustness of the Proxy specification. I have found the following bug
> in Proxy.[[Delete]]() by applying the above principle to:
>
> * state A: nonexistent property on a nonextensible object;
> * state B: existent own property on a nonextensible object.
>
> Resurrection of a successfully deleted property on a nonextensible object:
>
> ```js
> var target = Object.preventExtensions({ x: 1 }) var proxy = new
> Proxy(target, {
> deleteProperty() { return true }
> })
>
> Object.isExtensible(proxy) // false
> delete proxy.x // true
> proxy.hasOwnProperty('x') // true
> ```
>
> After a first scan, I haven't found other bugs in the essential methods of
> Proxy, than that one and the missing nonconfigurable-but-writable check in
> [[GetOwnPropertyDescriptor]] and [[DefineOwnProperty]] already mentioned in
> that thread.
>
> I plan to propose a minimal patch (i.e., just adding the missing checks)
> in a few days.
>
> —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: Observing whether a function is strict

[Mark Miller]

I don't get it. What is being removed? What purpose does this accomplish?


On Thu, May 26, 2016 at 4:03 PM, Claude Pache 
wrote:

>
> Le 26 mai 2016 à 13:23, Mark S. Miller  a écrit :
>
>
>
> 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.)
>
>
> Maybe that "leak", namely observing whether a function is strict, is not
> something to care about.
>
> But here is what I think to be a possible way to remove it: Because
> `Function#arguments` and `Function#caller` do return `null` for sloppy
> functions in some circumstances (namely, when the function is not found in
> the call stack), let them always return `null` for non-sloppy functions.
>
> —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: Do await statements unblock synchronously?

[Mark Miller]

Essentially yes. Minor issues inline

On Mon, Apr 11, 2016 at 10:32 PM, /#!/JoePea <j...@trusktr.io> wrote:

> So just to clarify, the code following an await statement should never
> run in the tick in which the await statement is executed, should never
> run in the same tick in which the promise it is awaiting gets
> resolved,


Settled.

If unresolved promise p becomes resolved to unresolved promise q, then p is
resolved but not settled.

If q is then fulfilled or rejected, then q is settled and p is settled in
the same way.


> and so should always run in a 3rd tick separate from those
> other two?
>

It should always run in a tick after the ticks in which those other two
events happen. However, to be fully pedantic, those other two events may
happen in one tick, so the post-await computation, happening after both,
would happen in a second tick.

Btw, I assume your "tick" is equivalent to our "turn" or "job". Tick is not
bad but neither is it clearly better. We should not introduce a third term
since we already have more than we need.



>
> On Mon, Apr 11, 2016 at 1:36 PM, Mark Miller <erig...@gmail.com> wrote:
> > On Mon, Apr 11, 2016 at 9:31 PM, Mark S. Miller <erig...@google.com>
> wrote:
> >>
> >> Not necessarily "the next tick", but some future tick. Definitely not in
> >> this tick or the tick in which the promise is resolved.
> >
> >
> > Meant: "or the tick in which the promise is settled."
> >
> >
> >>
> >> 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 <ljh...@gmail.com>
> 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 <j...@trusktr.io> 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
> >>
> >
> >
> >
> > --
> >   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: Do await statements unblock synchronously?

[Mark Miller]

On Mon, Apr 11, 2016 at 9:31 PM, Mark S. Miller  wrote:

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

Meant: "or the tick in which the promise is settled."



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


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

Re: Error stack strawman

[Mark Miller]

On Wed, Feb 17, 2016 at 5:36 PM, Gary Guo  wrote:

> * isTail will be set when the frame indicates a frame created by tail call
> instead of normal function call. Caller's frame is already removed so we
> need some indication for that to help debugging.
>

Nice


>
> * For span, I put only one pair of line/column there as it is the common
> implementation, but I agree that a starting position and a ending one is
> useful.
>
> * For source, nested frame could be useful but it is not implemented by
> all implementations, and in fact we need an extra field to distinguish eval
> and new Function.
>

For eval vs Function (vs GeneratorFunction, vs AsyncFunction, etc), doesn't
the name inside the nested frame already deal with that?


>
> * By reference to function, I mean that shall we be able to retrieve the
> function object from the frame?
>

No, absolutely not. The stack rep should provide only info, not access.


>
> * I wonder if putting special cases in (), such as (native) will cause any
> problem. No one will have a file called "(native)" in reality, isn't it?
>

If you do this, they will ;)


>
> Gary Guo
>
> --
> Date: Wed, 17 Feb 2016 17:04:39 -0800
> Subject: Re: Error stack strawman
> From: erig...@google.com
> To: nbdd0...@hotmail.com
> CC: es-discuss@mozilla.org
>
>
>
>
> 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 

Re: Calling toString on function proxy throws TypeError exception

[Mark Miller]

Non-membraned proxies are irreparably non-transparent. This case is not
worth worrying about.


On Tue, Oct 27, 2015 at 1:05 PM, Claude Pache 
wrote:

>
> > Le 27 oct. 2015 à 15:52, Mark S. Miller  a écrit :
> >
> > 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.
>
> ... at the condition that the proxy handler explicitly traps the getting
> of the toString method. It is certainly the case for impermeable membranes,
> but not for all proxies. Concretely, `new Proxy(function() {},
> {}).toString()` does throw in ES2015.
>
> —Claude
>
>
> > 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).
> >
> >
> > --
> > Cheers,
> > --MarkM
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Text by me above is hereby placed in the public domain

  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 Miller]

Only because typeof f === 'function' divides the world into callables and
non callables.

On Oct 26, 2015 3:20 PM, "Allen Wirfs-Brock" <al...@wirfs-brock.com> wrote:
>
>
> > On Oct 26, 2015, at 11:20 AM, Mark Miller <erig...@gmail.com> wrote:
> >
> > I like the idea a function proxy is more encapsulating of its
implementation than a function is.
> >
> > I also like the idea of treating a function proxy as a builtin
callable, rather than a function written in JS, and return something like
"function () { [function proxy] }" as Tom suggested or "function () {
[native code] }" as Claude suggested. We need progress on the draft spec
for F.p.toString reform, including the standardized pattern for the
function sources that are not supposed to parse, e.g., "function () {
[...stuff...] }”.
>
> I guess I still don’t understand the use case for applying there built-in
F.p.toString to any callable.  If you are explicitly defining a callable
proxy you may want to define a `toString` method for it that does something
that makes sense for the specific kind of callable you are creating. But
when you expect to do:
>
> ```js
>evalableString = Function.prototype.toString.call(anyOldCallable);
> ```
>
> with the expectation that the result you are going to get will be useful
for anything?

function () { [...] } is how callables I idiomatically give a response that
is not useful for anything. That's all, but it is enough.

>
> Allen
>
___
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 Miller]

I like the idea a function proxy is more encapsulating of its
implementation than a function is.

I also like the idea of treating a function proxy as a builtin callable,
rather than a function written in JS, and return something like "function
() { [function proxy] }" as Tom suggested or "function () { [native code]
}" as Claude suggested. We need progress on the draft spec for F.p.toString
reform, including the standardized pattern for the function sources that
are not supposed to parse, e.g., "function () { [...stuff...] }".



On Mon, Oct 26, 2015 at 1:17 PM, Allen Wirfs-Brock 
wrote:

>
> > On Oct 23, 2015, at 6:43 AM, Claude Pache 
> wrote:
> >
> > Almost every method found on `Function.prototype` "works" (or, at least,
> does not throw a TypeError before trying to work) if and only if the target
> is callable, or if and only if `typeof` applied to the target produces
> `"function"`.
> > That should not be different for `Function.prototype.toString()`. Even
> if "working" means producing a useless string à la `"function () { [native
> code] }"`.
> >
> > —Claude
> >
>
> Right, I should have look closer at the actual spec for  call, apply, and
> blind rather than depending upon memory.  The reason they work on proxies
> is that they only depend upon the MOP API of their this object. In other
> words, they are generic across  all object that have a [[Call]] internal
> method.
>
> Function.prototype.toString is different in that it is dependent upon the
> actual internal structure of the object is is applied to rather than the
> object’s MOP API. This is necessary because F.p.toString must access
> information (the source code of the function or the ability to recreate it)
> that is not available through the MOP.  As I’ve mentioned in earlier
> messages, F.p.toString is in this regard like all other methods that
> directly access private internal state.
>
> F.p.toString could be respecified to explicitly recognize proxies and
> drill through them but it isn’t clear why F.p.toString should be singled
> out from all other private state accessing buiit-in methods in this regard.
>
> But, let’s assume we did make F.p.toString drill through callable
> proxies.  What are the implications.
>
> First remember, that a callable proxy can only be created on a target
> object that already has a [[Call]] internal method. The target might itself
> be a callable proxy, but ultimately the chain of targets must reach an
> object that has a primitive [[Call]] behavior.  This would normally be
> either an ECMAScript function object or a built-in function object.
>
> So, while it is perfectly reasonable to define a callable proxy that, for
> example, in its [[Call]] handler runs a Lisp interpreter over a captured
> S-expression, such a proxy   must either directly or indirectly have as its
> target an ECMAScript function. If you were defining such a proxy where the
> Lisp interpreter is embedded within its [[Call]] handler, you might use
> something like: `function() {}` as the target. If you apply an enhanced
> proxy drill throughing F.p.toString to such a proxy you would get the
> source code for `function() {}`.  How is that useful?
>
> Another way, to implement our Lisp interpreting proxy would be to use as
> the target an ECMAScript function that actually implements the Lisp
> interpreter. In that case, the [[Call]] handler would simply call the
> target function passing the captured S-expression to it as an argument.  If
> you apply an enhanced proxy drill throughing F.p.toString to that sort of a
> proxy you would get back the source code for the Lisp interpreter. This
> seems potentially harmful.  Revealing the source code of the Lisp
> interpreter might reveal exploitable secrets. Heck, the very fact that a
> Lisp interpreter is being used might be a secret.
>
> So, why would we want to do this?
>
> Allen
>
>


-- 
Text by me above is hereby placed in the public domain

  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 Miller]

Ok, that all makes sense and is fine with me. Thanks for clarifying.

Tom, I'm still curious what you remember?


On Thu, Oct 22, 2015 at 2:59 PM, Allen Wirfs-Brock 
wrote:

>
> On Oct 22, 2015, at 11:43 AM, Mark S. Miller  wrote:
>
> 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.
>
>
> There are no such special cases that I’m aware of, and I don’t know how
> they would work. See the proxy [[Call]] internal method
> http://ecma-international.org/ecma-262/6.0/#sec-proxy-object-internal-methods-and-internal-slots-call-thisargument-argumentslist
>
>
> This is basically a coordination issue between the access of a method via
> a proxy [[Get]] and the invocation of the retrieved function via a [[Call].
> Essentially, the creation of a membrane is required to make it work. As I’m
> sure you will recall, we explored using an invoke trap to help deal with
> this sort of situation but eventually abandoned that.  At the time we
> recognized that proxies that only used default handler would not be
> transparent in such situations and decide that it would be ok.
>
> Allen
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Text by me above is hereby placed in the public domain

  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 Miller]

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?



>
> Possible valid uses for the empty placeholder:
>
> - Contents of expression commented out, maybe debugging if it causes side
> effects which may be harmful
> - Expression is a placeholder, with contents soon to come (mentioned by OP)
>
> The DSL thing is a non-issue, because the empty expression didn't need to
> be included in the list of expressions, and if it is included, DSLs can be
> smart enough to deal with it, and should probably be implemented as a
> recursive descent parser on top of the interpolated text anyways
>
> Ease of use, ease of debugging, ease of editing. Users of JS don't make
> the distinction between a Statement and Expression or ExpressionStatement,
> and interpolated strings are very much about strings.
>

A surprising static error is better than a dynamic error that silently
violates programmer expectations. If I saw `${}` and did not know what it
means, I would sooner guess undefined than ''.

Code that matters is read more often than it is written. By making `${}` a
static error, we spare readers the hazard of trying to guess what this rare
edge case would do.



>
> On Oct 22, 2015, at 7:05 PM, Mark S. Miller  wrote:
>
> It is an unnecessary special case. The empty string is a valid statement
> (aside from the semicolon) but not a valid expression. The syntax of what
> appears between the curlies is expression.
>
> Having it default to the empty string makes no sense. Why not 0, false,
> null, or undefined? Remember that template strings can be used to make
> arbitrary objects using any DSL that your tag knows how to parse. There's
> nothing about template strings that is about strings in either the
> substitution values or the result values.
>
> If you want the equivalent of `${''}`, just say `${''}`.
>
>
>
> On Thu, Oct 22, 2015 at 6:31 PM, Caitlin Potter 
> wrote:
>
>>
>> Doesn't necessarily seem like a bad idea. I could be on board with that.
>>
>> > On Oct 22, 2015, at 6:18 PM, Mohsen Azimi  wrote:
>> >
>> > Pardon my lack of use of proper terminology.
>> >
>> > This is kind of annoying working with large template strings. When I
>> leave an interpolation placeholder(what's the right name?) empty it blows
>> up all my code.
>> >
>> > Can it be forgiving like Ruby and CoffeScript and just replace it with
>> empty string?
>> > ___
>> > 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
>
>


-- 
Text by me above is hereby placed in the public domain

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

Re: memory safety and weak references

[Mark Miller]

At
https://esdiscuss.org/topic/memory-safety-and-weak-references#content-1
Dave Herman wrote

> Interestingly, I wonder if the idea of only collecting weak references
> between turns is immune to such attacks, since it's not possible to
> have a bogus reference on the stack between turns, where there is
> no stack.

Sorry it has taken me more than two years to respond to this ;)

If you *actually* GC only between turns, then yes. However, I doubt this is
practical.

If you use the implementation technique shown at
http://wiki.ecmascript.org/doku.php?id=strawman:weak_references
so that you never observably collect during a turn, then no, it doesn't
help.

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

Re: Please help with writing spec for async JSON APIs

[Mark Miller]

+1 for line delimited JSON. It would be good to switch all users of
json-seq over to it and to deprecate json-seq. Perhaps an RFC would help.


On Mon, Aug 3, 2015 at 11:53 PM, Bruno Jouhier bjouh...@gmail.com wrote:

 RFC 7464 has a different format (0x1E at beginning of every record) and a
 different media type (application/json-seq vs application/x-ldjson) than
 line delimited JSON (https://en.wikipedia.org/wiki/Line_Delimited_JSON).
 The 0x1E at the beginning of every record makes it hard to edit these
 files.

 Not sure it will improve interoperability, rather fragment things because
 it is likely that most people will stick to ldjson.

 2015-08-04 1:29 GMT+02:00 Carsten Bormann c...@tzi.org:

 Hi Domenic,

 We have a spec for that: RFC 7464



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

Re: Generalize do-expressions to statements in general?

[Mark Miller]

On Mon, Jul 13, 2015 at 6:53 PM, Isiah Meadows impinb...@gmail.com wrote:

 To be perfectly honest, though, I'm not entirely sure the specifics of the
 do-expression proposal, since Google is failing me here (can't find a thing
 giving more detail than this mailing list). And as for what my proposal
 here is, I forgot to mention that expression statements would be explicitly
 prohibited as the body of a do-expression.

 As for yours, I like it too, except if we keep adding all these extra
 parentheses, we might as well make JavaScript into a Lisp...(well, except
 LispyScript https://lispyscript.com kinda has...) ;)

 In all seriousness, I like your idea as well, but the parsing would have
 to take into account a similar distinction between expressions and other
 statements. And that problem with objects vs blocks would result in a
 similar situation we previously ran into with the same ambiguity (in
 reverse)
 https://esdiscuss.org/topic/may-24-26-rough-meeting-notes#content-3 in
 arrow function syntax. The other issue is that your proposal, because of
 that ambiguity, would likely bring a break in backwards compatibility, one
 that is definitely not worth it:

 ```js
 // Is this a block or object literal?
 let foo = ({ bar: 1 });
 ```


It is an object literal. My proposal is not technically ambiguous, at least
for this case, since I am not proposing we change the current meaning of
({, (function, or (class at all. So, under this proposal, these three
(and the damn sloppy let would need to be called out as special cases.
This is necessary so that this proposal does not change the meaning of
programs that are already syntactically legal.

However, there is a human-factors ambiguity, i.e., a violation of the
principle of least surprise. For (function and (class, the semantic
difference is subtle and would very rarely trip anyone up. Having reduced
the practical hazard to only one special case, we simply need to teach
that, when you wanted to say ({...}) meaning a block, just remove the
curies and say instead (...).

With a bit of lookahead, we can even include labeled statements, since an
expression cannot currently begin with identifier:. So your flip side
of your example becomes

let foo = (bar: 1);

where bar: 1 is therefore a labeled statement. I admit this seems weird,
but perhaps that's only because we're not yet used to it.


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

Re: Template site objects and WeakMap

[Mark Miller]

Hi Yusuke, congratulations and THANK YOU! I learned something important
reading your messages. The notion that we can preserve non-observability
when making one thing a WeakMap iff we make all other WeakMaps be strong
for those same objects is true, novel, and very surprising. I have been
working on such concepts for decades and never come across anything like it.

In this case, I suspect that implementers will continue to choose the
memory leak rather than make WeakMap more complex in this way. But you have
now given them a choice, which is great! The spec does not need to change
to enable this choice. The spec is only about observable differences, and
the space optimization you suggest would be unobservable.

Your observation, being general, may find other applications even if it is
not used to optimize this one. This observation is not language specific;
it may well find application in other memory safe languages including those
yet to be invented. You have added another tool to our toolbox. You have
deepened our understanding of what is possible.




On Tue, Jun 16, 2015 at 10:45 PM, Yusuke SUZUKI utatane@gmail.com
wrote:

 On Wed, Jun 17, 2015 at 2:29 PM, Yusuke SUZUKI utatane@gmail.com
 wrote:

 Thanks. And sorry for the late reply.

 On Wed, Jun 17, 2015 at 11:31 AM, Mark S. Miller erig...@google.com
 wrote:

 Hi Yusuke, I am not sure I understood your message. Could you show some
 example code that would observe the observable difference you have in mind?



 On Tue, Jun 16, 2015 at 7:25 PM, Yusuke SUZUKI utatane@gmail.com
 wrote:

 Hi forks,

 In ES6 spec, template site objects are strongly referenced by the
 realm.[[templateMap]].
 So naive implementation leaks memory because it keeps all the site
 objects in the realm.


 To lookup the identical template site objects, template site objects are
 stored in the realm.[[templateMap]].
 So they are strongly referenced and the naive implementation leaks memory.

 // By writing the following code, we can leak memory that GC cannot
 collect.

 function tag(siteObject)
 {
 return siteObject;
 }

 for (var i = 0;; ++i) {
 eval(tag` + i + `);
 }


 However, we can alleviate this situation.
 Because template site objects are frozen completely, it behaves as if
 it's a primitive value.
 It enables the implementation to reference it from the realm weakly.
 When all disclosed site objects are not referenced, we can GC them because
 nobody knows the given site object is once collected ( re-generated).


 By implementing the realm.[[templateMap]] as WeakMap, we can alleviate
 this situation.

 function tag(siteObject) {
 // Since siteObject is frozen, we cannot attach a property to it.
 // So if nobody has the reference to the siteObject, we can collect
 this siteObject since identity can not be tested across already collected 
 newly created site object.
 }



 But, even if the object is frozen, we can bind the property with it
 indirectly by using WeakMap.
 As a result, if the site objects are referenced by the realm weakly,
 users can observe it by using WeakMap.


 var map = new WeakMap();
 function tag(siteObject) {
 return siteObject;
 }

 var siteObject = tag`hello`;
 map.set(siteObject, true);

 gc();  // If realm.[[templateMap]] is implemente by the WeakMap,
 siteObject will be collected.

 var siteObject = tag`hello`;

 map.get(siteObject);  // false, but should be true.




 To avoid this situation, we need to specially handle template site
 objects in WeakMap; WeakMap refers template site objects strongly (if we
 choose the weak reference implementation for realm.[[templateMap]]).
 But this may complicate the implementation and it may prevent
 implementing WeakMap as per-object table (it can be done, but it is no
 longer simple private symbols).


 var map = new WeakMap();
 function tag(siteObject) {
 return siteObject;
 }

 tag`hello`;

 gc();  // siteObject can be collected because there's no reference to it
 if the [[templateMap]] is implemented as WeakMap.

 var siteObject = tag`hello`;

 map.set(siteObject, true);  // To avoid the previously described
 situation, WeakMap specially handles the siteObject. It is now refereneced
 strongly by the WeakMap.

 gc();

 var siteObject = tag`hello`;

 map.get(siteObject);  // true

 // And if WeakMap is collected, siteObject can be collected.


 Fix.


 var map = new WeakMap();
 function tag(siteObject) {
 return siteObject;
 }

 tag`hello`;

 gc();  // siteObject can be collected because there's no reference to it
 if the [[templateMap]] is implemented as WeakMap.

 (function () {
 var siteObject = tag`hello`;
 map.set(siteObject, true);  // To avoid the previously described
 situation, WeakMap specially handles the siteObject. It is now refereneced
 strongly by the WeakMap.
 }());

 gc();

 (function () {
 var siteObject = tag`hello`;
 map.get(siteObject);  // true
 }());

 // And if WeakMap is collected, siteObject can be collected.
 map = null;
 

Re: RegExp.escape()

[Mark Miller]

Perhaps. I encourage you to draft a possible concrete proposal.


On Sat, Jun 13, 2015 at 11:30 AM, Jordan Harband ljh...@gmail.com wrote:

 Would it help subclassing to have the list of syntax characters/code
 points be on a well-known-symbol property? Like
 `RegExp.prototype[@@syntaxCharacters] =
 Object.freeze('^$\\.*+?()[]{}|'.split(''));` or something? Then @exec could
 reference that, and similarly `RegExp.escape` and RegExpSubclass.escape`
 could reference it as well?

 On Sat, Jun 13, 2015 at 11:07 AM, Mark S. Miller erig...@google.com
 wrote:

 On Sat, Jun 13, 2015 at 9:17 AM, Domenic Denicola d...@domenic.me wrote:

  All of these should be building on top of RegExp.escape :P


 I am not yet agreeing or disagreeing with this. Were both to become std,
 clearly they should be consistent with each other. At the time I wrote
 this, it had not occurred to me that the tag itself might be stdized at the
 same time as RegExp.escape. Now that this possibility has been proposed, I
 am realizing lots of flaws with my polyfill. It's funny how, by considering
 it as leading to a proposal, I quickly saw deep flaws that I was previously
 missing.

 * The big one is that the literal template parts that are taken to
 represent the regexp pattern fragments being expressed should be
 syntactically valid *fragments*, in the sense that it makes semantic sense
 to inject data between these fragments. Escaping the data + validating the
 overall result does not do this. For example:

 const data = ':x';
 const rebad = RegExp.tag`(?${data})`;
 console.log(rebad.test('x')); // true

 is nonsense. Since the RegExp grammar can be extended per platform, the
 same argument that says we should have the platform provide RegExp.escape
 says we should have the platform provide RegExp.tag -- so that they can
 conisistently reflect these platform extensions.

 * Now that we have modules, I would like to see us stop having each
 proposal for new functionality come at the price of further global
 namespace pollution. I would like to see us transition towards having most
 new std library entry points be provided by std modules. I understand why
 we haven't yet, but something needs to go first.

 * ES6 made RegExp subclassable with most methods delegating to a common
 @exec method, so that a subclass only needs to consistently override a
 small number of things to stay consistent. Neither RegExpSubclass.escape
 nor RegExpSubclass.tag can be derived from aRegExpSubclass[@exec]. Because
 of the first bullet, RegExpSubclass.tag also cannot be derived from
 RegExpSubclass.escape. But having RegExpSubclass.escape delegating to
 RegExpSubclass.tag seem weird.

 * The instanceof below prevents this polyfill from working cross-frame.
 Also, when doing RegExpSubclass1.tag`xx${aRegExpSubclass2}yy`, where
 RegExpSubclass2.source produces a regexp grammar string that
 RegExpSubclass1 does not understand, I have no idea what the composition
 should do other than reject with an error. But what if the strings happen
 to be mutually valid but with conflicting meaning between these subclasses?






 *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf
 Of *Mark S. Miller
 *Sent:* Saturday, June 13, 2015 02:39
 *To:* C. Scott Ananian
 *Cc:* Benjamin Gruenbaum; es-discuss
 *Subject:* Re: RegExp.escape()



 The point of this last variant is that data gets escaped but RegExp
 objects do not -- allowing you to compose RegExps:
 re`${re1}|${re2}*|${data}`
 But this requires one more adjustment:


 
function re(first, ...args) {
  let flags = first;
  function tag(template, ...subs) {
const parts = [];
const numSubs = subs.length;
for (let i = 0; i  numSubs; i++) {
  parts.push(template.raw[i]);
  const subst = subs[i] instanceof RegExp ?


`(?:${subs[i].source})` :

  subs[i].replace(/[\/\\^$*+?.()|[\]{}]/g, '\\amp;');
  parts.push(subst);
}
parts.push(template.raw[numSubs]);
return RegExp(parts.join(''), flags);
  }
  if (typeof first === 'string') {
return tag;
  } else {
flags = void 0;  // Should this be '' ?
return tag(first, ...args);
  }
}




 --
 Cheers,
 --MarkM

 ___
 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




-- 
Text by me above is hereby placed in the public domain

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

Re: PerformPromiseAll

[Mark Miller]

On Wed, Jun 10, 2015 at 7:37 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:


 On Jun 9, 2015, at 9:53 AM, C. Scott Ananian wrote:

 On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller erig...@google.com
 wrote:

 Do you ever test that the object returned by `Promise#timeout(n)` is
 something other than a plain promise?


 Responded on the other thread.

 Let's keep this one focused on: do we need to tweak the definitions of
 `Promise.all` and `Promise.race` as they relate to species, and if so: how?

 Option 1: don't consult species at all; Option 2: use species for
 intermediate results, but don't use species for final result; Option 3: you
 tell me!

 Since I'm personally rationalizing away the current behavior as grody but
 acceptable, I'm particularly interested in hearing me, toos (via private
 email to me or Allen) if you think we should make a change.
   --scott


 I agree that the current behavior is grody, but acceptable for
 Promise.all and Promise.race


I agree that it is acceptable. Since we're not going to change it, I
withhold judgement on whether it is goofy ;).




 However, I think that Promise.reject should parallel Promise.resolve and
 hence it should not use species.


I agree.


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

Re: Ideas on type hinting and named parameters

[Mark Miller]

On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison lbljef...@gmail.com wrote:


 Instead, the purpose of initializers outside of the constructor are to
 increase expressivity in a different sense than what I think you meant
 about constructor initialization: It allows initialization that isn't based
 on logic in the constructor to be visually and clearly separate from logic
 that is.


So let's put a visually distinct syntax *in* the constructor. The
constructor is no longer as-if a function in several ways already. In for a
penny, in for a pound.




 It is strictly less expressive for constructor-injected state patterns,



In case I was not clear, I am not for using the current
assignment-in-constructor to pun initializing in constructor, the way Java
does. Initialization and assignment should be distinct. Const private
instance fields must be initialized but must not be assigned to.



 but it is strictly more expressive for other patterns of initialization.


What do you have in mind?


  I'm wary of adding syntax whose primary motivation is to express type
 constraints, when we haven't even defined (or proposed) what typing in JS
 means.



 ___
 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




-- 
Text by me above is hereby placed in the public domain

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

Re: Fixing `Promise.resolve()`

[Mark Miller]

Independent of the current issue, I just want to go on record stating that
dynamically scoped variables are a cure worse than any disease we might
think to apply them to. Avoid at all costs.


On Wed, Jun 10, 2015 at 8:44 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:

 I don't agree that @@species is useful at all for changing constructor
 signatures, since there is no closure argument.

 If we had dynamically scoped variables, then:
 ```
   LabelledPromise[Symbol.species] = function() { return
 LabelledPromise.bind(label/*dynamically scoped*/); };
   function() {
 let label = foo;
 return LabelledPromise.resolve(x);
   }
 ```
 would indeed be very interesting.  But in the absence of some sort of
 closure, the only way you can make @@species into a custom constructor is
 for odd special cases where you are just rearranging deck chairs.

 Why not:
  ```
 class LabelledPromise {
   constructor(exec, label) {
 super(exec);
 this.label = label === undefined ? derived promise : label;
   }
 }
 ```
   --scott


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




-- 
Text by me above is hereby placed in the public domain

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

Re: When the only tool you have is subclassing, all extensions look like....

[Mark Miller]

I don't understand your answer. p and r are plain promises. They must be
because they exist before q does. q is the first remote promise in this
scenario. How does resolving r to q leave r unsettled but give q access to
the messages buffered (and to be buffered) in r?

I think the answer must involve the to-be-defined behavior of .get, .put,
.post, .delete, and .where. These should be in bed with the implementation
of the built-in promise resolve, so that when r is resolved to q, if q is a
genuine promise (whatever that means in this new world), then r should
migrate its messages there.

However, to implement this on ES6 without monkey patching would require
intervening in the internal resolving of r while still leaving r unsettled.
If q intervenes by overriding .then, this does give it control during the
resolution. But it doesn't give it access to r with which the buffered
messages is associated.

I don't get it.





On Tue, Jun 9, 2015 at 11:20 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:

 On Tue, Jun 9, 2015 at 1:43 PM, Mark S. Miller erig...@google.com wrote:

 On Tue, Jun 9, 2015 at 10:38 AM, C. Scott Ananian ecmascr...@cscott.net
  wrote:

 I think that Promise pipelining works just fine -- you just have to
 implement it inside Promise#get, Promise#put, etc.
 ```
 // This is already in prfun
 Promise.get = function(fieldname) { return this.then(function(o) {
 return o[fieldname]; }); };
 // This comes with your RPC mechanism
 class RemoteObjectPromise extends Promise {
   this(args...) {
 let res, rej;

 if (typeof(args[0]) !== 'string') throw new TypeError(Not a remote
 reference!);

 super((a,b)={res=a;rej=b;});
 this.handle = gensym();
 // first argument to rpcCall is destination of the operation
 rpcCall(this.handle, ...args).then( v = res(v), e = rej(v) );
   },

   get(fieldname) {

// note that this.handle is a name for the remote object, it is not a
 resolved value.
// as such, this method doesn't have to wait until the remote object
 corresponding to
// this.handle is resolved
return new RemoteObjectPromise('GET', this.handle, fieldname);

   }

 }
 ```

 What about the interaction between q and r in .then, that I mentioned in
 my previous email? That's the reason I changed my mind and now think we
 need an extension mechanism besides subclassing in order to make pipelining
 work. Note: it needs to work even if p is a plain promise. It is only q
 that knows that the scenario is special.


 Oh, right, I forgot:
 ```
 RemoteObjectPromise[Symbol.species] = Promise;
 ```

 That takes care of `then()`...

 And provides another nice use case for species.

 What would you expect `RemoteObjectPromise.all()` to do in this case?

 Probably `RemoteObjectPromise.prototype.all()` makes more sense -- if you
 have a remote reference to a (promised) array, you can pipeline the wait
 for all the elements in the array, without having to do all the waits on
 the client side.

 But in this case `RemoteObjectPromise.prototype.all()` is probably
 special-cased (and ignores species):
 ```
 RemoteObjectPromise.prototype.all = function() {
   return new RemoteObjectPromise('ALL', this.handle);
 };
 // And this is what I claim that `Promise.all` should also be:
 RemoteObjectPromise.all = function(x) { return this.resolve(x).all(); };
 ```

 Note that, given the definition above (I've tweaked it slightly),
 `RemoteObjectPromise.resolve(x)` throws TypeError if `x` is not already a
 remote object reference.  You could tweak it to perform a migration or some
 such if you preferred.
   --scott

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




-- 
Text by me above is hereby placed in the public domain

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

Re: Subclassing ES6 objects with ES5 syntax.

[Mark Miller]

Just to close the loop on this, regarding the main point I remain convinced
and would be happy to champion. Again, thanks for pushing on this.

More later

-- 

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

Re: super.prop assignment can silently overwrite non-writable properties

[Mark Miller]

Yes. The problem is not that DefineOwnProperty is not acting more like
assignment. The problem is that super.prop = x; is acting too much like
DefineOwnProperty and too little like assignment.


On Tue, Apr 21, 2015 at 3:54 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:


 On Apr 20, 2015, at 5:28 PM, Caitlin Potter wrote:

  It makes perfect sense for Object.defineProperty, but maybe not so much
 sense for PutValue(). One idea was to just add an `return false if
 existingDescriptor.[[Writable]] is false.` Before
 receiver.[[DefineOwnProperty]]()`.

 yes, something like that.  I'm working on the fix right now.  But it's
 probably more complicated then that.  Consider what happens if the Receiver
 already has an like-named own accessor property...

 I think in that case it needs to fail. Otherwise, the current algorithm
 will turn the accessor property into a data property, which seems even more
 bogus then the ignore writable behavior.

 Allen







 
  On Apr 20, 2015, at 8:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:
 
 
  On Apr 20, 2015, at 12:42 PM, Caitlin Potter wrote:
 
  Oh — he’s right, ValidateAndApplyPropertyDescriptor won’t throw in the
 example case, because the old descriptor is configurable. That’s kind of
 weird.
 
  It is kind of weird, but that was what TC39 decided on back when ES5
 was being developed.  The logic was that if a property is configurable then
 it is possible to change all of its attributes  by performing a
 [[DefineOwnProperty]] with a complete property description.   Because of
 that possibility, all changes made via a partial property descriptor are
 also accepted.  In other words:
 
  var o = Object.create(null, {x:{value: 0, writable: false, enumerable:
 true, configurable:true}});
  Object.defineProperty(o,' x', {value:2});
  console.log(o.x); //2
 
  The define property above is allowed because it could have been
 replaced with the sequence :
  Object.defineProperty(o,'x', {writable: true});
  Object.defineProperty(o,'x', {value: 2, writable: false});
 
  or even by:
  delete o.x;
  Object.defineProperty(o,'x', {value: 2, writable: false, enumerable:
 true, configurable: true};)
 
  hence, we might as well accept the single line version.
 
  In retrospect, perhaps not such a good idea.
 
  Allen
 
 
 
 




-- 
Text by me above is hereby placed in the public domain

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

Re: Putting `global` reference in specs

[Mark Miller]

This is one of several cases where, post ES6, we can provide a std module
import that provides a built-in that carries authority. Another example is
the constructor for making weak references, which necessarily provide the
ability to read a covert channel. As with shadowable globals, this module
import must be easy to virtualize. We purposely postponed this along with
the Loader and Realm API as it is security sensitive and we don't yet have
enough usage experience with modules to know how to design this separation
well.

In particular, we rejected the obvious Reflect.global as it bundles the
global together with authority-free safe things, which makes virtualization
of the global alone needlessly unpleasant.



On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang curvedm...@gmail.com wrote:

 You guys are talking about referencing the global object in modules right?
 Since in scripts you can reliably get hold of the global object by using
 this in the root scope.

 And es 2015 made an explicit choice to clobber this in the root scope of
 a module, I guess that means module code really isn't supposed to get hold
 of the global object?

 On Apr 17, 2015, at 11:34 PM, Mark S. Miller erig...@google.com wrote:

 I almost omitted it, but one should never need to encounter or think about
 sloppy code unless absolutely necessary. For my brain, adding the use
 strict; makes this snippet of code much simpler.


 On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg rossb...@google.com
 wrote:

 On 17 April 2015 at 17:27, Mark S. Miller erig...@google.com wrote:

 (1,eval)('use strict; this')


 Is the 'use strict' relevant here? Seems overkill.

 /Andreas




 On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

 there's actually no way, officially, to reference what ES2015 call *the
 global object*, just pointless fragmentation between engines.



 On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
 andrea.giammar...@gmail.com wrote:
  So I'd say we should not have `self` (if stays on global and Worker
 I don't
  actually care) and add a `global` that nobody needs explanation to
  understand what it is in JavaScript

 Indeed, three ways to reference the global object is not nearly enough.


 --
 https://annevankesteren.nl/



 ___
 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



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




-- 
Text by me above is hereby placed in the public domain

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

Re: Converting strings to template strings

[Mark Miller]

The pattern  [\S\s]*? admits a lot. Why are you confident that it can't
contain a string that, for example, closes the function with an unbalanced
}, then  has an evil expression which evaluates, followed by an
unbalanced { so the whole thing still parses?

On Sun, Mar 22, 2015 at 7:38 AM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 Hi Mark, thanks for pointing that out but if I understand the problem
 correctly then the snippet I've suggested concatenates strings and will
 never produce those problematic syntax errors. Can I say it's still safe?
 Or do you think it might have some problem in Safari?

 Cheers

 On Sun, Mar 22, 2015 at 11:28 AM, Mark S. Miller erig...@google.com
 wrote:



 On Sun, Mar 22, 2015 at 6:46 AM, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

 There's no such functionality indeed but you might want to have a look
 at this gist: https://gist.github.com/WebReflection/8f227532143e63649804

 It gives you the ability to write `'test1 ${1 + 2} test2 ${3 + 4}'
 .template();` and read `test1 3 test2 7` or to pass an object similar
 to .Net String.format so that your Stack overflow code would be like the
 following:

 ```js

 let a = b:${b};
 let b = 10;

 console.log(a.template({b:b}));

 // or

 console.log(a.template({b:27}));

 ```

 You pass named properties and it works with nested properties too (i.e.
 ${down.the.road})

 It does use Function which is safe,



 Function is safe almost everywhere, but it is worth pointing out

 https://bugs.webkit.org/show_bug.cgi?id=106160
 https://bugs.webkit.org/show_bug.cgi?id=131137
 test_CANT_SAFELY_VERIFY_SYNTAX at
 https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#3198
 repair_CANT_SAFELY_VERIFY_SYNTAX at
 https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#4170

 After the repair, the Function constructor is safe again on Safari, but
 at considerable expense.




 compared to eval, and needed to eventually de-opt from 'use strict' but
 of course you could write your own parser avoiding Function completely.

 Finally, I agree it would be nice to be able to have a standard way to
 template strings in JS, the templating as it is plays very poorly with
 runtime generated strings, using eval for that looks the dirtiest thing on
 earth.

 Regards



 On Sun, Mar 22, 2015 at 10:05 AM, KOLANICH kola...@mail.ru wrote:

 I needed a functionality but haven't found it.
 See
 https://stackoverflow.com/questions/29182244/convert-a-string-to-a-template-string
 for more details.
 I think that this should be included into standard;


 Also we need a standard format string functionality like
 https://msdn.microsoft.com/en-us/library/system.string.format.aspx and
 https://docs.python.org/2/library/string.html#string-formatting
 https://docs.python.org/2/library/string.html#string-formatting

 ___
 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




-- 
Text by me above is hereby placed in the public domain

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

Re: Module import/export bindings

[Mark Miller]

Story is way too simple. JS const means constant, unchanging. By contrast,
import bindings, like const in C++, means read-only view. This is *very*
different from constant.

Don't use the const analogy when changes are still observable.


On Mon, Mar 16, 2015 at 9:20 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:


 On Mar 15, 2015, at 9:43 PM, Domenic Denicola wrote:

  From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
 Kyle Simpson
 
  Would it then be appropriate to explain that conceptually the binding
 would otherwise indeed be 2-way, but that the immutable/read-only nature of
 the bindings is what prevents an outside mutation of a module's internals?
 That is, without such bindings (and errors), a module could be changed from
 the outside?
 
  I wouldn't really find this an appropriate explanation. That's kind of
 like saying this building's 6th story would be blue, but the 5-story
 nature of its blueprints is what prevents you from accessing the 6th
 story. There just isn't any 6th story at all. (Similarly, there just isn't
 any defined [[Set]] behavior for module namespace objects at all. You could
 make up a plausible one, like pretending it would modify the original
 module's bindings, and write a revisionist history in which it was removed.
 But that's not really how the spec works.)

 the simple story:

 imported bindings are all `const` bindings.  Think of them as if if they
 were written

 ```js
 const import {a,b,c} from foo;
 ```

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




-- 
Text by me above is hereby placed in the public domain

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

Re: Maximally minimal stack trace standardization

[Mark Miller]

On Wed, Mar 11, 2015 at 6:31 PM, John Lenz concavel...@gmail.com wrote:

 I'll retract that suggestion having tried to write an argument for it.


Thanks.



   It sad though, removing stack isn't really an option.



a) It has never been added, in the sense that it does not appear in the
std.
b) It differs so wildly between platforms that cross-web content can't rely
on it.
c) We removed .caller, .callee, and .arguments. I'm sure that in 2007
many would have bet that we never could.

A further point about selectively providing or denying getStack: Something
that's acting like a console typically needs the privilege of extracting
stacks from thrown errors. The callers of the console almost never do.
Rather, the typical pattern is they pass the errors to the console as
method arguments. They may know that the error contains a stack, and their
purpose in passing it may be to show that stack to the user/programmer, but
it is very rare that they ever look at the stack themselves.

https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/useHTMLLogger.js

uses exactly this pattern to create a somewhat console-like display on a
normal html page, having been granted the getStack ability that its
caller's typically don't get. It's really just a special case of the
general principle that debugging tools are typically granted more privilege
with respect to the computation being debugged than the objects within that
computation are.






 On Wed, Mar 11, 2015 at 12:03 PM, Mark S. Miller erig...@google.com
 wrote:

 I don't understand. Could you show example code? Thanks.



 On Wed, Mar 11, 2015 at 12:00 PM, John Lenz concavel...@gmail.com
 wrote:



 On Tue, Mar 10, 2015 at 9:10 PM, Mark S. Miller erig...@google.com
 wrote:

 On Tue, Mar 10, 2015 at 9:02 PM, Domenic Denicola d...@domenic.me wrote:

  I don’t see how any of this follows. SES can censor/remove/etc.
 either the .stack getter or the .getStack function. They are isomorphic.


 I can selectively provide or deny a given getStack function to
 different code in the same realm.


 Can't you do the same by hiding Error in the same way that window is
 hidden?  Through a proxy or subclass?






 .stack already has very close to de-facto standard behavior.


 Have you looked at the case analysis I go through in debug.js to parse
 the variety of stack formats we currently have?



 We should be attempting to converge it to a standard, and not leaving
 it a non-interoperable mess while adding a second API.



 I also don’t see why .stack cannot map backward through different
 source maps. Again, a getter and a function are isomorphic in this regard.


 In a given realm, there can only be one Error.prototype.stack. But what
 getStack function is in scope can differ per scope as well as per loader.





 *From:* Mark S. Miller [mailto:erig...@google.com]
 *Sent:* Wednesday, March 11, 2015 12:12
 *To:* Domenic Denicola
 *Cc:* John Lenz; es-discuss; Erik Arvidsson

 *Subject:* Re: Maximally minimal stack trace standardization



 No, that makes the std SES API non-conformant to the std API, making
 porting more difficult, and making it harder to write code that works in
 both environments.



 Also, if you make it look like err.stack, then no matter what you
 stdize, it will conflict with existing err.stack behavior, since they
 conflict with each other. This makes the transition more difficult. If the
 new std behavior looks like getStack(err), then it can be rolled out
 without creating a transition conflict.



 As so often happens, the better security is the better modularity. If
 you make it err.stack, then you have to make visible one canonical mapping
 to source positions. If you make it getStack(err), then different getStack
 functions might map backwards through different sourcemaps.







 On Tue, Mar 10, 2015 at 7:45 PM, Domenic Denicola d...@domenic.me
 wrote:

  Can’t we just have Error.prototype.stack be a getter that SES is
 allowed to delete and hide away for its own purposes later?



 *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf
 Of *John Lenz
 *Sent:* Wednesday, March 11, 2015 08:35
 *To:* Mark S. Miller
 *Cc:* es-discuss; Erik Arvidsson
 *Subject:* Re: Maximally minimal stack trace standardization



  Ok, as long as we are clear there is an existing information leak on
 non-v8 engines.





 On Tue, Mar 10, 2015 at 1:48 PM, Mark S. Miller erig...@google.com
 wrote:

  On Chrome and Opera (v8), 
 https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js
 hides the stack. It is important that we not lose this.



 Regarding the rest, as previously discussed, there are enough
 differences between browsers that there is no legacy we must codify 
 because
 of web-wide agreement. Take a look at the extensive efforts 
 https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js
 makes to parse despite these differences in stack format. As 

Re: Class double-bind

[Mark Miller]

Hi Kevin,

If it were just a question of non-const-classes being too mutable, well,
they're everywhere already ridiculously too mutable in line with most
things in JS. It would be coherent to wait for const classes to repair the
mutability of the binding at the same time it repairs the mutability of the
prototype chain, etc.

However, the double-binding issue makes this weirder. If non-const-class
declarations were like non-const-function declarations, where there is only
one binding per defining occurrence, then I would fully agree. But this
issue of one defining occurrence creating two bindings that can diverge is
a new level of unpleasantness. I agree this calls for the issue to be fixed
now in ES6 if we can, for non-const-classes.




On Thu, Mar 5, 2015 at 8:46 AM, Kevin Smith zenpars...@gmail.com wrote:

 Just to be clear, this would make class declarations behave differently
 from builtins, both the ES kind and the IDL kind, right?

 I'm not saying that's a problem necessarily, but worth keeping in mind.


 Good point.  I think that we need to be looking ahead toward const class,
 and leave ES6 class declaration bindings as is.


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




-- 
Text by me above is hereby placed in the public domain

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

Re: Proposal: Additional Meta Properties for ES7

[Mark Miller]

On Mon, Mar 2, 2015 at 9:30 AM, John Lenz concavel...@gmail.com wrote:

 I was recently discussion Promise optimizations (specifically, that in any
 then chain at least one Promise object is created that goes unused), this
 could be solved by some metadata that indicated whether the result of the
 function would be consumed:

 Promise.prototype.then = function(a, b) {
...
if (function.called_from_void_result_context) {
  return undefined;
}
/* current behavior */
...
 };


More controversially, we might consider


if (function.called_from_void_result_context) {
  /* proposed .done behavior */


I'm not sure what I think of this. It is kinda scary, but it might be the
right thing.






 // example

 somePromise.then(); // no chaining promise created by then

 var x = somePromise.then(); // chaining promise created
 x.then(); // no chaining promise created

 I'm not really sure what impact this would have on the VMs but I found it
 an interesting idea.









 On Thu, Feb 26, 2015 at 2:47 PM, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:

 Here is a new proposal for some additional meta properties that should be
 considered for ES7
 https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md

 I've added this to the agenda for next months TC39 meeting but
 pre-meeting discussion is always welcomed right here.

 Allen


 ___
 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




-- 
Text by me above is hereby placed in the public domain

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

Re: Proposal: Additional Meta Properties for ES7

[Mark Miller]

On Mon, Mar 2, 2015 at 10:45 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:


 On Mar 2, 2015, at 9:30 AM, John Lenz wrote:

  I was recently discussion Promise optimizations (specifically, that in
 any then chain at least one Promise object is created that goes unused),
 this could be solved by some metadata that indicated whether the result of
 the function would be consumed:
 ...
 if (function.called_from_void_result_context) {
  ...
  I'm not really sure what impact this would have on the VMs but I found
 it an interesting idea.

 Essentially, this means that an additional implicit parameter
 (calledForValue) needs to be added for every function call.  At the MOP
 level this would manifest as an extra argument to the [[Call]] internal
 method.  It could be defined to default to true and implementation could
 probably optimize for the default case.  But, at least conceptually it
 requires passing additional information across the call boundary.  that
 might be a bit much if this is only about optimizing promises.


Allen, sadly, I expect you are correct about this.

Infix ! could, nevertheless, statically expand to .send or .sendOnly
depending on static syntactic context, without any further runtime
implication, as in E.

But .then, being a normal method call rather than distinct when syntax,
would not be able to gain a similar benefit.


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

Re: Function name property

[Mark Miller]

Why do arrow functions need to reflect on themselves? I think it is more
useful for all code directly inside a non-arrow function to be able to
reflect on that non-arrow function. If I wrote an arrow function and then
found I wanted it to reflect on itself, I'd be happier rewriting it as a
non-arrow function than I would with either
* the complexity of a whole new set of special forms for arrow functions to
reflect on themselves, or
* (as in the original proposal) making it more difficult for code in an
arrow function to reflect on their containing non-arrow function.



On Fri, Feb 27, 2015 at 8:00 AM, Rick Waldron waldron.r...@gmail.com
wrote:



 On Thu Feb 26 2015 at 8:22:55 PM Claude Pache claude.pa...@gmail.com
 wrote:


  Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock al...@wirfs-brock.com a
 écrit :
 
 
  On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
  For most of these, my first reaction is meh. They all make sense and
 violate no principle, but are they worth it?
 
  I do not like the arrow function behavior. For anything named
 function.something occurring within an arrow function, I'd expect it to be
 about the lexically enclosing non-arrow function. I do not object to the
 idea that there be such a special form that is about the arrow function,
 but it needs to be spelled differently. I have no concrete suggestion
 though.
 
  We have to work with the reserved words we have available,  there
 really need to apply equivalently to all functions, arrow or otherwise
 defined.  The only other available keyword that seems at all suggest of
 these use cases is 'in'
 
  in.callee  (or whatever)
  in.count.
  in.arguments
 
  If we went that route I'd probably still stick with 'function.next' for
 that use case
 
  Allen

 That one has just popped in my mind :-)

 =.arguments


 I was thinking exactly this while I was reading Allen's post.

 Would class method definitions use `class.*`? Seems like the wrong
 abstraction..? Maybe all functions and method definitions use `function`,
 while arrows use `=` (or whatever) to preserve correspondence to
 possible outer function?

 Rick

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




-- 
Text by me above is hereby placed in the public domain

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

Re: Global method calls

[Mark Miller]

There, Boris writes:
 Conceptually, using the global of the realm of the function involved
 (i.e. the Chrome/Firefox/IE10 behavior) makes sense to me.

Me too. This is in keeping with the spirit of lexical scoping. It is as if
these built-in functions have lexically captured the global of the realm of
their creation, and use that. Besides throw, any other answer would be
too much magic and (at least) hard to explain. Also, this aligns with the
global capture of sloppy functions.





On Sun, Feb 22, 2015 at 2:05 PM, Domenic Denicola d...@domenic.me wrote:

 From: Mark Miller [mailto:erig...@gmail.com]

  the ECMAScript global object? Which one? (Even if it is clear from
 context, please assume I do not have that context.)

 Heh; good catch. A contemporary thread to my [1] is
 https://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0658.html,
 which debates that very question.




-- 
Text by me above is hereby placed in the public domain

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

Re: Global method calls

[Mark Miller]

On Sun, Feb 22, 2015 at 1:03 PM, Domenic Denicola d...@domenic.me wrote:

 (Cc'ing public-script-coord in case this answer gets more complicated in
 the presence of the window proxy/overriden this-in-global setup.)

 Given code like

 script
   addEventListener(foo, function () { });
 /script

 Is this supposed to be an Invoke(current global, addEventListener,
 foo, function () {})?

 Or is it just a Call(addEventListener, undefined, foo, function () {})?

 What about if I added use strict; to the top of the script?



If it is strict code, then this is definitely a
Call(addEventListener, undefined, foo, function () {})

I won't try to speak definitively for what happens if the code above is
sloppy. But I believe the answer is the same. If the receiver is sloppy, it
is up to it to promote an undefined this-binding to its realm's global
object. As a builtin, it is neither strict nor sloppy, and its spec should
state what it does with an undefined this-binding.



 My suspicion was Invoke, but then I came up with another example that
 threw me off:

 script
 window.globalFunc = function () {
 console.log(this, this);
 };
 /script

 script
 use strict;
 globalFunc();
 /script

 This gives `undefined`. (The result is the same if I also prepend use
 strict; to the top of the first script.)



It is quite bizarre that you also get undefined when you don't prepend use
strict to the first script. globalFunc should then be sloppy. A sloppy
function should never see its this bound to undefined, or indeed to any
non-object value. I do not understand what might be going on here.

Regarding the second script, since you're calling globalFunc as a function
from strict code, you are passing a this-binding of undefined, even though
globalFunc is a global function.



 That nudges me toward the Call answer.

 But under the Call answer, my first example would be broken since the
 implementation of `addEventListener` would not have a sensible `this` to
 operate on.


If addEventListener was sloppy, it would promote the this-binding to the
global of the realm it was defined in. As a builtin, it is neither strict
nor sloppy, and its spec should state what it does with an undefined
this-binding.



 Anyway, I'm clearly missing something. What is it, and where are the
 relevant parts of the spec?


I remember where they were in ES5. I am also curious where to find this in
ES6.




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

Re: Global method calls

[Mark Miller]

https://heycam.github.io/webidl/#ImplicitThis says:

If the [ImplicitThis] https://heycam.github.io/webidl/#ImplicitThis extended
 attribute https://heycam.github.io/webidl/#dfn-extended-attribute appears
 on an interface https://heycam.github.io/webidl/#dfn-interface, it
 indicates that when a Function corresponding to one of the interface’s
 operations https://heycam.github.io/webidl/#dfn-operation is invoked
 with thenull or undefined value as the this value, that the ECMAScript
 global object will be used as the this value instead. This is regardless
 of whether the calling code is in strict mode.


the ECMAScript global object? Which one? (Even if it is clear from
context, please assume I do not have that context.)




On Sun, Feb 22, 2015 at 1:55 PM, Domenic Denicola d...@domenic.me wrote:

 OK, I think I might be on the trail of this one.

 [1] indicates a plan to make [Global]-annotated objects, like the Window
 object, apply [ImplicitThis] behavior to the object's methods and the
 methods of anything that shows up in its prototype chain. [ImplicitThis]
 behavior is defined at [2], and does exactly what we need, i.e. makes calls
 with undefined `this` get translated into calls with the window.

 However, the plan at [1] seems to be only half-executed, in that Window
 defined at [3] does not have [ImplicitThis], but the definition of
 [PrimaryGlobal] and [Global] at [4] does not imply [ImplicitThis] behavior.
 Due to this half-way state, [ImplicitThis] seems to be dead code, as
 evidenced by [5].

 If I am indeed reading the situation correctly, I think the spec-level fix
 is to either implement the plan in [1], or to put [ImplicitThis] (back?) on
 the globals *and* on EventTarget. I actually prefer the latter, since the
 way in which tagging [Window] as a [Global] implicitly makes EventTarget,
 defined in another spec, take on [ImplicitThis] behavior, seems hard to
 follow.

 [1]:
 https://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0657.html
 [2]: https://heycam.github.io/webidl/#ImplicitThis
 [3]: https://html.spec.whatwg.org/multipage/browsers.html#window
 [4]: https://heycam.github.io/webidl/#Global
 [5]:
 https://www.google.com/search?q=ImplicitThis+site%3Awhatwg.orgie=utf-8oe=utf-8#q=%2BImplicitThis+site:whatwg.org

 -Original Message-
 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
 Domenic Denicola
 Sent: Sunday, February 22, 2015 16:39
 To: Mark Miller
 Cc: public-script-co...@w3.org; es-discuss@mozilla.org
 Subject: RE: Global method calls

 Thanks Mark. At this point it may tend toward more of a
 public-script-coord question...

 From: Mark Miller [mailto:erig...@gmail.com]

  If it is strict code, then this is definitely a Call(addEventListener,
  undefined, foo, function () {})
 
  I won't try to speak definitively for what happens if the code above is
 sloppy. But I believe the answer is the same. If the receiver is sloppy, it
 is up to it to promote an undefined this-binding to its realm's global
 object. As a builtin, it is neither strict nor sloppy, and its spec should
 state what it does with an undefined this-binding.

 The added weirdness here is that addEventListener is actually a method of
 EventTarget, which Window derives from. (And then, of course, the window
 proxy masks direct access, at least when you do
 `window.addEventListener`---but apparently the window proxy is not involved
 in my case.)

 The spec for addEventListener [1] doesn't mention what to do with an
 undefined `this` binding. Although the language is of the typical
 imprecise-DOM-spec-type, as far as I can tell it assumes that its `this` is
 always an `EventTarget` instance, which then has an associated list of
 event listeners it operates on.

 At this point I must imagine that there is some special handling taking
 place somewhere else in the web ecosystem, possibly in WebIDL, that will
 ensure addEventListener (and possibly any other method?) will use the
 global window (but not the window proxy?) when called with undefined
 `this`. I don't know where to find that, though: I looked through [2]
 without much luck, and Ctrl+Fing for [[Call]] throughout WebIDL does not
 give anything fruitful.

 [1]: https://dom.spec.whatwg.org/#dom-eventtarget-addeventlistener
 [2]: https://heycam.github.io/webidl/#Global

  It is quite bizarre that you also get undefined when you don't prepend
 use strict to the first script. globalFunc should then be sloppy. A
 sloppy function should never see its this bound to undefined, or indeed
 to any non-object value. I do not understand what might be going on here.

 You are right; please disregard this part. I don't get undefined in the
 given example---only when adding use strict to both.

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




-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

[Mark Miller]

On Thu, Feb 19, 2015 at 12:14 PM, Axel Rauschmayer a...@rauschma.de wrote:

 However, you can’t freeze `Array.prototype`

 We do.


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

Re: @@toStringTag spoofing for null and undefined

[Mark Miller]

On Sat, Jan 24, 2015 at 2:42 PM, Isiah Meadows impinb...@gmail.com wrote:

  From: Mark S. Miller erig...@google.com
  To: Gary Guo nbdd0...@hotmail.com
  Cc: es-discuss@mozilla.org es-discuss@mozilla.org
  Date: Sat, 24 Jan 2015 07:11:35 -0800
  Subject: Re: @@toStringTag spoofing for null and undefined
  Of course it can, by tamper proofing (essentially, freezing)
 Object.prototype. None of these protections are relevant anyway in an
 environment in which the primordials are not locked down.

 Yeah, pretty much. That proverbial inch was given a long time ago. And the
 proverbial mile taken. And I highly doubt the spec is going to require
 `Object.freeze(Object.prototype)`,

Of course not. The key is the spec allows it. SES makes use of that.





 since that prohibits future polyfills and prolyfills of the Object
 prototype. Also, you could always straight up overwrite it, but that's even
 harder to protect against. (And how many cases do you know of literally
 overwriting built-in prototypes?)

 Or, to throw out an analog to Java, it is perfectly possible to call or
 even override a private method through reflection. JavaScript simply has
 more accessible reflection, more often useful since it's a more dynamic
 prototype-based OO language as opposed to a stricter class-based language.

 
  On Sat, Jan 24, 2015 at 6:11 AM, Gary Guo nbdd0...@hotmail.com wrote:
 
  Now I have a tendency to support the suggestion that cuts the
 anti-spoofing part. If coder wants to make an object and pretend it's a
 built-in, let it be. The anti-spoofing algorithm could not prevent this
 case:
  ```
  Object.prototype.toString = function(){
return '[object I_Can_Be_Anything]';
  }
  ```
 

 Or this:
 ```js
 function handler() {
   throw new Error(No prototype for you!);
 }

 Object.defineProperty(
   Object,
   'prototype',
   {
 get: handler,
 set: handler,
 enumerable: true
   });
 ```

 Me thinks this isn't going to get fixed.

  ___
  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




-- 
Text by me above is hereby placed in the public domain

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

Re: @@toStringTag spoofing for null and undefined

[Mark Miller]

Actually, I withdraw that last sentence. Such protections are relevant as
well in some specialized circumstances in which the trusted code runs first
and squirrels away the relevant primordials such as
Object.prototype.toString before it can be corrupted. Extra care is needed
to avoid using it later as savedToString.call(obj) since that would leave
it open to poisoning of Function.prototype.call.

See http://wiki.ecmascript.org/doku.php?id=conventions:safe_meta_programming




On Sat, Jan 24, 2015 at 7:11 AM, Mark S. Miller erig...@google.com wrote:

 Of course it can, by tamper proofing (essentially, freezing)
 Object.prototype. None of these protections are relevant anyway in an
 environment in which the primordials are not locked down.

 On Sat, Jan 24, 2015 at 6:11 AM, Gary Guo nbdd0...@hotmail.com wrote:

 Now I have a tendency to support the suggestion that cuts the
 anti-spoofing part. If coder wants to make an object and pretend it's a
 built-in, let it be. The anti-spoofing algorithm could not prevent this
 case:
 ```
 Object.prototype.toString = function(){
   return '[object I_Can_Be_Anything]';
 }
 ```

 ___
 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




-- 
Text by me above is hereby placed in the public domain

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

Re: @@toStringTag spoofing for null and undefined

[Mark Miller]

Put better, the spec requires that Object.freeze(Object.prototype) works.


On Sat, Jan 24, 2015 at 2:57 PM, Mark Miller erig...@gmail.com wrote:



 On Sat, Jan 24, 2015 at 2:42 PM, Isiah Meadows impinb...@gmail.com
 wrote:

  From: Mark S. Miller erig...@google.com
  To: Gary Guo nbdd0...@hotmail.com
  Cc: es-discuss@mozilla.org es-discuss@mozilla.org
  Date: Sat, 24 Jan 2015 07:11:35 -0800
  Subject: Re: @@toStringTag spoofing for null and undefined
  Of course it can, by tamper proofing (essentially, freezing)
 Object.prototype. None of these protections are relevant anyway in an
 environment in which the primordials are not locked down.

 Yeah, pretty much. That proverbial inch was given a long time ago. And
 the proverbial mile taken. And I highly doubt the spec is going to require
 `Object.freeze(Object.prototype)`,

 Of course not. The key is the spec allows it. SES makes use of that.





 since that prohibits future polyfills and prolyfills of the Object
 prototype. Also, you could always straight up overwrite it, but that's even
 harder to protect against. (And how many cases do you know of literally
 overwriting built-in prototypes?)

 Or, to throw out an analog to Java, it is perfectly possible to call or
 even override a private method through reflection. JavaScript simply has
 more accessible reflection, more often useful since it's a more dynamic
 prototype-based OO language as opposed to a stricter class-based language.

 
  On Sat, Jan 24, 2015 at 6:11 AM, Gary Guo nbdd0...@hotmail.com wrote:
 
  Now I have a tendency to support the suggestion that cuts the
 anti-spoofing part. If coder wants to make an object and pretend it's a
 built-in, let it be. The anti-spoofing algorithm could not prevent this
 case:
  ```
  Object.prototype.toString = function(){
return '[object I_Can_Be_Anything]';
  }
  ```
 

 Or this:
 ```js
 function handler() {
   throw new Error(No prototype for you!);
 }

 Object.defineProperty(
   Object,
   'prototype',
   {
 get: handler,
 set: handler,
 enumerable: true
   });
 ```

 Me thinks this isn't going to get fixed.

  ___
  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




 --
 Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM




-- 
Text by me above is hereby placed in the public domain

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

Re: JavaScript 2015?

[Mark Miller]

JavaScript X === EcmaScript Y :- X === Y + 2009  Y = 6;


On Thu, Jan 22, 2015 at 4:17 PM, Brendan Eich bren...@mozilla.org wrote:

 Andrea Giammarchi wrote:

 I really don't understand ...


 I'm pretty sure you do understand -- you just don't like it.

 The annual cycle may fail, but that would be bad. If it works out, we
 could still continue with ES6, 7, 8, etc.

 I'm leery of revolutionary fanaticism of the kind that led the French
 revolutionaries to invent new month names. Perhaps we're overreaching by
 declaring ES2015 before we've even wrapped up ES6, never mind implemented
 all of it in top browsers! You could be calling b.s. on this, please tell
 me if I'm warm.

 Anyway, I agree ES6 is out there. I cited kangax.github.io, and of
 course you're right, there are other sites and tutorials. The ES5/6/...
 pattern won't go away over night, no matter what bloody revolutionaries try
 to enact :-|.

 This should keep everyone from charging ahead with renaming right now. We
 need to socialize the annuals idea more, and actually hit the schedule. At
 that point we *will* have ES6 = ES2015, ES7 = (probably) 2016, etc. --
 twice the number of names to keep straight.

 /be

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




-- 
Text by me above is hereby placed in the public domain

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

Re: @@toStringTag spoofing for null and undefined

[Mark Miller]

On Wed, Jan 21, 2015 at 12:51 PM, Jordan Harband ljh...@gmail.com wrote:

 To reiterate, I see the issue as boiling down to two questions:
 1) Should builtins have their @@toStringTag value configurable?
 Can anyone provide a use case, or any value, to allowing this? If not, I
 think they should not be configurable. I'd be very interested to hear why
 it would aid debugging, or help Domenic's DOM concerns (which are totally
 valid and admirable), or help with extensibility?

 2) Should non-builtin JS values be able to pretend to be builtins via
 spoofing @@toStringTag?
 If the answer to (1) is every builtin's @@toStringTag is not
 configurable then I think I'm actually comfortable with a value explicitly
 pretending to be an Array, for example, and risking the consequences of
 doing that incorrectly. In this scenario, dropping the prefixing entirely
 makes sense to me.

 However, if the answer to (1) is builtins' @@toStringTag is
 configurable, then this question needs to be modified.

 I see no need to drop @@toStringTag, and little need to keep the prefixing
 at all, if all builtins (not just ES5 ones) have a
 nonconfigurable @@toStringTag.

 It also suddenly occurs to me that the ability to pretend to be a builtin
 will in fact be very useful to me, personally, for the es*-shims.

 Is there anyone who wouldn't be happy with all builtins' @@toStringTag is
 not configurable and drop the ~ prefixing completely?


Just checking: Are we talking about adding it to each instance as
unconfigurable?




 On Wed, Jan 21, 2015 at 11:05 AM, Brendan Eich bren...@mozilla.org
 wrote:

 Brendan Eich wrote:

 Sure -- good point, I flinched and was slot


 slow, lulz.

 /be

 to say internal property because we all don't like infernal slots. ;-)

 ___
 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




-- 
Text by me above is hereby placed in the public domain

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

Re: What would a 1JS-friendly strict mode look like?

[Mark Miller]

I didn't know that SpiderMonkey did that, but I agree it is better. In
light of this news, I'm glad my code sample doesn't work ;).

As for would be good for all engines to act the same, the
precondition was carefully crafted so that engines did not need to
retain the original source, but rather, just enough for behavioral
equivalence. Nevertheless, if we could get everyone to agree on
SpiderMonkey's behavior here, it would be better. Too late for ES6
though.



On Thu, Dec 18, 2014 at 9:09 AM, Till Schneidereit
t...@tillschneidereit.net wrote:


 On Thu, Dec 18, 2014 at 6:01 PM, Mark S. Miller erig...@google.com wrote:

 (1,eval)( + function(){...strict code you want to execute sloppy...})()


 This doesn't work in SpiderMonkey: stringifying functions retains their
 strictness, no matter where strict mode is activated. In this case, the
 result would be the string 'function (){\nuse strict;\n...strict code you
 want to execute sloppy...}'

 It's unfortunate that this doesn't behave the same in all engines, but I
 would argue that SpiderMonkey's stringification is the more faithful one.

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




-- 
Text by me above is hereby placed in the public domain

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

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Mark Miller]

On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 12/4/14, 1:36 PM, Travis Leithead wrote:

 Note that window is not the global.  It's a proxy whose target is the
 global.


 Yes, but within a browser UA, there is no way to get a reference to the
 naked global because all entry-points return window proxies ;-)


 Well, no way from web script.  The browser internals can do it, presumably,
 right?

 Well, good question.  If we don't do this restriction (by which I assume
 defineProperty throwing; I assume getOwnPropertyDescriptor claiming
 configurable always is less controversial), what do we want to do?


 As I look back on your original message, I fail to see what the problem
 is. You seem to think that the window proxy is referring to the same window
 object before and after the navigation.


 The window proxy object identity does not change before and after the
 navigation.

 The window object the proxy is pointing to changes.

 In fact, in most implementations that I'm aware of, there is the concept
 of the inner and outer window.


 Yes, I'm well aware.

 The outer window is the window proxy, which is the object that
 implements the cross-origin access control.


 In Gecko, the cross-origin access control is actually implemented using a
 separate security membrane proxy whose target is the outer window. But
 sure.

 In IE's implementation, the window proxy has no storage as a typical JS
 var--it's only a semi-intelligent forwarder to its companion inner window.


 That's an IE implementation detail.  In Gecko, the window proxy is a JS
 proxy object with a proxy handler written in C++.  That, too, is an
 implementation detail.

 What matters here is what JS consumers see.  Consumers typically (there are
 some exceptions involving scope chains) just see the window proxy, yes?

 So when a script does:

   Object.defineProperty(frames[0], foo, { value: true; });

 It is defining a property on frames[0].  The fact that this is actually a
 proxy for some other object (the global inside that iframe) is somewhat of
 an implementation detail, again.  From the consumer's and the spec's point
 of view, frames[0] is something with some internal methods
 ([[GetOwnProperty]], [[DefineOwnProperty]], etc) which are implemented in
 some way.  Still from the spec's point of view, the implementation of these
 internal methods must satisfy
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-invariants-of-the-essential-internal-methods.

 So, in your code sample, your defineProperty call forwarded to the
 inner window where the property was defined.


 Sure.  I understand that.  As in, the proxy's [[DefineOwnProperty]] invoke's
 the target's [[DefineOwnProperty]].

 After the navigation, the inner window was swapped out for a new one
 (and whole new type system at that) which the existing window proxy (outer
 window) now refers.


 Sure.

 This gave the appearance of the non-configurable property disappearing


 This isn't about appearance.  The relevant spec invariant for
 [[GetOwnProperty]], for example, is:

   If P’s attributes other than [[Writable]] may change over time or
   if the property might disappear, then P’s [[Configurable]] attribute
   must be true.

 And Object.getOwnPropertyDescriptor is clearly defined to invoke
 [[GetOwnProperty]].

 So when a page does Object.getOwnPropertyDescriptor(window, foo) this is
 invoking the window proxy's [[GetOwnProperty]].  That's allowed to do all
 sorts of stuff as long as it preserves the invariants involved, including
 the one I quote above.  The fact that the disappearing is due to the
 target changing is an implementation detail of the window proxy.

 but in reality it would still be there if you could get a reference to the
 inner window


 Which doesn't matter, because the consumer is not interacting with the
 inner window.

 *I wonder if you can capture the inner window in a scope chain or closure
 somehow


 Sure, for a scope chain.  Testcase at
 https://web.mit.edu/bzbarsky/www/testcases/windowproxy/use-old-window-1.html

That page demands a client certificate. Is that intentional?


 shows OLD WINDOW on the first line in Firefox, Chrome, and Safari.  In
 IE11 it throws a Can't execute code from a freed script exception; I can't
 find anything in the specs that allows that, fwiw.

 so that you could observe that foo is still there even though you can't
 directly see it anymore?


 Absolutely.

 I think that might work if the executing code was defined in the old
 iframe's environment and executed after navigation...


 Right.

 But we're not talking about indirect probes like this here, just about the
 basic invariants object internal methods are supposed to preserve.


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



-- 
  Cheers,
  --MarkM
___
es-discuss mailing list

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Mark Miller]

On Thu, Dec 4, 2014 at 4:49 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 12/4/14, 4:45 PM, Mark Miller wrote:

 On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 Sure, for a scope chain.  Testcase at

 https://web.mit.edu/bzbarsky/www/testcases/windowproxy/use-old-window-1.html


 That page demands a client certificate. Is that intentional?


 Er, sorry.
 http://web.mit.edu/bzbarsky/www/testcases/windowproxy/use-old-window-1.html
 should work for everyone.

 -Boris


Here's an unexpected weirdness, probably not deeply related. Change
your first helper page to


script
var someName = OLD WINDOW;
var evil = eval;
function f() {
  return someName;
}
function g() {
  return (1,evil)(3);
}
/script



On FF and Safari, I get 3 as expected. On Chrome, I get on my console:

Uncaught EvalError: The this value passed to eval must be the
global object from which eval originated

Especially weird, because this code doesn't pass any this to the
renamed eval. I don't know what this means.



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

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Mark Miller]

Yes. I was glad to find in that message a pointer back to
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027114.html

On Tue, Dec 2, 2014 at 5:36 AM, David Bruant bruan...@gmail.com wrote:
 Le 02/12/2014 14:24, David Bruant a écrit :

 Hi,

 I feel like I've been in an equivalent discussion some time ago

 The topic felt familiar :-p
 http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0322.html


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



-- 
Text by me above is hereby placed in the public domain

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

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Mark Miller]

On Sun, Nov 30, 2014 at 6:12 PM, Mark S. Miller erig...@google.com wrote:
[...]
 Put another way, if this invariant is preserved by WindowProxy, then

Should be: is not preserved by or is violated by

 anyone else seeking to create another object that violates this
 invariant can create a Proxy whose target is a WindowProxy. Its
 violation enables further violations. The invariants are inductive. A
 violation breaks the induction.


-- 

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

Re: Eval, literal eval, safe eval

[Mark Miller]

On Sun, Nov 23, 2014 at 8:22 AM, Mark S. Miller erig...@google.com wrote:


 https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/
 http://research.google.com/pubs/pub40673.html
 https://code.google.com/p/google-caja/wiki/SES
 www-cs-students.stanford.edu/~ataly/Papers/sp11.pdf

 http://wiki.ecmascript.org/doku.php?id=strawman:concurrency desperately
 needs updating in light of modern promises, but see discussion of Vats and
 there.


See also the two talks announced at
http://www.eros-os.org/pipermail/cap-talk/2011-November/015079.html






 On Sun, Nov 23, 2014 at 3:27 AM, Michał Wadas michalwa...@gmail.com
 wrote:

 Introdution:
 - eval executes piece of code
 - eval can not be safely used with external input
 - Python's ast.literal_eval would be almost useless in modern
 JavaScript (almost all data types can be easily send as JSON)

 literal_eval description:
 The string or node provided may only consist of the following Python
 literal structures: strings, numbers, tuples, lists, dicts, booleans, and
 None.



 My proposition is safe eval.
 Safe eval ( eval.safe(string: code, callback) ) should perform theses
 steps:
 - Create isolated realm without capabilities to perform almost any IO
 (implementation dependant - no XHR, no importScript, no require)


 y


 - evaluate code in context of created realm


 y


 - post result of last evaluated expression back to creator realm using
 structured-clone algorithm


 n. Structured clone sucks.


 - call callback with returned data


 Prefer promises to callbacks



 Pros:
 + sandbox offered by language


 y. Plan is to refine Realm API for ES7 by trying to redo SES in terms of
 Vats.


 + easy to run in other thread


 y


 + quite easy to polyfill


 Well, it wasn't as easy as I first expected, but we do have a SES
 polyfill. Not yet for Vats or Dr. SES


 + servers can send computations to users


 y


 +
 Cons:
 - Realm creation can be costly (but implementations can solve this
 problem in many ways)


 y


 - proposal does not include support for asynchronous operations


 Dr. SES does.


 ___
 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




-- 
Text by me above is hereby placed in the public domain

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

Re: Proposal: Abstract References

[Mark Miller]

On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink sph...@gmail.com wrote:

 On 10/22/2014 07:45 AM, Mark S. Miller wrote:
 
  * Only objects that have been used as keys in FastWeakMaps would ever
  have their [[Shadow]] set, so this could also be allocated on demand,
  given only a bit saying whether it is present. Besides this storage of
  this bit, there is no other effect or cost on any non-weakmap objects.
 
  * Since non-weakmap code doesn't need to test this bit, there is zero
  runtime cost on non-weakmap code.
 
  * Whether an object has been used as a key or not (and therefore
  whether an extra shadow has been allocated or not), normal non-weak
  property lookup on the object is unaffected, and pays no additional cost.

 Maybe it's because I work on a garbage collector, but I always think of
 the primary cost of WeakMaps as being the GC. The above analysis doesn't
 take GC into account.


I should have been more explicit, but GC costs are almost my entire point.
These costs aside, my FastWeakMaps are more expensive in all ways than
SlowWeakMaps, though only by a constant factor, since each FastWeakMap
operation must also perform the corresponding SlowWeakMap operation.




 In the straightforward iterative implementation, you record all of the
 live WeakMaps found while scanning through the heap. Then you go through
 them, checking each key to see if it is live. For each such key, you
 recursively mark the value. This marking can discover new live WeakMaps,
 so you iterate to a fixed point.


That is when you find yourself doing an ephemeron collection. The point of
the transposed representation is to collect most ephemeron garbage using
conventional collection. Consider

var fastField = new FastWeakMap();
var slowField = new SlowWeakMap();

var transientKey = {};

var fastValue = {};
var slowValue = {};

fastField.set(key, fastValue);
slowField.set(key, slowValue);

transientKey = void 0;
fastValue = void 0;
slowValue = void 0;


At this assume that the old value of transientKey is really garbage, but
that fastField and slowField are still reachable. Clearly, both the old
value of fastValue and the old value of slowValue are now garbage and may
be collected. Let's see what work the collector need to do to collect these.

First comes the conventional mark phase: fastField and slowField both get
marked. slowField is itself a non-transposed weakmap, so when we mark it we
also put it on the queue of weakmaps to be ephemeron collected.
fastField internally is not a weakmap, nor does it point at one. It's only
per-instance state is the token, so this gets marked as well.

Now comes the ephemeron mark phase. The only non-transposed weakmap to be
considered is slowField. The non-transposed weakmap serving as
transientKey's shadow never got marked because transientKey never got
marked. fastValue is only reachable from transientKey's shadow, so it also
never gets marked.

Here's the key important thing: In a generational collector, at this point
we'd typically postpone ephemeron collection. To do so, we would complete
the mark phase conventionally, by simply marking the values held by
slowField. This marks slowValue, causing it to get promoted to the next
older generation. THIS IS EXPENSIVE.

Finally, when we can no longer postpone ephemeron collection, when
ephemeron-marking slowField, we'd notice that transientKey didn't get
marked, so we wouldn't mark slowValue.

The counterpoint is the shadow weakmaps, when engaged in ephemeron
collection must still check whether their keys -- to tokens within the
FastWeakMaps -- are still reachable. Typically they will be. This has two
counter-counterpoints:

* For all practical use patterns we've identified, the WeakMap either lives
longer than its keys, or their lifespan is comparable. When the WeakMap is
known to necessarily live longer than its keys, as for class-private state,
then those shadow properties can even be exempted from the key-mark-check.

* Prior to emphemeron collection, the shadow weakmaps (and the values they
carry) get promoted to older generations only along with the object they
shadow.


 In the current web, this implementation seems to work fine. The worst
 case is O(n^2) in the size of the heap, which is pretty much fatal if
 you ever hit it. But that requires lots of paths through multiple
 WeakMaps, and in practice, it seems WeakMaps aren't being used much.
 I've never seen our WeakMap marking phase show up as a significant cost.


Chicken and egg. If WeakMaps are used for private state (and trademarks
and...), they will be used a lot. But they will only be used for those
things if it isn't fatally slow to do so.





 For an algorithmically more robust solution, you could add a check
 whenever marking an object. The check would test whether the object is
 (or might be) used as a WeakMap key. This would slow down marking all
 objects, so in practice you want to be clever about avoiding the test.


Yeah, I'm very curious about whether this can 

Re: Proposal: Abstract References

[Mark Miller]

Please do nitpick. I wrote this in too much of a hurry and it is something
that needs care.

In any case, yes, transientKey.

On Wed, Oct 22, 2014 at 2:46 PM, Rick Waldron waldron.r...@gmail.com
wrote:



 On Wed, Oct 22, 2014 at 5:26 PM, Mark Miller erig...@gmail.com wrote:



 On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink sph...@gmail.com wrote:

 On 10/22/2014 07:45 AM, Mark S. Miller wrote:
 
  * Only objects that have been used as keys in FastWeakMaps would ever
  have their [[Shadow]] set, so this could also be allocated on demand,
  given only a bit saying whether it is present. Besides this storage of
  this bit, there is no other effect or cost on any non-weakmap objects.
 
  * Since non-weakmap code doesn't need to test this bit, there is zero
  runtime cost on non-weakmap code.
 
  * Whether an object has been used as a key or not (and therefore
  whether an extra shadow has been allocated or not), normal non-weak
  property lookup on the object is unaffected, and pays no additional
 cost.

 Maybe it's because I work on a garbage collector, but I always think of
 the primary cost of WeakMaps as being the GC. The above analysis doesn't
 take GC into account.


 I should have been more explicit, but GC costs are almost my entire
 point. These costs aside, my FastWeakMaps are more expensive in all ways
 than SlowWeakMaps, though only by a constant factor, since each FastWeakMap
 operation must also perform the corresponding SlowWeakMap operation.




 In the straightforward iterative implementation, you record all of the
 live WeakMaps found while scanning through the heap. Then you go through
 them, checking each key to see if it is live. For each such key, you
 recursively mark the value. This marking can discover new live WeakMaps,
 so you iterate to a fixed point.


 That is when you find yourself doing an ephemeron collection. The point
 of the transposed representation is to collect most ephemeron garbage using
 conventional collection. Consider

 var fastField = new FastWeakMap();
 var slowField = new SlowWeakMap();

 var transientKey = {};

 var fastValue = {};
 var slowValue = {};

 fastField.set(key, fastValue);
 slowField.set(key, slowValue);


 I don't mean to nit-pick, but key is transientKey, right?

 Rick




-- 
Text by me above is hereby placed in the public domain

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

Re: what makes a file a module?

[Mark Miller]

I agree that we should come to consensus on a file extension. The argument
that it is out of our jurisdiction only makes sense to me if it is in
some other group's jurisdiction. AFAICT, it is not. And consensus is
needed, so let's proceed.

Suggestions?
Is there any reason we should still limit ourselves to the traditional
three characters?
Are there any registries reliable enough to get a sense of possible
conflicts, or how bad they may be?
Once we choose an extension, what if anything should be done about
correspondence with mime type?

IIRC, the extension .jsm was already proposed, but may have had fatal
conflicts. To get the ball rolling, .jsmod ?


On Sun, Oct 19, 2014 at 8:43 PM, John Barton johnjbar...@google.com wrote:



 On Sun, Oct 19, 2014 at 2:23 PM, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:


 It is implementation dependent how it is determined whether an individual
 file will be parsed as a Script or as a Module.

 Axel alluded to a possible HTML extension that could be used to
 distinguish modules from scripts.  But, exactly how modules will be
 integrated into HTML is still under development.

 You can imagine various ways that modules might be identified in a
 command line environment. for example

 js script1.js -m mod1.js -m mod2.js script2.js

 so of us have argued that a module file extension might be useful in such
 environments:

 js script1.js mod1.js mod2.js script2.js


 FWIW, traceur has to use --script vs --module on the command line and
 .module.js among files otherwise parsed as script.

 You may recall that Yehuda Katz suggested on this group that a prefix
 might be used, script:file.js. To avoid long arguments about What Is a URL,
 I suggest a postfix string, file.js,script. Of course a file extension
 would be better. Many build tools use filenames and this issue puts
 practical work with ES6 at a disadvantage.

 jjb

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




-- 
Text by me above is hereby placed in the public domain

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

Re: Throwing errors on mutating immutable bindings

[Mark Miller]

On Thu, Oct 2, 2014 at 12:22 AM, Andreas Rossberg rossb...@google.com
wrote:

 On 1 October 2014 16:09, Erik Arvidsson erik.arvids...@gmail.com wrote:
  The static error is problematic. I'm pretty sure that engines that do
 lazy
  parsing of functions is not going to report static errors before doing a
  full parse of the function.

 Well, it is no harder than reporting reference errors for unbound
 variables in strict mode, which is already required for ES5.
 ...However, at least V8 does not report that correctly either, as soon
 as lazy parsing kicks in.


Hi Andreas, can you show an example where v8 observably does the wrong
thing here? Thanks.


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

Re: Array.prototype.contains solutions

[Mark Miller]

On Wed, Oct 1, 2014 at 12:21 AM, Brendan Eich bren...@mozilla.org wrote:


  The most painful use case is the existence of perfectly reasonable ES5
 code like:


 function Point(x, y) { this.x = x; this.y = y; }

 Point.prototype.toString() { return `${x},${y}`; };


 You mean

 Point.prototype.toString = function () { return ...; };

 of course -- but you're using template string new syntax, so why not use
 Object.defineProperty here? Just sayin' ;-).


I did indeed mean the assignment in your correction.





  Because of the override mistake, this reasonable code no longer works
 after

 Object.freeze(Object.prototype);

 This sucks.

 SES goes out of its way to not break code that follows ES5 best
 practices. The above Point code does. That's why SES's
 tamperProof(Object.prototype) replaces the data properties on
 Object.prototype with accessor properties whose setter uses
 [[DefineOwnProperty]] to emulate assignment on a this that is not
 Object.prototype itself.


 Yup, Domenic's #2.

  With your #3, perhaps we'd have a less painful way to working around the
 override mistake.


 I think #3, if hacked via @@enumerableWhenAssigned or any such thing, will
 just lead to more bugs. It's too implicit, modal.

 Here's an alternative: add an assignment operator variant, spell it :=,
 that overrides. Boom, new code can work around the override mistake.

 Point.prototype.toString := function () { return ...; };

 Yeah, I remember := being mooted as [[DefineOwnProperty]] sugar taking a
 property descriptor, but I'm throwing this out here. It's simpler and does
 not confusingly vary the RHS to be a propdesc where regular assignment
 evaluates an arbitrary RHS assignment-expression.

 Old code will need magic frozen-proto-setter hacks anyway. That ship
 sailed with ES5.


My concern is old code like Point co-existing with new framework code, like
SES, that wants to freeze old prototypes, but is ignorant about all the
particular old client abstractions, like Point, that need to work within
that framework. The new framework code currently must use tamperProof
rather than freeze, which is expensive and not a fully transparent fix.
With #3, the new framework code might instead install an @@something on
these frozen prototypes, leaving the properties on that prototype as data
properties that do not suffer from the override mistake. The result could
be efficient and adequately transparent.

-- 

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

Re: Throwing errors on mutating immutable bindings

[Mark Miller]

On Wed, Oct 1, 2014 at 9:15 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:


 On Oct 1, 2014, at 9:05 AM, Mark S. Miller wrote:

 Good point. If we can require all such assignments to be rejected
 statically, why is a runtime assignment to a const variable even possible?
 Can't we just assert that this cannot occur?


 The runtime cases I meant are the ones you mentioned. Sloppy with or eval
 dynamically shadowing a sloppy a [[Set]] reference to a const binding.
 Can't be a early error, should be a runtime error.


Although it is a bit late to suggest it ;) ...

Couldn't we have with and sloppy direct eval ignore/skip const and let
bindings? Then these errors could always be early.

I have no argument with the answer too late, but still curious if there's
another reason.



 Allen






 On Wed, Oct 1, 2014 at 8:59 AM, Allen Wirfs-Brock al...@wirfs-brock.com
 wrote:


 On Oct 1, 2014, at 8:39 AM, Mark S. Miller wrote:

 ...

 I was with you until you got to the following point

 
  If there is an intervening with or sloppy direct eval, then there is
 not a statically apparent assignment to a const variable. Since this can
 only occur in sloppy code anyway, it seems more consistent with the rest of
 sloppy mode for this failed assignment to be silent, rather than
 dynamically throwing an error.
 

 const is a new kind of declaration unlike any declaration form that
 previous existed in ES, so Ii don't think its handling introduces any
 legacy consistency issues.  If somebody is using const, regard less of
 mode, they pretty clearly expect assignments to any const bindings to be
 illegal.  And, I don't think any body wants new silent failure errors, even
 in sloppy mode.  The most consistent thing is for runtime detected
 assignments to const bindings to always be noisy errors.  Early where
 possible, at runtime in the rest of the cases.


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

Re: Maximally minimal stack trace standardization

[Mark Miller]

Yes, I believe that we should consider some non-strict non-sloppy
functions, such as .bind()ings of strict functions, to also normatively
have some TCO/PTC requirements. However, it is too late to consider such
for ES6 and we can always extend such TCO/PTC requirements to more cases
later.

On Mon, Sep 29, 2014 at 12:02 PM, Brendan Eich bren...@mozilla.org wrote:

 Allen Wirfs-Brock wrote:

 No particular reason an implementation can't optimize through that if
 they want to.


 The question is whether it should be normative. PTC is about observable
 asymptotic space performance (I keep saying :-P).


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

Re: ... A community is writing the spec...

[Mark Miller]

Meant this message is so uninformed that
On Sep 10, 2014 6:55 AM, Mark S. Miller erig...@google.com wrote:

 Hi L2L, this message is uninformed that I must ask you to move to another
 forum, until you learn a lot more about js and web programming. This is not
 the place.
 On Sep 10, 2014 6:47 AM, L2L 2L emanuelal...@hotmail.com wrote:

  Yeah I guess I'm pretty late for that huh... No this is great, the
 more feature, the better. A lot of these feature would cause certain
 application not to be needed... In other words, use more of the language
 and less libraries Why you at it, how about reviving E4X? That way, we
 can lose the DOM api. After all, if ES was made for the web, than there
 should be method to access the DOM. It could be an object, like how the E4X
 was, but better.

 On another note, this is now becoming the mini-type
 application/JavaScript, than text/JavaScript.

 But consider the E4X though.

 E-S4L
 N-S4L

 On Sep 10, 2014, at 9:35 AM, Sebastian Zartner 
 sebastianzart...@gmail.com wrote:

 I don't see why you're complaining. If you don't like the features in
 ES6, then just don't use them. The features of ES5 are still available.
 If you want to have more strict code, then add a use strict; statement
 to your code.
 And if you're against adding more features to the core language, then you
 should have complained several years ago at the planning of ES6.

 Sebastian

 On 10 September 2014 08:12, L2L 2L emanuelal...@hotmail.com wrote:

 This These feature--most of them-- would be something I see in the
 browser api... This is truly looking like w3c working group...

 ... But I don't see any chance of my words changing the direction of the
 spec Especially when you consider the original designer of the language
 steering this course...

 So in term, if you can't beat them, change them, might as well aid them
 --in what I feel to be In truth, the destruction of the original syntax,
 by the original creature of the language... Kinda wish they had a flag for
 these new syntax to be set... At least than, those who are toward the
 originally syntax style, would feel some sort of preservation for it--
 In their quest to farther add on to ES as a --application-- language.

 --as duo to a private email by /be. This to me is not trolling, I'm
 responding to this person who respond two times to my post... So in terms,
 I should not have to worry about being banned from the mailing list cause
 of this message.

 E-S4L
 N-S4L

 On Sep 10, 2014, at 1:17 AM, Axel Rauschmayer a...@rauschma.de
 wrote:

 Now is second half of 2014, and lots of issues are not closed yet, from
 what I see.


 The spec already looks pretty complete to me and Traceur and TypeScript
 do a pretty good job of letting you use ES6 today.

 As previously announced here, the current schedule is to be finished by
 the end of the year, to start the publication process in March 2014 and to
 have a standard by June 2014.

 I got delusioned as well.

 Isn't the model of big new editions of spec over; in the times we live
 now, with two-week frequent releases? I think ES6 will never see the light
 when taken from this approach. That's why, shouldn't the release policy be
 changed so that:


 It has already changed, but not for ES6. ECMAScript 7 and later will
 have fixed release dates. Only features that are ready at a given date will
 be included.
 Background: https://github.com/tc39/ecma262

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


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


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

Re: use strict VS setTimeout

[Mark Miller]

On Mon, Sep 8, 2014 at 7:25 AM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 Apologies, now I see what you meant and I think option 2 would be probably
 ideal.


I disagree. I think option #2 is rather horrible. Strictness can't be
tested in JS user code, and shouldn't be. And sloppy functions can't be
emulated by proxies, and shouldn't be. Whatever we spec as the caller's
interaction with the callee, it shouldn't be predicated on if the callee
is strict. We've taken pains to avoid this everywhere else[*].

The status quo, though we agree on the pain it causes, is less painful than
introducing this conditional.


[*] SloppyFunction.caller must not reveal a strict function. This means
that calling into a sloppy function can reveal whether the caller is strict
-- but only if the sloppy function has the legacy magic caller property and
calls a sloppy function.



 ES5+ engines can easily retrieve strictness so while it might seem weird
 it would surprise less, syntax and explicit intent speaking, and will
 remove the right to pass *a* global context to the callback.

 Going through the list of all properties it looks like at the end of the
 day only things to improve/change are:

 requestAnimationFrame
 setInterval
 setTimeout

 Although I have honestly no idea how to explain via W3C pages that JS
 might be strict or not ... seems to me that _strictness_ should be
 outside the DOM knowledge so  probably this should be part of ES
 specification.

 However, it seems at this point an overly-complicated tiny little change
 full of cross-web alignment that might not even have a concrete impact in
 the real world ... so maybe all this won't be worth to fix.

 Thanks all for thoughts, hints, and insights on this matter.

 Best Regards


 On Mon, Sep 8, 2014 at 2:45 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 9/8/14, 8:15 AM, Andrea Giammarchi wrote:

 no introspection or nothing magic and weird, simply `.call(undefined)`
 would do for sloppy and strict, preserving global in sloppy, avoiding
 shenanigans in strict.


 You seem to be assuming there is only one global involved again.  Did you
 look at my testcase I posted earlier in this thread?  Again, 
 http://fiddle.jshell.net/tmt5e9m6/2/show/.

 The behavior that testcase shows is not achievable by doing
 .call(undefined).  If the web depends on that behavior (which is worth
 verifying if someone wants to experiment!), then we can't blindly do
 .call(undefined).  Even if that is case, we _could_ still do
 .call(undefined) when the callee is strict, since I'm fairly certain the
 web does not depend on that behavior for strict callees, but that involves
 introspecting the strictness of the callee.

 So we have three options, as I see it:

 1)  Keep existing behavior; always pass in a this value that's the
 window that was the this of the setTimeout call.

 2)  Change behavior for strict callees only.  This involves introspecting
 the strictness of the callee, which is clearly doable in implementations,
 but weird and magical from the ES point of view.

 3)  Change behavior across the board to passing undefined as the this
 value, and deal with any resulting compat issues via evangelism.

  Hence my curiosity: when this experiment was made, which code with `use
 strict` failed ?


 This only matters for option 2 above, right?  The compat constraints for
 option 3 are all around sloppy functions, which is what most people use
 today.  That's why I even brought up option 2: the question you were asking
 was presupposing that this option should be on the table.

 -Boris



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




-- 
Text by me above is hereby placed in the public domain

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

Re: use strict VS setTimeout

[Mark Miller]

On Sun, Sep 7, 2014 at 10:29 AM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 I know this is probably W3C land but the following code shows the global
 object in every JS engine I could test:

 ```js
 (function () {
   'use strict';
   setTimeout(function () {
 'use strict';
 console.log(this);
 // [window/global Object]
   }, 0);
 }());
 ```


On Sun, Sep 7, 2014 at 11:02 AM, Axel Rauschmayer a...@rauschma.de
https://mail.google.com/mail/?view=cmfs=1tf=1to=a...@rauschma.de
wrote:

 On Sep 7, 2014, at 19:47 , Mark S. Miller erig...@google.com
 https://mail.google.com/mail/?view=cmfs=1tf=1to=erig...@google.com
 wrote:

 On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens mathi...@opera.com
 https://mail.google.com/mail/?view=cmfs=1tf=1to=mathi...@opera.com
 wrote:

 On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
 andrea.giammar...@gmail.com
 https://mail.google.com/mail/?view=cmfs=1tf=1to=andrea.giammar...@gmail.com
 wrote:
  This looks like a potential problem when possible passed methods are not
  bound + it looks inconsistent with *use strict* expectations.


 Yes. This looks like a typical screwup. Thanks for pointing it out.


 Interesting. Follow-up question: isn’t strictness propagated lexically?


Yes.



 That is, shouldn’t the parameter of `setTimeout()` be strict even without
 being explicitly declared as such?


Yes, it is. That's what demonstrates that this is a W3C land screwup, as
Andrea inferred, rather than a JS issue. The callback is strict. It is
setTimeout itself which is explicitly passing it the global as a
this-binding, rather than passing it undefined. If the callback function
were sloppy, it would see the global object in either case.



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

Re: use strict VS setTimeout

[Mark Miller]

On Sun, Sep 7, 2014 at 11:07 AM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 Yes Axel, that's how it works, this will show undefined indeed all over

 ```js
 (function () {
   'use strict';
   function g() {
 console.log(this);
   }
   g(); // undefined
   setTimeout(function () {
 g(); // undefined
   }, 0);
 }());
 ```

 or testing other use strict restrictions:

 ```js
 (function () {
   'use strict';
   setTimeout(function () {
 argument.callee
   }, 0);
 }());
 ```

 The strict behavior is preserved, it's not an opt-out, but the invoked
 function within setTimeout has the global context regardless it has been
 defined under the strict directive + regardless it defines itself as strict.

 Basically if you feel secure about use strict here you have a case that
 shows you shouldn't ... making one point of strict directive kinda
 broken/pointless.


Agreed. I would remove only kinda from that statement ;).




 Regards


 On Sun, Sep 7, 2014 at 7:02 PM, Axel Rauschmayer a...@rauschma.de wrote:

 On Sep 7, 2014, at 19:47 , Mark S. Miller erig...@google.com wrote:

 On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens mathi...@opera.com
 wrote:

 On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
 andrea.giammar...@gmail.com wrote:
  This looks like a potential problem when possible passed methods are
 not
  bound + it looks inconsistent with *use strict* expectations.


 Yes. This looks like a typical screwup. Thanks for pointing it out.


 Interesting. Follow-up question: isn’t strictness propagated lexically?
 That is, shouldn’t the parameter of `setTimeout()` be strict even without
 being explicitly declared as such?



-- 

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

Re: use strict VS setTimeout

[Mark Miller]

On Sun, Sep 7, 2014 at 11:27 AM, Domenic Denicola 
dome...@domenicdenicola.com wrote:

  I don't understand why this is any more surprising than any other
 function that calls its callback with .call(something).


The issue is what the something should be, and which choices for something
are surprising for what APIs.



 It doesn't matter whether the callback is strict or not; .call(window),
 which is what the spec does, will override it.


I don't understand what you're trying to say here. What will override what?



 As far as I can see this issue has absolutely nothing to do with strict
 vs. sloppy.


As Andrea initially stated, this is a DOM-spec issue, not a JS issue, in
that JS allows setTimeout to call the callback with WTF it wants. However,
the purpose of setTimeout, etc, from the JS programmer's perspective, is to
postpone some action to some future time. From this understanding, there's
no reason to give the postponed action access to the global object. From a
POLA perspective, there is thus strong reason not to.

Put another way, were the functionality of setTimeout etc only to postpone
calling its callback, and not to provide it access to the global object,
then we might consider moving it from the W3C side to the JS side, like we
did for promises. After all, this temporal postponement function, by
itself, would seem equally useful in non-browser contexts, like Node.
Speaking of which:


On Sun, Sep 7, 2014 at 11:35 AM, Alex Kocharin a...@kocharin.ru wrote:


 I would add that in node.js it returns neither undefined nor window, but a
 timer object, which you can clear up with `clearInterval(this)` inside the
 callback.


Since these are specced only for the browser, this divergent behavior
doesn't violate anything. Were setTimeout etc to be moved from W3C to JS,
we would not pass the global object, so again you would not be violating
the spec *by virtue of* not passing the global object.

However, in order to not break the web, as was pointed out, any such
possible future JS std setTimeout etc would only pass undefined, so that
sloppy functions still see their global object. So in that sense, this node
behavior is incompatible with any behavior that could be standardized by a
future JS for setTimeout etc.


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

Re: use strict VS setTimeout

[Mark Miller]

On Sun, Sep 7, 2014 at 11:44 AM, Garrett Smith dhtmlkitc...@gmail.com
wrote:

 On 9/7/14, Domenic Denicola dome...@domenicdenicola.com wrote:
  I don't understand why this is any more surprising than any other
 function
  that calls its callback with .call(something). It doesn't matter whether
 the
  callback is strict or not; .call(window), which is what the spec does,
 will
  override it.
 
  As far as I can see this issue has absolutely nothing to do with strict
 vs.
  sloppy.
 
 I agree on that point; setTimeout passes the window to the callback as
 the this value. But that has nothing to do with inheritance.


Who said anything about inheritance?




 Method setTimeout uses the global object as the `this` value for the
 callback function, much like addEventListener, etc, as does
 `.call(window)` like you mentioned.


Yes it does. The question is: should it?


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

Re: use strict VS setTimeout

[Mark Miller]

On Sun, Sep 7, 2014 at 12:50 PM, Garrett Smith dhtmlkitc...@gmail.com
wrote:

 On 9/7/14, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
  this is getting nowhere ... yeah Garret, you can use `.call` and we all
  know that ...
 
  Now I want you to answer this: why on earth would you expect a global
  context in a setTimeout or setInterval operation for a function/method
 you
  have explicitly defined as strict ?
 
  One single use case ... do you have it ?
 
  'cause you don't use use strict inside method/functions passed to
  `addEventListener` as example, do you?
 
  So I will close the loop with the very initial snippet and just one extra
  comment
 
  ```js
  (function () {
'use strict'; // == as a developer, I don't want implicit window
setTimeout(function () {
  'use strict'; // == as a developer, I don't want implicit window
  console.log(this);
  // [window/global Object]
  // SO WHY ON EARTH I HAVE AN IMPLICIT window HERE ?
}, 0);
  }());
  ```
 

 setTimeout is explicitly calling your callback with the window. It's
 specified to do so in HTML5. It is a little strange. Should HTML5 be
 changed?


Yes, this is indeed the only question that Andrea and I are raising in this
thread. As you acknowledge, providing window here is a little strange. I
quibble with a little. When a surprise surprises by providing less
authority than expected, I don't much care. When the surprise is that more
authority is provided than expected, that's a more serious issue.






 http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#dom-windowtimers-settimeout
 --
 Garrett
 @xkit
 ChordCycles.com
 garretts.github.io




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

Re: Duplicate property names (was Re: @@new)

[Mark Miller]

Regarding Domenic's question:


Domenic Denicola wrote:

 Another way of guiding the decision: I don't quite recall where the
 spec landed `{ x: 1, [x]: 2 }`, but we should probably be consistent with
 that.



The initial value of the x property would be 2. It should not be observable
that it was 1 at an intermediate stage of the initialization.

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

Re: Standard builtins' prototypes and toString

[Mark Miller]

I am happy with #b as well, though I prefer #c. I also agree with C.
Scott's interpretation of #c, to mean, appropriate degenerate value, which
is generally the zero value, but is plausibly NaN for Date.

Whichever experiment Nightly tries first with a positive outcome, I expect
that's what we'll do, since the difference between #b and #c is not large
enough to be worth waiting for a second experiment.




On Tue, Jun 17, 2014 at 8:37 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:

 On Tue, Jun 17, 2014 at 11:33 AM, Allen Wirfs-Brock
 al...@wirfs-brock.com wrote:
  I'm not sure who introduced the idea that the Date.prototype should have
 a
  zero value, but that is inconsistent with ES35 where the TimeValue of
  Date.prototype is NaN:
  http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.5 If we went
 the
  (c) route it should presumably be modified to use NaN and not 0.

 Sorry, I was using quotes around zero value on purpose to mean, the
 appropriate value for the given type (which is not actually 0).  Date
 should be NaN, boolean should be false, etc.  I hope most of those
 reading understood this.
   --scott
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




-- 
Text by me above is hereby placed in the public domain

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

Re: Standard builtins' prototypes and toString

[Mark Miller]

On Thu, Jun 12, 2014 at 8:19 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:


 On Jun 12, 2014, at 5:26 AM, Till Schneidereit wrote:

  While working on changing Date.prototype to be a plain object in
 SpiderMonkey, we realized that there's an issue: the way things are specced
 now, `alert(Date.prototype)` will throw, because `Date.prototype.toString`
 isn't generic. The same applies for all builtins with non-generic
 `toString` prototype functions.

 Fortunately there aren't very many of those. I think it is only Date and
 RegExp that have this issue among the ES6 built-ins


WeakMap, Map, Set, others?



 
  To resolve this, I propose changing these `toString` to first check if
 the `this` value is %FooPrototype% (e.g., %DatePrototype% in the case at
 hand) and return the result of the equivalent of calling the original
 Object.prototype.toString.

 that breaks if you move such methods across Realms.

 
  I'm not sure if that is enough to cover subclasses of these builtins.
 Will calling `toString` on the prototype of `class MyDate extends Date{}`
 still throw? If so, that would at least not be a backwards-compatibility
 concern, but it's probably also not desirable.

 Yes, it would still throw for subclasses.

 I think the pattern we should follow for such built-in toString methods is
 that if a branding check of this sort is performed, the fall back should be
 to perform the built-in Object.prototype.toString behavior rather than
 throwing.

 Unless somebody sees issues with this fix, I'll incorporate it into the
 spec. for Date and RegExp.


The real problem includes ES6 classes as well. Whatever fix we choose, it
should apply there as well -- not that I have a concrete proposal. This
one's a real puzzler.




 Of course, even with this fix there is no guarantee that invoking toString
 on an object won't throw.  Debugging tool that expect to use toString need
 to take that into account and provide their own fallbacks.

 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: Integrating the Webs' dependency systems

[Mark Miller]

On Thu, May 29, 2014 at 8:20 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 5/29/14, 11:12 AM, Mark S. Miller wrote:

 But if the issue is of general interest across many hosting environments,
 then it should
 probably be handled by JS and TC39, rather than duplicating work among
 the hosting environment specs.


 Assuming the requirements of the different hosting environments are
 similar enough that it's possible to factor out some sort of common thing
 (presumably with hookable bits for the parts where hosting environments
 want different behavior), of course.  If the hookable bits start being the
 whole thing, that would suggest that the requirements are not similar
 enough  Hard to say until we try.


I wholeheartedly agree. Let's try.


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

Re: Integrating the Webs' dependency systems

[Mark Miller]

Parallel experiments would be great.


On Thu, May 29, 2014 at 8:59 AM, Kevin Smith zenpars...@gmail.com wrote:


 Assuming the requirements of the different hosting environments are
 similar enough that it's possible to factor out some sort of common thing
 (presumably with hookable bits for the parts where hosting environments
 want different behavior), of course.  If the hookable bits start being the
 whole thing, that would suggest that the requirements are not similar
 enough  Hard to say until we try.


 I wholeheartedly agree. Let's try.



 I think a better approach (perhaps parallel) would be to imagine a
 scenario where the host environment defines the loading framework, and
 seeing how that changes the ES spec.  My hunch (untested of course), is
 that, as long as the host provides some elegant promise-returning
 primatives, the ES spec would be much simplified and streamlined by the
 change.





-- 
Text by me above is hereby placed in the public domain

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

Re: Object.getOwnPropertyDescriptor can return just about anything

[Mark Miller]

This is a stop-the-train scale disaster. ES6 cannot ship in this state. We
need to fix this asap.

My apologies for not tracking this issue better earlier. I thought we had
all agreed on the constraints, so I did not pay sufficient attention to
what I thought was merely the ironing out of minor kinks.

I am trying to arrange a hangout with Tom and Allen to discuss this further.



On Wed, Apr 30, 2014 at 9:50 AM, Jason Orendorff
jason.orendo...@gmail.comwrote:

 On Tue, Apr 29, 2014 at 8:08 PM, Mark S. Miller erig...@google.com
 wrote:
  There aren’t any internal invariant sensitivities that I could find.
  Once
  such a non-standard descriptor is never directly used by any of the
 ordinary
  object MOP operations
 
  I'm surprised and alarmed by this, and it seems wrong. It is also not
 what I
  think I remember. What about, for example, the invariant that an object
  cannot both claim that a property is non-configurable but then later
 change
  its alleged configuration?

 As specified, proxies can do this:

   js Object.isFrozen(proxy)
   true
   js Object.getOwnPropertyDescriptor(proxy).configurable
   true

 Of course the property is not really configurable. The extent of the
 issue is that Object.getOwnPropertyDescriptor is not a reliable
 reflection API.

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




-- 
Text by me above is hereby placed in the public domain

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

Re: standardizing Error.stack or equivalent

[Mark Miller]

On Thu, Mar 27, 2014 at 9:11 AM, Erik Arvidsson erik.arvids...@gmail.comwrote:

 To be clear. Changing .stack is not an option. We need to introduce a new
 API.

 On Tue Mar 25 2014 at 4:40:20 PM, John Lenz concavel...@gmail.com wrote:

 Interesting sourcemap usage.  But is there any hope for standardization
 of the existing stack handling for ES7? It wasn't clear to me why it
 stalled for ES6.  There a few things I would like to see:
 1) standardization V8's Error.captureStackTrace API


 The V8 API has some issues that it returns objects (getThis, getFunction
 and getEvalOrigin). For security reasons we would want to limit what the
 API gives you to names and locations.


+1.




 2) standardization of the stack format


 We can probably reuse V8's and Chakra's toString format here.


I think that's a good place to start, and 
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#158
attempts to normalize other browsers to the v8 format. However, in doing so
we discovered that FF Nightly 30 includes useful extra information,
regarding nested eval contexts, which this code throws away with the
FFEvalLineColPatterns regexp. Before adopting the v8 format, we should
discuss whether this extra information is useful enough that we should find
a way to keep it. Mozillians, why did you add this extra information?

Also, rather than startline/startcolumn, we should really do what Smalltalk
has done forever: startline/startcolumn/endline/endcolumn.





 3) standardizaton of when the stack is added to the Error object
 (creation vs throw)


 Since we have to do a new API we can decide either way. Personally I
 prefer at creation maybe there are some performance benefits to only add it
 on throw?


 4) specification as to whether throw (and re-throw) overwrite any
 existing stack property


 Same here. New API. What is the desired behavior?


The stack should not be accessible given only the error object. Rather,
there should be a getStack function 
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#300
which, given an error object, returns the stack. That way, code which does
not have access to the getStack function cannot see the stacks.





 More would be welcome but that is what I would actually have an immediate
 use for.




 On Tue, Mar 25, 2014 at 11:43 AM, Mark S. Miller erig...@google.comwrote:

 Hi John, see also my message at 
 https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html
 which cites some of your work on sourcemaps.


 On Tue, Mar 25, 2014 at 11:25 AM, Rick Waldron 
 waldron.r...@gmail.comwrote:




 On Tue, Mar 25, 2014 at 1:38 PM, John Lenz concavel...@gmail.comwrote:

 I was recently modifying some code to be strict mode compliant and it
 reminded me that the primary use of the Function caller property and
 arguments.caller is to build stack traces.   Now the latest Internet
 Explorer releases have support for stack traces, as of course do Chrome,
 FF, and Safari but only Chrome/V8, to my knowledge, has an actual API.

 I know there was some initial work in this area and nothing is likely
 to happen in the ES6 time frame but can something to be done to make the
 stacks traces more usable?


 Take a look at the work Erik Arvidsson has done so far:

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


 Rick


 ___
 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


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




-- 
Text by me above is hereby placed in the public domain

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

Re: standardizing Error.stack or equivalent

[Mark Miller]

Is the FFEvalLineColPatterns at 
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#194
correct?


On Thu, Mar 27, 2014 at 11:29 AM, Jason Orendorff jason.orendo...@gmail.com
 wrote:

 Not formally, but it's straightforward:

 At the time you call eval() or Function(), we capture the string
 fileName +  line  + lineNumber +   eval
 or  Function if you're calling Function. We use that string as the
 fileName for the dynamic eval or Function code. This affects both
 err.fileName and err.stack.

 This implies these synthetic fileNames can nest. You can end up with a
 stack like:

 js try { eval(eval('FAIL')); } catch (x) { print(x.stack); }
 @typein line 2  eval line 1  eval:1:1
 @typein line 2  eval:1:1
 @typein:2:7

 I think the extended format was added in this bug:
   https://bugzilla.mozilla.org/show_bug.cgi?id=332176

 -j

 On Thu, Mar 27, 2014 at 1:37 PM, Mark S. Miller erig...@google.com
 wrote:
  Is this extended format documented anywhere?
 
 
  On Thu, Mar 27, 2014 at 10:36 AM, Jason Orendorff
  jason.orendo...@gmail.com wrote:
 
  On Thu, Mar 27, 2014 at 12:31 PM, Mark Miller erig...@gmail.com
 wrote:
   Mozillians, why did you add this extra information?
 
  Well... if the point of Error.stack is to provide diagnostic
  information for exceptions, for the purpose of debugging, this
  information is critical.
 
  Without this, eval() or Function() often won't appear on the stack
  anywhere. What we were doing before didn't reveal that eval or
  Function was involved at all. It was misleading and unhelpful.
 
  -j
 
 
 
 
  --
  Cheers,
  --MarkM




-- 
Text by me above is hereby placed in the public domain

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

Re: standardizing Error.stack or equivalent

[Mark Miller]

I wasn't aware that v8 does that. Is this format documented anywhere?


On Thu, Mar 27, 2014 at 2:23 PM, Christian Plesner Hansen c...@p5r.orgwrote:

  js try { eval(eval('FAIL')); } catch (x) { print(x.stack); }
  @typein line 2  eval line 1  eval:1:1
  @typein line 2  eval:1:1
  @typein:2:7

 I'm unclear on what the problem is with nested evals -- you get
 essentially the same information from v8:

 js try { eval(eval('FAIL')); } catch (x) { console.log(x.stack); }
 ReferenceError: FAIL is not defined
 at eval (eval at anonymous (eval at anonymous (repl:1:7)),
 anonymous:1:1)
 at eval (eval at anonymous (repl:1:7), anonymous:1:1)
 at repl:1:7


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




-- 
Text by me above is hereby placed in the public domain

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

Re: Multiline Strings

[Mark Miller]

On Sat, Mar 8, 2014 at 11:05 AM, Mark S. Miller erig...@google.com wrote:

 On Sat, Mar 8, 2014 at 9:30 AM, Florian Bösch pya...@gmail.com wrote:

 On Sat, Mar 8, 2014 at 6:10 PM, John Barton johnjbar...@google.comwrote:

 You may like to take a look at how the traceur compiler (
 https://github.com/google/traceur-compiler) works. It allows one to
 write code like
  var statement = parseStatement `${result}[${index}++] =
 ${expression};`;
 where the ${} syntax surrounds variables from the caller that are
 substituted into the string.  In our case the result 'statement' is an AST
 but it could source code just as well. And source maps work fine for our
 code. Well as fine a source maps ever work ;-)


 That's a fine approach, and I'm not against preprocessing in any flavor
 if that's your cup-o-tea. The problem rather is that one explicit usecase
 of multiline strings (aka templates) is to make it easier to write DSLs.
 But if you write DSLs and embedd the strings in your JS source somewhere,
 you're gonna have to deal with debugging of any kind.

 For example, WebGL implementations return errors strings like these:

 ERROR: 0:1: 'foobar' : syntax error

 You can imagine that being confronted with a string like that, out of
 thousands of shader code lines in your application, isn't very useful.
 You'll also realize that, not all errors can actually be detected with a
 validator.

 In order to make this a useful piece of error message, you'll need to
 translate whatever WebGL throws back at you, to a sourceline and filename.
 And unless you instrumented this beforehand with a preprocessor, you're not
 gonna get it.

 So my question is this, is everybody happy with the state of affairs that
 a preprocessor is the only viable way to use templates/multiline strings
 for DSLs, or am I the only one who thinks that could somehow be better?




 Thanks for raising this. I agree you've identified a real issue. Referring
 to slide #28 of Domenic's presentation at 
 http://www.slideshare.net/domenicdenicola/es6-the-awesome-parts/23, we'd
 need to add an array of sourcemaps to the frozen[1] record, to parallel the
 raw and cooked arrays, that say where each character of the raw and/or
 cooked arrays come from in the source. The func, which is the
 template-string-parser of the embedded DSL, has no other way to recover
 this information. The source-map-array should probably only describe the
 origins of the characters in the cooked array, since the origins of the
 characters in the raw array can be derived from this but not vice versa.

 None of this would effect the use of template strings in Traceur that John
 describes, as he's interested in source positions in the file being
 translated, not source positions in the template strings within the Traceur
 compiler used to describe these translations. But for debugging Traceur
 itself, one may well be interested in the latter.


 There are several issues with this, none of which are show stoppers:

 1) There is not yet a standard for sourcemaps. But see 
 https://docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k,
 
 https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps,
 and https://github.com/mozilla/source-map/. Would someone care to
 champion this for inclusion in ES7?

 2) Since this can be addressed compatibly in ES7, we should note in ES6
 that future editions may add more frozen data to this record, that can be
 feature tested for.

 3) Code doesn't normally know where it came from. Adding these to
 template-string records will give JavaScript the power of __FILE__ and
 __LINE__.

 4) Browsers are still all over the place in how they report Error stack
 trace information. Even after all the renormalizing done at 
 https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#157,
 we still get the divergent stack traces shown at[2]. For all of these, the
 first stack trace comes from within a call to eval. The second from a
 dynamically generated script tag.


To see these for yourself in your own browsers, visit 
http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/explicit.html
.




 5) At 
 https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#856
 I'm adding the source info that eval is supposed to use, as explained at
 [3], where the alleged source file is http://example.com/fake1.js and 
 http://example.com/fake2.js. (See 
 https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/explicit.html#183.)
 However, that alleged source file name is not showing up in *any* of the
 browser stack traces. Am I not using [3] correctly?


 I would hope all of these could be addressed in ES7, including the
 addition of an array of source maps to the template string record.



 [1] A more correct expansion is:

   var whatsThis = func(
 Object.freeze({
   raw:Object.freeze(['', 

Re: Multiline Strings

[Mark Miller]

On Sat, Mar 8, 2014 at 11:14 AM, Mark Miller erig...@gmail.com wrote:

 [...]
 To see these for yourself in your own browsers, visit 
 http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/explicit.html
 .


and click of the last two [+]s to expand these.

-- 

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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Mark Miller]

No, absolutely not. By lexical, I took Allen to mean the new reliably
block-local binding forms: let, const, class


On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:

 I'm getting vary. Does that mean that you want to change the semantics
 since ES5.1?


 On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller erig...@google.com
 wrote:

 +1.


 On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock al...@wirfs-brock.com
  wrote:

 See
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation


 A better statement of the question would be can we agree that lexical
 bindings created by eval are always non-deletable binding.  Where or not is
 throws which the various modes is already determined by the existing spec.
 for delete based upon whether or not the binding is deletable.

 Allen




 On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote:

 In this context, there are two things you might mean by throws:
 a) That this delete is an early error within the evaled program, and
 therefore throws before any of the code in the evaled program executes.
 b) That the delete is a dynamic error that happens when the delete
 executes, and therefore that the evaled code prior to the delete has
 executed before the error is thrown.

 -1 on #b.

 Assuming you mean #a, between #a and silence, I'm torn. Here are pros and
 cons:
 pro #a: The program is wrong. Silence fails to bring it to anyone's
 attention, making the mistake less likely to be fixed. And making it more
 likely the program's execution deviates from author's intent.
 con #a: Silence on sloppy wrong programs are least surprise, and is
 arguably the most vivid different between sloppy and strict.

 I doubt there's any sensible choices other than #a and silence.



 On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock 
 al...@wirfs-brock.com wrote:

 So, #3 appears to be the winner.

 Given that,  can we also agree that  this is throws (or at least that the
 delete does nothing):

 eval (let x=5; delete x;);

 (bug https://bugs.ecmascript.org/show_bug.cgi?id= )

 Allen



 On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote:

 I'm also fine with 3.

 On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com
 wrote:

 Happy to concede to #3 on my end.  Just wanted to be clear that it seems
 to be optimizing for future happiness vs. least surprising behavior (which
 isn't a bad thing).


 On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com
  wrote:

  On 17/02/2014, at 13:42, Andreas Rossberg wrote:
  On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote:
  Allen Wirfs-Brock wrote:
 
  Another consideration in the back of my mind is that there may be
 useful
  to implementors to knowing that let/const/class declaration are never
  dynamically added to a non-global environment.
 
  +lots, this should be front of mind.
 
  In a block, we want the bindings local to that block to be statically
  analyzable. We want no non-local mode effects. So, #3 still wins.
 
  Strongly seconded.

 And even thirded.

 --
 ( Jorge )();

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




 --
 Jeremy Martin
 661.312.3853
 http://devsmash.com
 @jmar777

 ___
 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




-- 
Text by me above is hereby placed in the public domain

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

Re: Rename Number.prototype.clz to Math.clz

[Mark Miller]

On Thu, Jan 16, 2014 at 12:09 PM, Joshua Bell jsb...@google.com wrote:




 On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller erig...@google.comwrote:

 On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff 
 jason.orendo...@gmail.com wrote:

 At the risk of putting too many nails in the board...

 The rationale seems to propose that (0).clz() === 32, but the
 hypothetical uint64(0).clz() would return 64. That seems like a bad
 idea though. It's weird for two zero values to get such different
 behavior from the same method. It's weird for floating-point numbers
 to have a clz() method in the first place.

 Since these are two different mathematical functions, they should have
 different names: Math.clz32(zero) would be 32 no matter what type of
 zero you pass it; the hypothetical Math.clz64(zero) would of course be
 64. That way users can focus on the mathematical function being
 computed, rather than runtime types.

 Or maybe: flip the function around so that it returns the number of
 bits in the binary expansion of the value: Math.bitlen(15) === 4. This
 is just (32 - CLZ), so it effectively computes the same thing as clz.
 The advantage is that it extends naturally to integers of any size.


 +1. I like this flipping idea by far the best. It can be explained in
 terms of the number being denoted, without referring to the internal
 limitations of any particular representation. With this change, I agree it
 should be a static on Math.

 With this flipped idea, let's think through what the proper .bitlen
 answers are for fractions, negative numbers, NaN, +/- Infinity, and -0.0.


 Would Math.bitlen(Number.MAX_SAFE_INTEGER) return 53 or 32?


Since the point is to make the answer have a mathematical relationship to
the number denoted, rather than the limits of a particular representation,
53.



 (If 53, environments trying to emulate 32-bit ints on top of Number could
 toss in yet another |0 or 0)


yes.


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

Re: Rename Number.prototype.clz to Math.clz

[Mark Miller]

On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert j...@nockert.se wrote:


 On 2014/01/16, at 17:40, Jason Orendorff jason.orendo...@gmail.com
 wrote:

  At the risk of putting too many nails in the board...
 
  The rationale seems to propose that (0).clz() === 32, but the
  hypothetical uint64(0).clz() would return 64. That seems like a bad
  idea though. It's weird for two zero values to get such different
  behavior from the same method. It's weird for floating-point numbers
  to have a clz() method in the first place.
 
  Since these are two different mathematical functions, they should have
  different names: Math.clz32(zero) would be 32 no matter what type of
  zero you pass it; the hypothetical Math.clz64(zero) would of course be
  64. That way users can focus on the mathematical function being
  computed, rather than runtime types.
 
  Or maybe: flip the function around so that it returns the number of
  bits in the binary expansion of the value: Math.bitlen(15) === 4. This
  is just (32 - CLZ), so it effectively computes the same thing as clz.
  The advantage is that it extends naturally to integers of any size.

 What is Math.bitlen(-1) then? Isn’t this just the same problem as before,
 except it happens for negative numbers instead of positive?


Good question. I don't yet have an opinion. But for a baseline, for all the
problem cases (fractions, negative numbers, NaN, +/- Infinity, and -0.0),
what would .clz have done?

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

Re: Additional Set.prototype methods

[Mark Miller]

https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables


On Tue, Dec 31, 2013 at 5:06 PM, Forrest L Norvell forr...@newrelic.comwrote:

 On Tue, Dec 31, 2013 at 2:45 PM, Mark S. Miller erig...@google.comwrote:

 Sets and Maps are deterministically ordered by insertion order.


 I understand how the need to specify a deterministic traversal order for
 for-of led to this result, but doesn't that preclude a number of
 (potentially faster with larger collections) implementation strategies,
 like using hashing under the hood?

 -F

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




-- 
Text by me above is hereby placed in the public domain

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