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&list=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&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2&index=23

Also relevant
https://www.youtube.com/watch?v=wQHjITxQX0g&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2&index=18
https://www.youtube.com/watch?v=9WdbTucMaRo&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2&index=10
https://www.youtube.com/watch?v=pig-sIS8_Wc&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2&index=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  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?
>>>
>>> -kai
>>>
>>> On 3/11/18, Peter Jaszkowiak  wrote:
>>> > Oh

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: Proxy performance: JIT-compilation?

[Mark Miller]

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

> In particular, for many permanently absent traps, the proxy can just pass
>> these through directly to the target without much analysis.
>>
>
> Your suggested changes to the ECMAScript specifications seem to focus on
> permanently absent traps... which doesn't do much good for present traps.
> For instance, new Proxy({}, Reflect), which I mentioned in my initial
> e-mail and, by the way, implements all the traps.  :-)
>

Hence the "many" qualification. It is true that the main use case for
proxies is membranes, in which case all traps are present. But even for
these, if the trap is permanently present, it need only be [[Get]]ed from
the handler once on initializing the proxy. Granted, this is much less
helpful for speeding up implementations, but it is not nothing ;).



>
> --
> "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: JSON text is not a subset of PrimaryExpression

[Mark Miller]

The benefit that I care about more:

"The following regularity holds between A and B except for this tiny edge
case."

is a much greater cognitive burden on everyone, forever, than

"The following regularity holds between A and B."



On Wed, Jul 19, 2017 at 10:09 AM, Mike Samuel  wrote:

> On Wed, Jul 19, 2017 at 12:40 PM, Allen Wirfs-Brock
>  wrote:
> > The “issue” raised is one word in a non-normative paragraph.  It can be
> > corrected with a one word change.  Replace
> >
> > "Valid JSON text is a subset of the ECMAScript PrimaryExpression syntax
> as
> > modified by Step 4 above.”
> >
> > with
> >
> > "Valid JSON text is a variant of the ECMAScript PrimaryExpression syntax
> as
> > modified by Step 4 above.”
>
> +1.  AFAICT, the only benefit "subset" gets us is that it's a bit
> easier to paste JSON into a .js file.
> I doubt a significant number of people are pasting JSON with the
> problematic codepoints but if there are that can be addressed by
> js-mode.el or your favorite analogue.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



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

Re: JSON text is not a subset of PrimaryExpression

[Mark Miller]

Hi Allen, that one word change would correct the inconsistency. I agree
that it is the most that is likely to happen. I would prefer that we
actually fix JS so that it is a superset of JSON, as I preferred during our
es3.1 days. However, I agree that this is
a) even less likely to happen now than it was then, and
b) matters less now than it would have then, since no one has any
remaining excuse for using eval to parse JSON.
Assuming that we are in fact stuck, I agree that we should make that one
word change.

Nevertheless, I would still prefer that we fix JS so that it is a superset
of JSON. I can't say that I care a lot. But if someone does, it would be
good if they could gather statistics on how much existing JS code would
break. Simply scanning for the total number of *.js files in github that
contain a literal \u2028 or \u2029 would give a nice upper bound on that. I
suspect that even this upper bound would be shockingly tiny; but I do not
actually know.



On Wed, Jul 19, 2017 at 9:40 AM, Allen Wirfs-Brock 
wrote:

>
> On Jul 18, 2017, at 9:36 PM, Mark S. Miller  wrote:
>
> I argued for that in the old es3.1 days. IIRC so did Mike Samuel and
> Crock. The pain of doing it now would be higher than it would have been
> then. Nevertheless, I would still be in favor.
>
>
> Why do we care?  ECMAScript and JSON are two distinct languages with their
> own distinct and standardized definitions. And we should be well past the
> time where JS eval is considered to be an acceptable way to process an
> alleged JSON text.
>
> The “issue” raised is one word in a *non-normative paragraph*.  It can be
> corrected with a one word change.  Replace
>
> "Valid JSON text is a subset of the ECMAScript *PrimaryExpression* syntax
> as modified by Step 4 above.”
>
> with
>
> "Valid JSON text is a variant of the ECMAScript *PrimaryExpression*
> syntax as modified by Step 4 above.”
>
> (note that the second sentence of this paragraph is important in that it
> further clarifies that the validity of a JSON text is defined by ECMA-404)
>
> I don’t see such a trivial issue would motivate us start making normative
> changes to either standard when run the risk that such changes would
> opening the door for other proposal to “fix JSON” in some manner or another.
>
> 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: 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  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  wrote:
> > 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
> >>>  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
> >
>



-- 
  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 realm. BTW, shall we add reference to
> func

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"  wrote:
>
>
> > On Oct 26, 2015, at 11:20 AM, Mark Miller  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: 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: 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: 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  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 :
>
>> 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  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  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)
>  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 ":". 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: Will any new features be tied to constructors?

[Mark Miller]

For the record, there are no so-called private symbols. The concept being
referred to here is an implementation-only concept for naming an internal
property. These naming-things are never reified and available to JS code
and must not be.


On Thu, Jul 2, 2015 at 1:22 AM, Andreas Rossberg 
wrote:

> On 1 July 2015 at 17:12, Domenic Denicola  wrote:
>
>> Similarly, for several V8 built-ins, private state is not done via the
>> allocator at all, but instead via "private symbols" that act quite similar
>> to data properties. They can be added or removed at any time. In short,
>> they're much more part of initialization than of allocation.
>>
>
> For the record, the ability to do this is rather an incidental consequence
> of private symbols. We don't remove private state anywhere, nor did I
> intend it to be used that way. There is one case where we add a private
> field dynamically (attaching a stack trace to a thrown object), but that is
> a half-broken hack anyway.
>
> I'd love to have a proper allocation-time notion of private state, like
> Allen & Kevin suggest. You still have weak maps for more dynamic relations.
>
> /Andreas
>
>
> ___
> 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: 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 
wrote:

> On Wed, Jun 17, 2015 at 2:29 PM, Yusuke SUZUKI 
> wrote:
>
>> Thanks. And sorry for the late reply.
>>
>> On Wed, Jun 17, 2015 at 11:31 AM, Mark S. Miller 
>> 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 
>>> 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 siteO

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  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 
> wrote:
>
>> On Sat, Jun 13, 2015 at 9:17 AM, Domenic Denicola  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-di

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 
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 ? "" : 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: Ideas on type hinting and named parameters

[Mark Miller]

On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison  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: PerformPromiseAll

[Mark Miller]

On Wed, Jun 10, 2015 at 7:37 AM, Allen Wirfs-Brock 
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 
> 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: 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 
wrote:

> On Tue, Jun 9, 2015 at 1:43 PM, Mark S. Miller  wrote:
>
>> On Tue, Jun 9, 2015 at 10:38 AM, C. Scott Ananian 
>>  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]

If the prop property accessed by super.prop is an accessor, super.prop = x;
should invoke its setter. super.prop should invoke its getter.

On Tue, Apr 21, 2015 at 4:18 AM, Allen Wirfs-Brock 
wrote:

>
> On Apr 20, 2015, at 12:39 PM, Jason Orendorff wrote:
>
> On Mon, Apr 20, 2015 at 12:44 PM, Allen Wirfs-Brock
>  wrote:
>
> In the spec, 9.1.9 step 4.d.i. is where `super.prop = 2` ends up, with
>
> O=X.prototype.
>
>
> 4.d.1 doesn't set the property, it just comes up with the property
> descriptor to use, if the `Receiver` does not already have a corresponding
> own property.
>
>
> 5.c+5.e checks if the corresponding own property actually exists on the
> `Receiver`.
>
>
> If it already exits then it does a [[DefineOwnProperty]] that only
> specifies the `value` attribute. This should respect the current `writable`
> attribute of the property and hence reject the attempt to change the value.
>
>
> I agree with all of this, except I don't see where the attempt is
> rejected. Since the property is configurable, I think
> [[DefineOwnProperty]] succeeds.
>
> The property is still non-writable afterwards. Only the value changes.
>
> So this isn't breaking the object invariants: the property in question
> is configurable, so it's OK (I guess) to change the value. It's just
> surprising for assignment syntax to succeed in doing it.
>
>
> I think it's bogus and needs to be corrected.  Not only does it allow (in
> weird cases for [[Set]] (ie, assignment) to change the value of a
> non-writable property.  It also means there are cases where [[Set]] will
> convert an accessor property to a data property.
>
> In combination, I think this is a serious bug that needs to be fix in the
> final published ES6 spec.  The fix I propose is in 9.1.9 to replace Set 5.e
> as follows:
>
> 5.e If *existingDescriptor* is not *undefined*, then
>i.   If IsAccessorDescript(*existingDescript*), return *false*.
>ii.  If *existingDescriptor*.[[Writable]] is *false*, return
> *false*.
>iii.  Let *valueDesc* be the PropertyDescriptor{[[Value]]: *V*}.
>iv.  Return *Receiver*.[[DefineOwnProperty]](*P*, *valueDesc*).
>
> Lines 5.e.i and 5.e.ii are new additions.
>
> Thoughts?
> 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: 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 
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 
> 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  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  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 
> wrote:
>
>> On 17 April 2015 at 17:27, Mark S. Miller  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 
 wrote:

> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
>  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 
> 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  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

 ___
 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 
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  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 
> wrote:
>
>> I don't understand. Could you show example code? Thanks.
>>
>>
>>
>> On Wed, Mar 11, 2015 at 12:00 PM, John Lenz 
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 10, 2015 at 9:10 PM, Mark S. Miller 
>>> wrote:
>>>
 On Tue, Mar 10, 2015 at 9:02 PM, Domenic Denicola  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 
> 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 
> wrote:
>
>  On Chrome and Opera (v8), <
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debu

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  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 10:45 AM, Allen Wirfs-Brock 
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: Cancellation architectural observations

[Mark Miller]

On Mon, Mar 2, 2015 at 10:25 AM, Dean Tribble  wrote:

> On Mon, Mar 2, 2015 at 6:32 AM, Gray Zhang  wrote:
>
>> +1 to the ignore term, I’ve opened an issue about it in
>> https://github.com/promises-aplus/cancellation-spec/issues/14
>>
> I have little attachment to any term, but there's value in keeping
> terminology that has years of investment and use in other contexts. However
> "ignore" also has the wrong sense, because it implies that the computation
> completes anyway. That can be accomplished more easily by simply dropping
> the promise.
>

Agree. But I feel even more strongly that "cancel" is the right term and
"ignore" the wrong one. In the real world, when I order something to be
delivered, if I then decide to "ignore" it, that describes how I react to
receiving the package. It is a private decision about how I will react and
does *not* communicate any information to the sender about that decision.
If I attempt to cancel the order, I may or may not receive the package
because of the asynchronous race that Dean describes. But even if I receive
the package, it does not violate my encapsulation expectations for the
sender to find out that I attempted to cancel.


IMO the term cancel(or abort) and ignore are totally different things, the
>> former one means “do not continue, stop it right now” and the “stop” state
>> should be broadcast to everyone who is interested in the work, while the
>> latter means “I don’t care about the result anymore, just play it as you
>> like”, it means the async progress can be continued
>>
>  This goes back to some of the observations above: you cannot stop it
> "right now" because async notification is not synchronous; indeed the
> operation may already be complete before you stop it. Thus consumers of the
> result of a cancellable request need to be able to handle either successful
> completion or the cancelled state (which just looks like any other error
> that prevented completion).  Attempting broadcast to "everyone" adds
> complexity and resources that are needed only in the rare cancellation
> case. It's typically not only not worth the software complexity, but not a
> good idea. When you cancel a print job, the document editor should make
> best efforts in the background to stop requesting fonts, stop laying out
> print pages, stop spitting out pages on the printer, etc. but most
> importantly, it should start paying attention to my new edits and hang
> waiting for everything that might be involved in printing to wrap itself up.
>
>> In practice both scenario are commonly seen, we may abort a resource
>> fetch in order to save bandwidth and opened connections, or we may in other
>> side just ignore it since continue to complete the fetch can result in a
>> local cache, which speeds up our fetch next time
>>
> The resource point is important. That's the "don't care" scenario, not the
> "abort" scenario. It's the request processor that knows what cleanup is
> worth the effort. The initiator of the request only knows they don't care
> about the result anymore.
>



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

>
>
> On Thu Feb 26 2015 at 8:22:55 PM Claude Pache 
> wrote:
>
>>
>> > Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock  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: Function "name" property

[Mark Miller]

On Feb 26, 2015 5:04 PM, "Allen Wirfs-Brock"  wrote:
>
...[arrow functions]...
>
> If we went that route I'd probably still stick with 'function.next' for
that use case

Since we don't have arrow generator functions...

> 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

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

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  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.org&ie=utf-8&oe=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 

Re: Global method calls

[Mark Miller]

On Sun, Feb 22, 2015 at 1:03 PM, Domenic Denicola  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
>
> 
>   addEventListener("foo", function () { });
> 
>
> 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:
>
> 
> window.globalFunc = function () {
> console.log("this", this);
> };
> 
>
> 
> "use strict";
> globalFunc();
> 
>
> 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: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

[Mark Miller]

On Thu, Feb 19, 2015 at 12:14 PM, Axel Rauschmayer  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]

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


On Sat, Jan 24, 2015 at 2:57 PM, Mark Miller  wrote:

>
>
> On Sat, Jan 24, 2015 at 2:42 PM, Isiah Meadows 
> wrote:
>
>> > From: "Mark S. Miller" 
>> > To: Gary Guo 
>> > Cc: "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  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: @@toStringTag spoofing for null and undefined

[Mark Miller]

On Sat, Jan 24, 2015 at 2:42 PM, Isiah Meadows  wrote:

> > From: "Mark S. Miller" 
> > To: Gary Guo 
> > Cc: "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  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  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  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: JavaScript 2015?

[Mark Miller]

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


On Thu, Jan 22, 2015 at 4:17 PM, Brendan Eich  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 1:05 PM, Jordan Harband  wrote:

> > Just checking: Are we talking about adding it to each instance as a
> non-configurable non-writable data property?
>
> Mark: No, not to each instance, but to Array.prototype,
> Function.prototype, etc. If someone wants to override it on a specific
> instance that's fine, and I don't think it's important to protect against
> that.
>

In that case, I find this unacceptable, as it breaks the branding invariant
that some legacy ES5 code depends on.



>
> > I would not be happy with making the built-ins nonconfigurable. Just
> like Function.prototype.length, it should be unlocked.
>
> Domenic: Changing Function#length makes sense to me - the Function#bind
> shim does nasty things to ensure "length" is set properly, for example, and
> it would be much easier if the length was editable. Do you have a use case
> in mind where you'd want to change a language builtins' @@toStringTag value?
>
> We can always unlock it later, but it seems like we can't lock it down
> once it's unlocked, so without any valid use cases, it seems like a risky
> move to unlock it now.
>
> On Wed, Jan 21, 2015 at 1:00 PM, Mark S. Miller 
> wrote:
>
>> On Wed, Jan 21, 2015 at 12:57 PM, Mark Miller  wrote:
>> [...]
>>
>>> 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?
>>>
>>
>> Sorry, incomplete question. Meant:
>>
>> Just checking: Are we talking about adding it to each instance as a
>> non-configurable non-writable data property?
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
>


-- 
  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  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 
> 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
 wrote:
>
>
> On Thu, Dec 18, 2014 at 6:01 PM, Mark S. Miller  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 (){\n"use 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:49 PM, Boris Zbarsky  wrote:
> On 12/4/14, 4:45 PM, Mark Miller wrote:
>>
>> On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky  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



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




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]

On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky  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
> .
>
>> 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-di

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

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

>
>
> On Wed, Oct 22, 2014 at 5:26 PM, Mark Miller  wrote:
>
>>
>>
>> On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink  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: Proposal: Abstract References

[Mark Miller]

On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink  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 

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

>
>
> On Sun, Oct 19, 2014 at 2:23 PM, Allen Wirfs-Brock 
> 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 
wrote:

> On 1 October 2014 16:09, Erik Arvidsson  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: Throwing errors on mutating immutable bindings

[Mark Miller]

On Wed, Oct 1, 2014 at 9:15 AM, Allen Wirfs-Brock 
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 
> 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: Array.prototype.contains solutions

[Mark Miller]

On Wed, Oct 1, 2014 at 12:21 AM, Brendan Eich  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: 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  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"  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"  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  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" 
>>> 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  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 12:50 PM, Garrett Smith 
wrote:

> On 9/7/14, Andrea Giammarchi  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: "use strict" VS setTimeout

[Mark Miller]

On Sun, Sep 7, 2014 at 11:44 AM, Garrett Smith 
wrote:

> On 9/7/14, Domenic Denicola  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 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  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: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  wrote:
>
>> On Sep 7, 2014, at 19:47 , Mark S. Miller  wrote:
>>
>> On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens 
>> wrote:
>>
>>> On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
>>>  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 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 https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=a...@rauschma.de>>
wrote:

> On Sep 7, 2014, at 19:47 , Mark S. Miller  >
> wrote:
>
> On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens  >
> wrote:
>
>> On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
>> > >
>> 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: 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 
wrote:

> On Tue, Jun 17, 2014 at 11:33 AM, Allen Wirfs-Brock
>  wrote:
> > I'm not sure who introduced the idea that the Date.prototype should have
> a
> > "zero value", but that is inconsistent with ES3&5 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 
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 9:50 AM, Ian Hickson  wrote:
[...]

> This suggests that the plan should be to instead make sure that whatever
> ES6 defines can be used by other specs to define the Web's loading model.
> Is extending the ES6 model (not the API, but the underlying model with
> load records and so on) something that could be on the table?


Compatibly extending the ES6 model *after* ES6 is certainly on the table.
Regarding ES6 itself, not unless it's critical, and perhaps not even then,
depending. That ship is sailing, airplane doors have closed, or whatever
metaphor you like ;).

What's a "load record"?

-- 
  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  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: Integrating the Webs' dependency systems

[Mark Miller]

On Thu, May 29, 2014 at 8:20 AM, Boris Zbarsky  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: 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
wrote:

> On Tue, Apr 29, 2014 at 8:08 PM, Mark S. Miller 
> 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