January 26th 2016 Meeting Notes

January 26th 2016 Meeting Notes

Eric Farriauolo (EF), Caridy Patino (CP), Michael Ficarra (MF), Peter
Jensen (PJ), Domenic Denicola (DD), Jordan Harband (JHD), Leland Richardson
(LM), Chip Morningstar (CM), Brian Terlson (BT), John Neumann (JN), Dave
Herman (DH), Yehuda Katz (YK), Jeff Morrison (JM), Lee Byron (LB), Daniel
Ehrenberg (DE), Lars Hansen (LH), Nagy Hostafa (NH), Michael Saboff (MS),
John Buchanan (JB), Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar
Horwat (WH), Mark S. Miller (MM), Paul Leathers (PL), Sebastian Markbage
(SM), Zibi Braniecki (ZB), Andreas Rossberg (ARB), Ian Halliday (IH), Keith
Miller (KM), Tim Disney (TD), Misko Hevery (MH), Brad Green (BG), Kevin
Smith (KS), Brad Nelson (BN), JF Bastien (JFB), Shu-yu Guo (SYG), Rick
Waldron (RW), Staś Małolepszy (STM), Dean Tribble (DT)


## Agenda

https://github.com/tc39/agendas/blob/master/2016/01.md


## Approval of the minutes from November 2015

WH: what sort of changes?

JHD: some editorial cleanup

#### Conclusion/Resolution

  - Minutes approved.



## 5. Proposals for Future Editions

## 5.i Zones

DD: Misko is presenting, zones.

https://docs.google.com/presentation/d/1H3E2ToJ8VHgZS8eS6bRv-vg5OksObj5wv6gyzJJwOK0/edit#slide=id.p

MH: Writing async code is hard, specifically book keeping of (begin/end of
async tasks). Specifically for framework authoring, and cooperation between
various components. In other langauges, this may be "domains" or "contexts".

MH: some existing implementations, Angular Zone.js, Zone, Dart Zones,
Node.js domains/continuation local storage/asyncwrap, c# logical call
context etc.

MH: this has been around for some time, but the lack of standarization
prevents interopt and may also prevent more ideal solutions.

MH: Frameworks often what to know when work has begun and completing, this
allows for batching.

WH: Can you clarify the example?

MH: In a typcial application, a whole orchistration of async tasks occurs

YK: browser do this already, flush work -> calculate changes -> paint.

MH: by annotating different context, prioritizaing is possible. One example
would be animation context vs ..

WH: thanks

MH: another example is testing, existing solutions result in test
"flickering", but using zones would enable some determism.

BT: test262 would benefit from this, existing solutions require manual book
keeping and tracking. No way to tell in the browser when a set of async
operations have completed.

SP: it adds determism

MH: another use-case, is for measuring and instrumentation.

SP: you may also have interleaving plans, this helps group them and
mitigate some common related issues

MH: good error handling, with zones you get the error handling for free.
Global error handling lacks sufficient context

MH: You can also associate errors with the originating/initiating event for
tracing/debugging scenarios.

DD: these actions can happen concurrently, an example would be an HTTP
server serving many requests, each would want a zone To associated relevant
signals.

MH: When you have unit test you want to know when everything is done so you
can clean up to prepare for the next test in a clean state.

MH: this would also prevent test polution

MH: How would this work?  Zone.current

MM: are you proposing global state that yields different values over time

MF: would a meta property be ok

MM: I had not considered this, it raises other questions

YK: this is a hypothetical API

MM: I understand this

MH: Time changes over time as well, but you cannot mutatie it yourself.
`Zone.current` is similar in this regard.

...

MH: in a promise example, the callback would be associated with the zone it
was instantiated in. So when invoked, it would remember its zone.

JM: how do zones change

DD: it hasn't been presented yet

YK: it is possible to create this API self hosted

DD: only if all async was hooked, and a transpiler for async/await

YK: I meant, if a user wrote this manually it would work

MH: Correct.

MH: We could monkey patch the then method, but their are limitations. These
limitations include user-land task-queues, and other foreign async.

YK: and its common

MH: if they don't properly capture the zone, the value diminishes.

MH:

YK: ember has a mechanism, but without a standard interopt is hard.

MH: yes

DH: TLS analogy is the strongest one, async in JS is cooperative userland
threads. What i haven't seen is, how to create such zones.

BT: So you said current implentations have holes?

MH/YK: It's insufficient to monkey-patch everything because frameworks
might have their own event loop.

MH:  we need to provide the right primites so the platforms do the right
thing.

MH: Now how to make new zones "slide: more realistic Example"

MH: Zones also offer local storage, and it is valuable

DD: The "node cloud team at google" wants TLS.

MH: ... describes other details, and suggests to look at the respositor...

MM: What prevents you from calling a zone transition sync

BT: that is embers use-case

MM: run calls the provided closure sync?

MH: correct, the only way to cahnge the zone is to call run or to call a
wrapped function.

DD: run is to wrap, as call is to bind.

MM: the binding of rURL is it mutable? (referring to slide #12 "More
Realistic Example")

MH: they are immutable

DD: one can put in a mutable structure

MM: the accessors are referenced via string, is that important?

MH: doesn't seem so.

MH: child zones inherit the parents zones

DT: can you arrange to merge multiple ancestors

DD: you can arrange manually yes

MH: we don't support that today.

(MM: Somewhere in here I made the point that asynchronous causality is a
graph, but Zones needs to treat it as a tree.
At the base, the triggering of a callback has two causal ancestors, the
registration of the callback and the triggering
of the condition that the callback should be notified about. In promises,
these are respectively the .then and the settling
of the promise. All is a higher level pattern in which an outcome has more
than two causal inputs.

What I finally understood from the discussion is that Zone's always follows
only the registration, not the triggering, and
this does always pick a tree out of the causality graph. However, it is
often not the tree that most intuitively corresponds
to the programmer's understanding of causality in their programs.
See http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html)

MM: let me share when this would come in force, a Promise.all where the
promise inputs were sourced from multiple zones.

SP: Only the callbacks will capture the zone, Promise.all itself wont'
capture the zone, rather the callback passed to resulting promise one.

YK: i think we are making the graph vs tree mistake here

MH: the registration captures the zone

YK: I think MM is saying multiple consumer may want to be part of the
causality

MM: Whoever invoked the then sets the zone

YK: that may not be correct

YK: let me try to say what the two use-cases are:

    1. somethingly ike TLS, sounds good.
    2. life-cycles hooks around stack pushing and popping, and that is
extremely importent for flushing and rendering.

DD: i don't want to get into the hooks discussion yet

MM:  We need a standard API for the "wrap", the implementation isn't that
important.

YK: The DOM has to do something, we will have to standardize.

DD: the host environment needs to register a callback, so a hook could be
imagined.

MM: the fact that you are propagating from the registration, but that
conflicts with the addEventListener example

SP: no this will work as expected as it will merely be another fork.

MM: If the first thing a zone does is execute a zone.wrap then the invoking
zone gets throw away?

MH: The first thing I do in a click handler is to ask for a zone and do all
the work in it.

MM: Okay.

YK: I agree that you could make these be trees, but I think it's bad that
you can't handle multiple sources.

DD: Disagree as apps aren't trying to track this.  We can take this offline
to discuss more though.

YK: the concern that i have, is that causality and execution branching are
intermixed. Frameworks will be the same place we are today, enumerating all
the potential entry points.

MH: I'm having a hard time understanding

YK: do you enumerate all eventHandlers?

MH: no

MH: I want to make sure angular knows about everything, a second problem is
to track user behavior flow. I would argue this requires hand tuning.

MH: Usually, zones trigger on router changes.  App changes route and a new
zone handles tracking from there.

WH: How do zones interact with iterators and generators? What happens if
you start one from zone A and then call next from zone B?

DD: you suspect the execution context from the generator

MH: is this not the same as async

YK: presumably

YK: the data is stored on the execution context, pause resume should work.

MH: presents a strawman "slide: MVP API"

MH this is missing error handling, but that is handled by zone spec. Zone
spec describes the details.

DD: having the fully customized wrap may not make it, as it makes some of
us nervous.

MH: You get to wrap the callback into the wrap, but at the end of the day
you don't get to override the Zone.  Fundamentally, the result will be on
the zone that was wrapped.

DD: Browser engineers are very unhappy about having to call code whenever
setTimeout is called

YK: await having to do this is quite scary.

YK: if you don't monkey patch the world, the platform can be performant.
This makes it somewhat scary.

WH: What's so special about 'then'? If a user implemented his own
scheduling and callback mechanism analogous to 'then', would that capture
and propagate zones from the creators of the callbacks or would it
propagate them from the callers of the callbacks?

YK: i would hope async/await offers possibilities for optimization

SP: I believe async function would capture the zone

YK: await having different semantics seems like a refactoring hazard.

DD: if there is no callback, then there is no wrap.

SP: YK is the concern that the refactor from .then(...) -> await shouldn't
change the instrumentation calls?

YK: yes

YK: wrapping allows you to intercept the scheudling

MH: no, wrapping is only post scheduling

MM: what about realms? onFulfilled could be in a different realm. The
execution stack can thread through many realms.

*various members mime mushroom clouds*

** collective brain splosion**

MH: passing a callback from iframe1 -> frame2,

DD: we could handle this like bind, and let it work.

SP: what about cross realm data leaks.

DD: i think this is solvable, but the cross realm point is a good catch. We
will need to explore this.

...: Examples have a then block presented statically, if the function

MM: it is the registration of the callback not the instantiation of the
promise nor the function.

DH: I have questions about intra-thread uses of the API.  Two questions:

    1. You have .get but not .set you can put immutable things in the .get
so I'm not sure what it buys you to make it immutable.

MH: One property I'd like to have is that for apps that expect zone
behavior, when you fork a child zone, application should behave the same
way as without the fork.

DH: Only true if users don't mutate things.  Is it vital for the language
to enforce this guarantee?

MH: You can certainly override a property and that COULD break behavior.
If code running in a child zone could mutate the parent then you couldn't
see it in the parent.

DH: I didn't understand

DD: I'll rephrase -- if you allow children to set new properties, then they
don't share the idea across the boundary.  This is more of a path we want
to guide you down rather than a path that must be enforced.

DH: I have a question that may clarify around lack of .set.  There's
history for other languages with TLS with use cases for what has
historically been achieved through dynamic scope.  A concrete example
program would be a recursive descent JS parser.  You have certain context
being passed around like the labeles currently in scope.  Only used a few
places in the parser.  It's a total pain to keep track.  Other option is to
use an OO pattern to carry context in a class/object so it's still
explicit, but it's shrunk to one place.  Another mechanism is to use a TLS
(thread local storage) like mechansim or dynamic scoping so this becomes
implicit.  Only operations that need to access the state go through this.
One answer could be we disavow this and say the OO way is the right way to
do this.  Another answer is to say this (zone) is right for doing this.
Creating new zones is a heavy-weight api.  Is there a lightweight user-land
abstraction?  Is there no place for .set there?

YK: why not just provide set

MH: get will walk up the hirachy but set will not hence get/set are not
symmetric.

YK: sounds like prototypes

WH: what you are after is dynamic scoping, and this is not dynamic scoping.

MM: two ways to implement dynamic scoping, shallow binding or deep binding.
This is deep binding

DH: set is not a distraction here, the temp modify and revert is
orthogonal, but in particulate in the dynamic set you actually want to use
mutation.

MM: this sounds ok

DH: what does the UX look and feel like, when you are actually doing this.
We may say, we don't care because its not a valid use-case. Could we build
a library on top of this to improve the ergonomics

CM: if you make the zone mutable, you have taken away the immutability.

DH: yes

YK:  I am not wrong that using a mutable object in the slot. The parent
zone will see mutation in the values.

DE: a problem with dynamic scoping with set, is that you may have  an outer
scope that introduces a var, and an inner scope that defines a different
variable. The hazard is accidentally overriding an unintentially is common,
so disallowing set fixes this issue.

DH: we should do some exploration, using this API in those use-case and see
if it falls over. We may decide that is not appropriate at all. OO may be a
better way to solve this problem, although I myself am unsure what is the


DT: If A passes a zone to B and then to C, A could arrange so that B could
change the state the C sees. A may want to arrange so that they are
isolated very specifically. A needs to be sure, B cannot interfere with C
etc. If we add set, A would need to add many defensive layers in-case of a
malicious actor.

YK: a symmetrical problem is users may not realize the deep mutability.

SP: think prototype.value = {}  vs prototype.value = 1;, the former shares
state the later cannot.

MH: I feel zones are more like an observer like a logging service.  They
get to watch over how an app runs and notify you to do something about it.
Whether it's there or not, the app should function the same way.

DH: maybe the answer if you are using thread local dynamic scoping, it
should not be built on top of zones.

YK: Arriving at "you should not put mutable objects there" is good.
(referring to values passed into the zone)

MM: The proposal as it stand, there are some good goals that we should seek
a way to address.  Kudos on the good goals.  The mechanisms as proposed
combine several nightmares -- mutable global state, dynamic scoping, and
before/after hooks. Before/after hooks reminds me of the nightmare of
aspect oriented programming. They introduce an attack vector of invoking
someone else's code during a turn while invariants are supended.
Classically a thread is a sequential program, TLS (thread local storage) is
a global variable for that sequential program.  In TC39, we have
successfully avoided global state -- if you lock down all the primordials,
everything still works so far. We must keep that property.  LISP has
dynamic scoping.  Scheme has fluid scoping. In Fluid scoping, thing that
changes depending on the context you're in is the value of a lexical
variable.  You cannot see the values or rebind that var if you're not in
the lexical scope.  The strings are worse than classical dynamic scoping
because the program can calculate the strings.  Making them something first
class or record based -- we should look how to restrict how you name those
things.  Otherwise you have a truly global variable.

YK: if you are too restrictive, people will end up virtualizing again.

MM: If you have fluid variables, you don't need to reinvent dynamic
variables.  They're still bad, but less bad.  I'm firmly on the lexical
scoping side of the debate.

YK: i think everyone agrees with that. Lexical scoping is the 99.9% case,
some things don't quite fit in that. You can use globals or OO, all of them
have issues. If you end up restricting, users will end up approximating the
same thing.

MM: for most of the motivating problems for dynamic scoping, if rethought,
lexical scoping patterns typically address the issues nicely.

YK: Who is the one rethinking it?  If it's an app developer, they won't end
up doing it.

MM: I want to think through the concepts presented here without being
anti-modular.

DD: to draw this to a close, why does this need to be in the language.
Patching is hazardous, coordination between many collaborators is of value.
We would like to move this to stage 0

MM: what does it mean to approve something to stage 0

DH: I think it's well motivated problem.

YK: well motivated problem

MM: if I endorse some of the goals but not the mechanisms, can I approve
stage 0?

DD: Yes, and we encourage collaboration with the champions.  Just want to
move to stage zero if we can.

YK: Stage zero seems fine.


#### Conclusion/Resolution

 - stage 0 approved


### Announcement

MM: Does ECMA have rules for NDA's signed at these meetings? Participants
should not be required to sign an NDA, the company should protect its own
secrets it should not be the burden of the participants.

We need to do some diligence, some work for the next meeting.

SP: Lots of these NDA's are totally incompatible with the nature of this TC

An email has been sent to Istvan, and Salesforce will be contacted.

Its completely not binding, if it was not obvious.


## 5.iii Shared memory and Atomics (proposal)

Presented by Lars Hansen

(request slides)

LH: motivation, why we need this. We will also go over some of the
september concerns

(presenting slides)

Slides:
https://github.com/lars-t-hansen/ecmascript_sharedmem/blob/master/tc39/presentation-jan-2016.odp

LH: Why not only for wasm?
YK: wasm will want to be sync exposable from JS which transitively means
these constructs need to shared.

LH:  next slide willl cover that

LH: Why not only for wasm (2)

YK: we could say, wasm is only accesible async

LH: we can't really

YK: this is a platform feature

MM: workers that have access to shared memory, are only available async.

LH: what i am proposing is that we are proposing, is that JS define these
semantics. This would give it some teeth, and enable healthier interopt.

DH: "if you're gonna drink, you're doing it under my roof"?

LH: Why not only for wasm? (3)

MM:  given a shared memory buffer, each worker would be seeing it through a
set of types. There is nothing that enforces which types, corect?

LH: correct

LH: why not something completely different?

YK: we also don't know what it is

DH: if we want, I could put a team on it for a couple of years

LH: what is Pjs?

** parallel JavaScript **

A: Why is racy required

LH: its hard to imagine C++ program that isn't racy

WH: Depends on what you mean by "racy". You can trivially eliminate all
data race undefined behavior from a C++ program by turning all memory
accesses into atomics. The execution would still be racy (i.e.
unpredictable), but it would not be racy (i.e. have races causing undefined
C++ behavior according to its memory model). The two meanings of "racy" are
quite distinct.

A: one approach I could see, is the JS side only has synchronized acess to
the array buffer.

LH: concerns about slow

MM: pony + rust provide strong rules, can we enforce this?

LH: that is off the table

DH: Don't know how to track ownership and infer types inside the asm.js
typed array.

MM: the point that i am making, is that the type reasoning i am speaking of
is only that of the typed array.

DH: but there is only 1 typed array for the program

DH: I can't make sense of this

YK: 1 heap, that is shared across threads, without races.

MM: no runtime cost im not claiming, there is a step (from dynamic ->
static) that may involve an additional test.

YK: do you believe this cost would be cheap?

MM: im assuming (hope) it will be cheap

LH: I would like to present this proposal not what MM is speaking about,
but what MM is speaking of is interesting.

LH: Some sort of integrity

DH: I was thrown off, because it is much more general.

...

DH: imagine that we had 1 big typed array, but where you could checkout
sections of the array with different permissions (rw r) the sharing would
be controller based on the permissions one had. This would allow improved
concurrency, and safety. It can be data-race free, but would require some
clunkyness. Alll this could be done via the message passing system, this
could be spec'd and implemented.

LH:  the point is, this kind of sharing DH is talking about has some issues
and likely requires a better type system than JS has. Multidimensional
arrays make this more complicated, (what killed it, i missed it..)

LH: for ecmascript, we likely require a better system. But we have this
system today.

LH: I have decided to provide a low level system, and build a better system
on top.

DH: A bigger KO, is that this can't come anywhere near the performance of
the pure shared array buffer. Message passing comes at a heavy cost, as the
hardware support for racy shared access enables order of magnitudes better
performance

... Would a more constrained compile target not just solve this.

LH: unity compiled some benchmarks, using shared buffer they benifited from
4x speed-up.

LH: this API is a good basis to build a system on

WH: what is the API

LH:

DH: We have done multiple years exploring this. With intel + Mozzilla, we
looked at race free high level API's and we really couldn't come to
something that would work. It's not to say we are the only people to solve
this problem, but their is limit to how much we can explore.

BE: WH you were ill and were not present to attend when this was presented
the last time.

LH: the shared buffer spec is small and stable

DE: In release behind a flag (in chrome)

LH: alpha/beta/release will be behind a flag (on FF)

LH: slide (API: Shared memory)

LH: slide (API: Atomic Operations)

LH: regular access to not guarentee tearing

WH: so everything is sequentially consistent, which is far slower than
acquire/release on, say, x86

LH: atomic access are sequentially consistent

What is the safe guarentee?

LH: you cannot step outside the array, and the types remain safe.

WH: There is more to memory safety than that. Java got into trouble with
this, and it caused grief for C++. Reading a value and using it twice, due
to common optimizations, could result in seeing different values. Booleans
that are neiter true or false, not because of strange bit patterns, but
because of optimizations affecting the order of memory operations. If you
try to nail this down so that it could never happen, we must restrict the
optimizations to a level that hurts performance.

LH: slide (API: Agent sleep and wakeup)

LH: futexWait must no longer be used on the main thread of the browser.

LH: slide (Agent model)

DH: what does a forward progress guarentee mean

LH: more or less a fair scheduling guarentee

DD: are agents continents?

MM: worker goes through a sequence of jobs, there is a full ordering of
jobs in any one worker. Each worker is a sequential program. Concurrency is
between workers. I would be surprised if the division into jobs becomes
relevant

LH: i likely misspoke, my agents are most likely similar to what you call a
vat.

MM: ok, so each agent executes a fully order sequences of jobs, where each
job is executed to completion before starting the next job.

JFB: C++ is exploring forward progress guarentees to support weaker models,
such as SIMD lanes or fibers. Its more a technical point.

JFB: C++ has spent many hours discussion this, it is quite complex.

LH: slide (Agent Mapping)

LH: to wrap this up, how you create agents, what they are and how you share
them is all mapping specific. Browser vs node would be totally different.

LH: in a browser it would be a worker, WW semantics need much work.

LH: again, no futuxWait on the main thread.

MM: you are assuming agents are only coupled via shared array buffer or
asynchronously

LH: Slide (Memory model)

Totally ordered relative to a thread?

LH: totally ordered base don the atomics

Physics doesn't let you have that, so..

WH: no you can

LH: atomic operations from JS on all shared array buffers in your browser
are totally ordered

JFB: the non atomic operations are all unordered, if you don't have atomics
between them, everything can be re-ordered. The atomics provide ordering
through happens-before with the non-atomic operations. The atomics provide
inter-threads-happens-before between each other.

WH: I am not sure I believe you

JFB: there is a formal proof for the C++ model, there should also be a
formal proof for this one before it is standardize.

WH: read behaves as sequentially consistent acquire, I don't know what
happens if you try to load/release in c++ memory model

JFB: there is no load/release.. I believe this is beyond this content.

M: any atomic operation is sequentially consistent even if it is unrelated.

Browser that is spending many independent process, sharing memory is
complicated. Im not sure what it means for them to be ordered

LH: total order not sequential order.

LH: slide (memory model 2)

LH: this is easy to reason about, but slower then alternatives

WH: what happens during a race?

MM: once you read a value, does it remain stable or can it change?

WH: Do you get classical garbage or quantum garbage? (Quantum garbage is
what happens in C++: reading a racy value and storing it into a temporary
can cause the temporary to later spontaneously change its value).

LH: i don't believe so

MM: so quantum garbage

LH: Yes, quantum garbage.

JFB: architecture differences can make this impossible.

LH: im wrestling with if that is reasonable, we have already defined races
will create garbage, we are defining now how bad that garbage is. Even if
you read garbage, the garbage is sensible for the type that you are reading.

LH: some interesting complications, since we are using typed arrays, we can
alias arrays, we can have atomic and non-atomic operations operating on the
same array at the same time. Interesting problem for weakly ordered
scenarios. We would like to give races a little bit of meaning. We want
them to have enough meaning, so we don't crash the system

MM: weakly ordered data describes this

LH: yes

MM: tearing is a out of thin-air value

LH: nono that happens in a non-racy scenarios

WH: That is a different concept, memory models do not always match the
intuitive notion of causality. For example, the C++ memory model allows you
to write programs that test whether an atomic value is 42, and set it to 42
if it was 42, and the optimizer can cause, via various memory model
deduction rules, to cause the test to become self-fulfilling.

LH: relaxed atomics can cause this, we address this with strong atomics

...

LH: lets  continue

LH: slide (Other memory model issues)

LH: the goal is to high performance, but we will get there

WH: i am concerned that this is the wrong starting point

can we get some numbers and see the difference

WH: Providing a low-level library that implements sequential consistency
only instead of also supporting acquire-release-relaxed seems like
defeating the purpose of the effort. Requiring sequential consistency on
reads/writes is several times slower than just doing acquire-release
semantics on reads/writes on x86. Sequential consistency only seems like
the wrong starting point because it throws away so much performance
compared to acquire/release, which almost always suffices. The point of
this effort is to go for high performance.

LH: any questions:

MM: you mentioned we avoid blocking the main thread, can we also make it so
high-speed access is ???.

LH: in principle yes, TypedArray constructers made illegal on the main
thread would enable this. This may strike some people as strange, but in
principle yes

YK: UI and IO threads blocking is a well known thing, I suspect not one
will notice

LH: I believe MM was thinking disabled access to the shared memory from the
same thread. But i would suggest that would be practical.

BN: WebGL is on the main thread, not having access to shared memory on the
main thread would be unfortunate

LH: i believe MM proposes workers having access to such things

LH: slide (futexWait on the main thread)

LH: slide (futuxWaitCallback)

YK: isn't message channel more compisition then postMessage

LH: maybe we should hold off on this then

LH: slide (side-channel attack)

LH: slide (cache attack)

YK: i have a general question, other sandboxes allow this, how are we
different? iOS sandbox etc. Prior art?

LH: Im sure they have thought about this, but not alot of evidence they
care about it

WH: Those things were designed at a time when timing attacks just weren't
on the radar. They're all vulnerable to cache timing attack mischief. A
large mitigating factor is that evil apps can be reviewed and revoked with
at least a modicum of success. Browsers on the other hand must deal with
arbitrary evil content.

DH: We live in a world, were forcing users to essentially install by merely
navigating is true. Maybe we can prevent this, bringing us in-line with the
iOS or similar sandboxes.

DH: we have strong signals, we can detect if an API caused the navigation
or a user. This may be sufficient.

LH: lets push this on the stack for two more slides

LH: Existing tech (Flash/Java/PNaCL/NaCL) already demonstrate them.

MM: I would like to point out on this slide (status quo?) flash, java,
nacl/pnacl are dead or dying. The fact that those exists, does not mean we
need to put up with this.

LH: I'm not saying that, only stating the current state.

(MM: A clearer statement I wish I said: "if we find the danger is bad
enough, browser makers could turn off flash, java, and nacl/pnacl. iPad has
already turned off flash. Many have turned off java. No one but chrome runs
nacl or pnacl. OTOH, once this goes into javascript, it becomes impossible
to turn off. So these prior systems do not commit us so strongly that we
can deny that our actions today make things worse." Some of this was said
in the unrecorded verbal discussion, but not as clearly.)

JFB: Tne google teams (chrome & security team) do not believe this attack
vector matters. Timing isn't the attack, rather a mechanism of leak.
Non-constant time crypto can be observed. Many ways to observe this state,
the google security believes the problem is with non-constant time crypto
itself, which should be fixed.

JFB: there is a large number of existing leaks, which need to be addressed,
the timer is only the messanger not the route cause.

WH: Yes, non-constant time operations are vulnerable. But constant time
operations are also vulnerable, as long as they access data-dependent
memory locations within a cache shared by the attacker.

DH: performance.now was throttle for these reasons, was this to mitigate
existing leaks, essentially buying more time?

JFB: I believe it was partly that, and partly because that precision was
not required. It's a cost a running close to the metal, that you can
observe the metal, preventing that defeats the feature

JFB: when the performance.now thing happened, it seems low cost to change
(likely no-one depended on it) so given that something could be observed it
was adjusted.

JFB: given this is going to happen, there will be high resolution timer.
The course of action is to fix the route causes.

LH: the current resolution is already sufficient for these issues.

JFB: with row hammer you can flip bits without atomics, because of hardware
issues.

LH: I haven't found any evidence of this making it worse.

YK: it doesn't seem like we are the first to encounter this

LH: we may be exposing something, so we should becareful

YK: it merely feels inappropriate to have panic mode

LH: i can agree witb this.

WH: I believe in defence in depth, it is extremely difficult to transition
all code that handles secrets to run in constant time with data-invariant
memory access patterns. It's likely impossible. This applies to all code
running on the machine, not just the browser.

MM: Other secrets exist, that can't be protected by constant time
algorithms. For example, say some code is handed a graph containing
secrets, where that code must traverse the graph to process the secrets.
Clearly the pattern of memory accesses or their timing is not going to be
independent of the topology of the graph. This claim that one can
practically write side-channel-free constant time algorithms applies only
to very specialized algorithms such as crypto.

LH: moving along

LH: slide (Mitigations for side-channel)

YK: existing API/flows exist to prevent driveby

DH/YK: let me unpack it, when navigating to a web app with an install
banner, the JS code can trigger the install banner, but only if the browser
believes it is not a drive by

LH: slide (complexity)

LH: slide (compiler can't introduce races)

LH: slide (Shared Memory)

LH: slide (User affected "only" by races)

WH: these are easy to deal with, the quantum garbage is not

LH: yes, i believe my next slides will cover

LH: slide (Where do we stand?)

LH: do we want this?

MM: let me verify, can we negotiate re: deny shared memory buffer to the
main thread?

LH: we can talk about it

LH: slide (Where do we stand? 2)

YK: can you do this with PNacL or flash?

Yes it is possible, but it is most likely quite slow

YK: stronger point, not only is it going to happen but it has already
happened.

WH: Quantum garbage issue is new

LH: We need more direct input, need help fixing it, or finding bugs. Stage
2 has the notion of reviewrs.

For the review, memory model stuff is very hard. This one may be worth
getting outside help

JFB: we have contacted several and have been getting feedback from industry
standards.

DD: this TC can help best with integration with the language, deferring the
memory model issues to the experts seems appropriate.

LH: for example WH doesn't want quantom garbage, this is good feedback. The
current 2 month cycle isn't a tight enough loop.

WH: in the last few months, I haven't seen much improvement. Especially
with the quantom garbage

LH: Until now, it was unclear we wanted to fix that issue.

WH: I haven't seen enough progresss

JFB: do you feel this would result in churn, or getting the entire proposal
nixed.

WH:  I don't want values that spontaneously change, as that will leak and
break all existing invariants. This is a deal-breaker until we have a
believable proposal on how to prevent quantum garbage.

MM: if their was a boundary between code directly interacting with the
shared buffers,  and the rest. It could prevent it the quantum garbage from
leaking. If on that boundary crossing, we ensure an atomic operation. All
values post the operation would be safe

no

LH: if two works are running with shared memory, if X reads a value and Y
writes that value. X reads into local var. It is possible to.

```
x = mem[a];
...
if (x)
  print(x);
could print 0.
```

MM: **ooupfh***

DH: this isn't a security concern, rather an correctness concern

MM: it is possible to fix it at the atomic operation level?

WH: No. This problem is independent of any atomic operations.

LH: no

* lots of talking *

?: What do other languages do?

WH: C++ makes it undefined — lots of weird things can happen.

DH: the reaosn i mentioned Java, is because they have worked very hard, and
it is still full of data races. They tried to avoid synthesing pointers to
objects out of thin air, that is a seperate. Did they try harder? Did they
try to solve this problem?

WH: Yes, they tried ;-). The first time they got it badly wrong. The second
time, after a few years' work, they got it slightly wrong.

DH: given that they got it wrong several times, are they relatively
confident in the current result?

JFB: Those researchers are worker with us.

MM: Java i think is a dismal failure in this regard.

DH: this is not the Java model, this isn't multi threaded objects out the
wazoo.

MM: I agree it isn't the full java problem, I agree we should look to java
for lessons. We should be cautious of thinking java is a positive example

MM: We should learn these lessons.

YK: I believe what is described is a deal breaker.

DE: in typed arrays they were initially spec'd outside of the TC, and now
the TC and the vendors disagree. Recommendations landing sooner is healthy.


JFB: C++ hasn't tried to speciy what happens in the race, it merely says
its undefined. I don't know if Java tries to specify it

WH: They tried it, but it was unimplementable, so no implementation was
actually doing what the spec stated.

JFB: I think they worked to ensure the GC did the right thing

DH: that specific issue seems irrelevant, as we are only dealing with
primitive values in an array buffer.

JFB: We should likely define how far the poisoning spreads.

DH: MM you argued that multiple nans (which is similar to this) was fine

MM: I merely argued that it was not fatal, due to nearly all the language
features not being able to observe the issue. In general in JavaScript, if
you read a value, and re-read it you can count on it being the same. This
is true of all values including NaN for old code that does not include the
new binary arrays.

MM: When you (Dave) figured out how to avoid the non-determinism without
introducing the other problems my proposal was trying to avoid, I quickly
accepted it as superior.

LH: no actually their is a distinction, compilers today can optimize this
to be single lookup

LH: shared memory invalidates that, even in trivial ways

MM: can this be isolated?

YK: you can imagine a number leaks

JFB: we should define that if it leaves the shared buffer, the value no
longer change

MM: could the compiler mark those object, preventing them from polluting.

LH: it could


MM: it seems like we want something the same as volatile

LH: I believe the compiler could detect these cases and prevent the issues.

JFB: yes, the memory model needs to be defined.

BE: does this help approaching stage 2?

LH: I believe we can address the quantum garbage issue as mentioned above,
we should take a pool and see if their are other blockers.

WH: timing attack is still an issue

YK: it seems like its going to happen (has happened)

WH: The difference is that, when we get a timing attack security scare in
the future, if the timing is done via something like web assembly, the
advice to the general public will be to just turn web assembly off. If it's
a timing attack enabled via ECMAScript, it will not be practical to tell
folks to turn JavaScript off because it's relied on so widely.

MM: I was prepared say no, we shouldn't move to stage two. I have
reluctantly good news for you. I believe that really, shared memory should
be kept out of the world of the browser. I don't think TC39 has that power,
as BE mentioned. Agreeing to this, I feel like I have blood on my hands,
issues will likely happen. Just  like __proto__ it was better to define
then to let it be implemented in an ad-hoc way. Given the large amount of
high value pthread code in the world,  competitive pressures will force all
browsers will to do this whether it is safe or not. We should work to
ensure it is as good as possible

M:  we should be sure we work with webasm, and be sure this is something
that works well for then.

*agreement*

MM: it was the potential ability, to stop the potential propagation of
quantum garbage. If we can solve it, I am reluctantly OK.

WH: i would like to also see the quantum garbage issue sorted out before it
moves from stage 2

MM: for me, the quantum garbage problem would be fatal, do I need to block
on stage 2?

DD: you can stop the train at stage 4 still.

DD: not every stage 2 feature makes it in the spec.

YK: it is ok to say, I am willing to advance it but not beyond 3 or 4,
until this issue has been addressed.

LH: Yes it has to be solved, it is rediculous for JS to have this. Even if
it means we take a performance hit.

DH: Helps us hans booms, yous're our only hope.

... some process discussion...

LH: slide ("where do we stand? 3)

LH: market place pressure, showing our seriousness is healthy. We are now
at the point, were additional reviewers are important, which stage 2 is for.

MM: let me rephrase, what we believe we are advancing is a proposal that
includes removing the quantom garbage propagation

*argeement*

BT: It is important to advance proposals.

BE: it will go into it wasm regardless we may aswell own it.

WH: I go on the record as objecting to advancing to stage 2 on the basis of
failure to satisfy the stage 2 prerequisites. The prerequisite "spec
quality: all major semantics, syntax and API are covered" is not met at the
moment with the race memory model and quantum garbage issues being both
major and unaddressed in the current draft. However, I will not block the
process.

#### Conclusion/Resolution

 - advance to stage 2



## Weak References

(Brendan Eich)

BE: quantum death drink, half of something and half of something that is
incompatible

BE: I'm here to discuss weakreferences, some want this but no-one is
championing it.

MM: i do not have the time to champion it, but I will help a champion

YK: i think the main hazard alan pointed out, was that many people expect
it to solve more then it should

BE: weak references wont be prompt

YK: you will still need to right cleanup code

BE: we will decouple them from GC in general, we want to avoid people
assuming they can use this for fine tuned GC

MM: it may never be GC'd

BE: do we think it is important

yes

WH: No, and I mean this as a literal answer to Brendan's question: I don't
think it's important, not that I want to actively prevent it.

BE: why, WH

WE: We already have WeakMaps (and yes, I know they are different!)

MM: WeakMaps and weak refs are totaly different. While "WeakMaps" is a
better name than "Ephemeron Table", it has caused endless confusion.

YK: the fact that you can't self host addEventListener is the issue.

MM: WM and WR are totally different

WH: The main reason is that I don't want to make GC visible, which WeakRefs
would do. I know you (MM) don't like it visible either. However, I have no
antipathy to doing WeakRefs if the committee wants to.

A: one data point, v8 has finalization in its C++, people report false
issues all the time wondering why some things are not destroyed

YK: removing all destructor logic will cause people grief, this will not
replace that.

BE: the C++ layer has these things, JS is used more often to implement
these features. I think this is far game, I think WH is ok with it as long
as it doesn't telegraph the GC.

BE: I think we can do this

DT: I am interested, but what does that mean

MM: having worked with DT before, I am overjoyed.

DT: not currently on TC-39

MM: the individual who does the work, doesn't need to be on the TC, though
it does help. I am happy to be the on-TC-advocate of the proposal if
necessary.

LH: have you looked at guardians (paper:
http://www.cs.indiana.edu/~dyb/pubs/guardians-pldi93.pdf )

MM: I am very much interested in looking at it, and preferring the small
talk approach. In small talk 80, they added post mortem finalization.

DT: I preferred the small talk approach

... some talk describing the above paper ...

BE: I would love a champion, but this will require cooperation with GC
implementers.

BE: the only practical issue is deans partnership/activity in the meeting.


## 5.viii Async Generators

DD: i believe JHD should present

## 5.xiv Object.values Object.entries

(Jordan Harband)

https://github.com/tc39/proposal-object-values-entries

JHD: implemented in chakra, flagged in v8, my patch into JSC is not yet
patched.

JHD: as part of core-js and es7-shim.

DE: i have no issues with the proposal, v8 implementation is flagged. We
don't pass test 262 yet. I would like to wait until we implement this in
atleast 2 browsers. So I would like to suggest we wait for the next meeting.

JHD: Browsers providing feedback, re: breakage or performance, should block
it yes. I don't see that happening here thought

BT: this meeting is the last meeting for ES2016, if it doesn't make it
here, it gets deferred to the next.

JHD: more then one feature on ES2016 would be good for PR.

SP: last time we discussed what is 2 implementations, did we decide what
that meant

DD: no.

BT: how did the browser do on test 262

JHD: chakra passed, JSCS when it lands will be.

BT: i have zero doubt that this is implementable, but the question is from
a web compat standpoint?

JHD: the class of problem is typically for prototype extensions not on
Object.

SP: subclasses of Objects may be affected

JHD: it doesn't seem like their are many issues.

YK: should we just wait?

DD: yes

JHD: i'll bring it up next meeting again, hopefully it is shipping in one
or two browsers and the web compat concern has been resolved.

BT: do you know what the chrome timeline is, will we have afew weeks of
canary?

DE: ya, afew weeks.

AR: we should  land it in M50

YK: People maybe confused with async/await, entries/values introduces
potential web compatibility issues, which we haven't vetted yet. Async
await, had technical implementation details.

#### Conclusion/Resolution

 - Stay stage 3, wait for 2 shipping browsers to confirm web compat.


## `String#padStart`/`padEnd` (JHD)

#### Conclusion/Resolution

  - stay stage 3, no further concerns about unicode/graphemes/RTL, Intl
will handle that.
  - will pursue stage 4 when enough browsers have shipped it to allay web
compat concerns

## Unicode fix: https://github.com/tc39/ecma262/pull/300 (DE)

Discussion about support for old operating systems

WH: In practice the unicode version doesn't affect ES programs much. New
unicode versions mainly add new characters, and those just flow through ES
programs regardless of the unicode version. The places where unicode
version matters are relatively obscure such as case conversions for non-BMP
characters or whether you can use brand new characters in identifiers. The
situation will change when we add character classes to RegExps, so we
should update the required minimum unicode version of the spec then.

DE: should we stay at unicode 5.1?

DD: now, it seems like we should move to 8

WH: I am worried this will cause too much noise in the test262 tests. I
think it is legitmate for implementations to lag if they rely on the OS's
support for unicode and don't want to penalize them with test262 failures
for being lightweight.

DD: I think its no less legitimate to implement all of ES2016

DE: i don't understand your concern WH, it seems like you want to save the
implementers some time, but the implementers seem on board.

WH: [repeats above]

DE: I don't believe this would be alot of noise

BT: they way i see us implementing these tests, is to have a single file
for this test, having a single test fail is fine, and implementors already
have machinery to manage test failures.

MF: are we doing 8 or 8 or greater?

BT/DE: 8 or greater

#### Conclusion/Resolution

- switch to 8 or greater and merge  https://github.com/tc39/ecma262/pull/300


## Object.getOwnPropertyDescriptors proposal email (JHD)

JHD: this method instead of producing a single descriptor, this would
return multiple. Ultimately being what would be passed to Object.create's
second arguments

JHD: can we advance it to stage 2, and we will firm it all up

MM: i am happy with stage 2

#### Conclusion/Resolution

- advance to stage 2

## Object.getOwnPropertyDescriptors object: null or Object.prototype as
[[Prototype]]?

DD: what is the prototype of the object it returns, null or object?

YK: does anything in the spec return null prototype?

SP: Does Object.create second arg us ownProperties

JHD: yes

MM: getOwnPropertyDescritpor returns an object with prototype of object.

DD: I am fine with the prototype being object.prototype

#### Conclusion/Resolution

 - prototype stays as object, DD + SP will be reviewers.


## 5.xi Daniel, presenting SIMD changes since December

link:
https://docs.google.com/presentation/d/1tREM-eLjadnXZogdKXlTWY8XzicXgylI_GlIxxsMNzc/edit

DE: (walks through slides)

DD: how do you feel about the test coverage

DE: test coverage feels pretty good, the tests for the value semantics will
need some more work, but largely the test suite is good.

DE: we will need to do some work on the test harness, test262 would like to
generate the tests precedurally

DE: test harness may want sameValue sameValue0

DE: do we want SIMD to be optional

M: I would prefer for it to be optional, i don't see value

BT: small IoT devices

BE: the devices in question, have the required hardware

BE: SIMD is analogous to C++ intrinsics available to mobile apps that web
apps compete with and mix with via webviews,

M: exactly

BE: which type of device, we want to avoid the kiddie car model

YK: As a practioner, I would like to have it everywhere. But if these
devices don't implement it anyways then...

BE: what is the pressing small device use-case, the compact profile is test

DD: we could create a IoT core

BE: We don't want to go back to the compact profile of 15 - 20 years ago.

BT: samsung spoke about such devices

M: a watch

DD: Whats wrong with a fruit-like watch not supporting the full spec?

BT: it is hard to not get SIMD

BE: if there is a device that really cant run this, I question if it will
have other features. Those devices tend to be hard targets.

DH: This is the same issue, we want to maybe only provide specific
instructions, feature detection may be needed anyways.

DH: If it turns out a significant amount of the market can't implement we
can reinvestigate.

JFB: just to be clear on SIMD. it is the bare minimum, and happens to be on
most devices, and devectorizing is also not hard. It becomes really hard on
much wider SIMD, that will be much more effort.

DE: it seems like we have a settled position

DD: thanks for your update

SP: can we figure out a better strategy of dealing with these problems? We
continue to cover the points, and no much process is being made.

DE: we should look for such devices

BE: why would we look for devices to cripple the spec

MM: has someone reached out to the samsung folks

DH: I believe they implemented something that may support it all:
https://github.com/Samsung/jerryscript


#### Conclusion
 - successfully delivered the update to the committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160205/03db6351/attachment-0001.html>

January 27th 2016 Meeting Notes

Eric Farriauolo (EF), Caridy Patino (CP), Michael Ficarra (MF), Peter
Jensen (PJ), Domenic Denicola (DD), Jordan Harband (JHD), Chip Morningstar
(CM), Brian Terlson (BT), John Neumann (JN), Dave Herman (DH), Yehuda Katz
(YK), Jeff Morrison (JM), Lee Byron (LB), Daniel Ehrenberg (DE), Lars
Hansen (LH), Nagy Hostafa (NH), Michael Saboff (MS), John Buchanan (JB),
Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar Horwat (WH), MarkS.
Miller (MM), Paul Leathers (PL), Sebastian Markbage (SM), Zibi Braniecki
(ZB), Andreas Rossberg (ARB), Ian Halliday (IH), Keith Miller (KM), Tim
Disney (TD), Misko Hevery (MH), Brad Green (BG), Kevin Smith (KS), Brad
Nelson (BN), JF Bastien (JFB), Shu-yu Guo (SYG), Rick Waldron (RW), Staś
Małolepszy (STM), Dean Tribble (DT)


## Agenda

https://github.com/tc39/agendas/blob/master/2016/01.md


## FastTrack

AWB: slide (Ecma to ISO)
AWB: ecma fast tracks it to become an ISO standard
AWB: slide (ECMAScript 2015 and beyond)
AWB: slide (the plan)

BT: Got a bunch of excellent editorial comments from JP22.

WH: The Japanese ISO delegation has been by far the most prolific in
finding technical problems during our past ISO fast track reviews, but they
were by no means the only ISO member to make productive comments.

BT: It's not clear if the other delegations are commenting or not. They
feed comments via GitHub but we don't necessarily know if the GitHub input
we're getting is coming from folks associated with ISO delegations. JP22 is
conscientious in tagging their contributions, but I don't know if the other
ones do.

BT: some of the issues have been editorial some are bugs or implementing
concensus. Lots of pull requests for bug fixes.

WH: What are the natures of GitHub submissions from random entities to ES?
For bug reports I'm not worried, but for more significant contributions
there may be IPR issues.

BT: it is a heuristic, significant contributions is what matters. Some bug
fixes could be considered contribution, if the contribution is
significant they have to be a registered contributor.

AWB: it mostly comes into play for pull reuqests, but it is up to the editor

BT: not in theory, this is in practice, Largely contributions come from
people in this room, but some substantial outside contributions have
occured.

AWB: that is the general plan, addressing the ISO issue. So one final
update that merely points to our documents.

AWB: slide (but still need something to fast-track as update to ISO/IEC
16262:2011)

AWB: slide, describing the content of the ecmascript suite.

BT: a downside I see, right now the fast-track process allows ISO members
to provide feedback. If they do not see a document, would they provide
feedback? I suspect this will result in less feedback from ISO. I don't
believe that is fatal, but..

AWB: i believe that is true, but what alternative ?

DH: could we submit less frequently?

SP: seems very strange to get feedback on old versions, and not on the
latest or new version

YK: does everyone agree that the standard  is "official" is year old, would
we want sony to feel required to implement an obsolete spec?

* general consensus *

AWB: slide (ECMA to ISO)

AWB: should we provide a technical report for JTC1, that describes our
process

WH: whats going to be in this document

AWB: the current draft is on the tc39 member area of the ecma site.
(displays content on screen)

WH: is their more to this

AWB: no this is it

AWB: ISO people sent an email, that suggested we require a clause for a
normative reference.

AWB: it is just a set of pointers

WH: This is just a bibliography without any paragraph that defines
conformance. Once this gets an ISO standard number XYZ, what does it mean
to conform to ISO standard XYZ? One can point to anything in a bibliography.

BT: do you mean, it should say must implement the entire spec

WH: Yes, the ISO pointer standard should have a short paragraph stating
that conforming to the ISO standard is defined as conforming to the current
ECMA standard that's referenced.

BT: we should say: If you conform to ecmascript262, then you conform to the
ISO spec

YK: are they ok with this?

AWB: it is actually their idea

BT: likely concerns exist, but something we can work out

YK: presumably those are one-shot things.

SP: everyone seems "in spirit"  to be on-board, we just need to deal with
some of the details.

BT: for this body we don't have to care, because we just do our thing. No
more IOS fast tracking.

John: how does this impact 2016 release

AWB: it is entirely decoupled, normative rules dictate if no specific
version is specified, it implies the current version

#### Conclusion/Resolution

- next meeting we will vote for this.
- if concerns exist, please let us know before the next meeting

## ECMA-262/402 2016 End-Game

AWB: slide (Key dates)

BT: the way I want to do this, at the march meeting I want us to approve
what is in master, or a snapshot. I don't want to make minor tech or
editorial changes. I will make fixes if major issues exist, but otherwise I
wish we can leave it as is. Leaving it as a tag

WH: What changes are you planning on making to the spec document between
now and the April 1 deadline?

BT: Just small editorial changes and bug fixes.

WH: Which, if any, of the stage 3 or 4 proposals are you planning on adding
into the document between now and then?

BT: None. As far as proposal-level features are concerned, the 2016
standard candidate spec will be what's in it today. Enjoy
Array.prototype.includes (and the exponentiation operator).

AWB: have you discussed what will be in?

BT: changelogs have all the normative changes, I can go over those

AWB: we don't need to know, we should likely record exactly what are the
new features.

BT: (lists features)

AWB: everything that applies here, applies to ecma 402 also. ecma 402 has
to go through the process on the same dates, hopefully those editors are on
top of that.

AWB: slide (draft stability)

BT: istvan wants a PDF, but will accept an HTML. Some may want a PDF, but
it is merely a ctrl-p of the HTML. Those that want to use it, should be
aware editorial changes may be more or less useless.

BT: I will give ecma a zip of a snapshot of the github repo.

YK: the PDF seems fine

BT: how are links

YK: people should use HTML

BT: the original PDF had links

YK: people should use HTML

WH: HTML has formatting issues.

WH: PDF needs links. It's much less useful without links.

* general agreement *

AWB: some people may want to print this thing

BT: i believe those days are done

AWB: we should provide both

BT: companies could be hired to accomplish this

SP: is this a transition period, or will be do this forever

AWB: ecma would like to have the PDF

BT: ecma wants PDF, because of ISO requiring it, now that we no longer send
the full spec to ISO, this may be fine.

AWB: ecma wants a zip file, that can run on a local machine and it has the
full high fedility document.

BT: yup, they can host it.

AWB: they will want to insert some analytics

BT: I'll work with them to add that.

AWB: in the past, I have just copied their boiler plate

BT: do i take the snapshot on feb 26, lets pick a date.

AWB: Feb 29

BT: ok, thats a monday

BT: how about march 1

AWB: thats fine

BT: so if you have anything you want in the document, get it to me well
before march 1

WH: How many files are in the HTML spec?

BT: 6. The HTML, CSS, diagrams, Javascript

WH: Why does the archival standard spec execute Javascript? Isn't that
brittle?

BT: it isn't required, it merely improves the experience

#### Conclusion/Resolution

- 30 days before the next meeting, the final draft will be provided
- next meeting we will vote to make it ES2016
- start the out-patent review process, you may need to alert your
organizations

##  Ecma archiving and web hosting issues: Github, wiki.ecmascript.org,
etc.

(Allen Wirfs-Brock)

AWB: slide (Ecma Archival Issues)

AWB: slide (github)

SP: We can likely include a snapshot of issues/pull/comments requests as
part of the release

YK: ecma position seems correct

SP: AWB are you going to do this

AWB: yes

AWB: slide (ES6 archives)

AWB: We need a strategy, small to medium (1 -> 2 weeks) could likely be
covered by ecma.

AWB: tc39 reflector -> github private repo

#### Conclusion/resolution

- BT will set up reflector
- AWB will work on archival.
- AWB wil own the wiki archival process


## TC39 Invited Experts Fund - Proposal

AWB: Istvan Sebestyen floated this, this is actually Istvan's deck

AWB: root problem is as folllows, how to pay for AWB to come to the
meeting.... I am an instance of the problem. We have in the past invited
experts, we cannot assume it is reasonable for them to cover this. Is their
a way for a group like TC39, which is made up of orgs. Is there a means for
it to provide some level of support to unaffiliated individuals who would
be important contributors and such.

YK: how does one decide who is important and who is not

AWB: yes, lots of practical points to discuss

AWB: slide (ecma: type of participants in an Ecma TC)

*concern about hard limit on guests*

MM: is there a hard limit?

DT: a hard limit of 2 observers

YK: the found would require a group, I am concerned that this group would
be peers on TC39. As a person who would benefit from this, I would be
concerned that I would have to use scarce political resources.

DH: this could create uncomfortable situation.

YK: the flip side, such indivudals seeking funds on their own would not
have this problem.

AR: TC39 or ecma may be the wrong organization, an org may exist an
external group that should cover this. An example would be the jQuery
foundation (or similar)

AWB: slide (Proposal)

YK: I find this unsettling

BT: MS GA rep didn't like this

WH: Google GA rep didn't like this

AWB: Adobe's GA rep did

BT: been speaking with more people at MS

AWB: other orgs are also speaking about this, such as the W3c.

AR: I am doubt it will happen in the w3c, but i feel the best solution is
something similar to the jQuery foundation sponsoring this.

YK: this poltically frought process

MM: yes, we should be careful to not erode the healthy work environment

TD: A minor variant that may work, ECMA may administer the found but allow
individuals to self-found.

AWB: this sounds like a legitimate expense

... tax talk ...

#### Conclusion / Resolution

----




### Decorators
presenter: Yehuda Katz
link to slides:

YK: the champion group has grown, in good ways.

YK: Still at stage 1, it will likely become more clear as i progress. I
hope to progress it to stage 2 in munich.

YK: babel/ts want to explore some ideas before we move on.

YK: slide (quick recap)

YK: slide (on classes)

AWB: if decorators move forward, any future new class items would need to
describe how to work with decorators.

YK: we should discuss, but yes we should consider this,

YK: slide (On Object literals)

YK: slide (originally out of scope)

YK: slide (prototyped in babel and TypeScript)

YK: slide (Users by angular 2 and Aurelia)

YK: class decorators are mandetory partof those frameworks

YK: slide (displays examples of angular 2 and aurelia)

YK: someone uses all the features in the proposal have some real usages,
which help with features

YK: ember has also experiments, using decorators in concise object literals
via an addon.

YK: react also uses this, aka @injectProps: (shows screenshot of an
example) a large part of the react ecosystem seem to be excited about

YK: another example is core-decorators by jay phelps, an example of generic
decorators everyone can use

MM: so what you are saying, is decorators are relieving pressure from the
language to add more specific features, as they can be implemented nicely
in user-land with decorators

YK: TL;DR decorators are popular

YK: slide (motivating use cases)

JM: can you state the difference of class vs constructor decorator

YK: the constructor is not a member, and my proposals do no cover it. As
putting a decorator on the constructor is isomorphic to putting it on the
class

YK: the main use-case for constructor replacement, is to deal with the fact
that the spec says 3 sings exist. unfortunately specing this is complicated
and will require additional machinery

YK: slide (changes going forward)

YK: given that there is usage now,  let me describe what is important. I
want to maintain rough syntactic compatilbity. Angular for example, should
be able to provide compatible decorators, without consumers having to
change.

YK: we should decide on @ vs #, this would likely be the only user-facing
change. As it would be a simple transform.

YK:  slide (maintain existing capabilities for library authors)

MM: should we say rough

YK: yes, i removed 1 capablity, but it appeared to not be used.

YK: slide (continuing requirements)

*discussion about when decorator expressions are evaluated*

WH: I noticed when reading your proposal that you allow decorators on
methods defined inside object literals but not on plain properties inside
object literals. Is that intentional?

YK: Not intentional. The proposal on github is old.

WH: In that case you'll get a syntax clash when you try to extend the
object literal grammar to allow decorators on plain properties in addition
to methods, regardless of whether you use @ or # to introduce decorators.
The conflict will be between the tail of the decorator LHS expression and
the property syntax that follows it.

... some discussion about jits ...

AR: We should collect evidence

YK: Some confusion, the world static confused the situation, stable would
have been more work.

AR: I'm ready to believe that, but their are other things that could detect
statically, that decorators impose

DH: an exampe would be, replacin an IF with a decorator, would reduce the
ability to quickly analyse

YK: i accept that

AWB: is it any different then a normal predicate

DH: Abstractions cost

YK: I agree, I should not speculate

SP: In Ruby, metaprogramming can happen anywhere, at any time, and
decorators are more stable

YK: you can express most metaprogramming in a visible way.

YK: slide (Continuing Requirements)

YK: We want decorators to be able to decorate everything that exists within
a class, including a decorator which is generic across multiple of them

.. YK talks about how symmetry is hard, generic decorators working well has
been a hard problem ...

MM: provide the decorator enough information to make these choices

MM: I don't recall  the concrete API, is the decorator called with
sufficient information to infer ??? ?

YK: This is the intent; we have to implement it

AWB: what is the hint then?

YK: it is a short-hand methed, vs property contains a function. We have
removed this from the current indication, but we have removed it.

YK: a short-hand method is the same as object literal version

AWB: super

YK: i did not realize

YK: slide (Most common reported issues)

YK: one could have a reflect.defineField that  doesn't work outside of
class intanstiation time.

....lots of hard to track/write up conversation, we need a stenographer....

YK continues to present read slide (Most Common reported issues)

YK: extend and decorators need to collaborate, if you could know your
superclass was being subclassed a collaborating decorator would not be
required.

YK: slide (Changes Max-Min)

YK: havin to feature test the object to figure this out, is unfortunate.

YK: When adding an additional descriptor, you may need access to other
properties. For example, _fullName may want fullName accessor. But with
private this would not work, so I proposed an abstraction that allowed
reflection of the private slot. Decorating a private slot, should give
access to the private slot

MM: I don't know if I agree, but we have a session later this.

YK ...diagrams something..

AWB: wouldn't it be better to have a decorator, that decorates  this
specifically installing the appropriate slots

MM: the exploration in private state that unified the weakMap view on how
to name the private state and the slot view, was to avoid reifing the name
of the private slot. To postpone the issue

YK: i dont' think that is realted

MM: the get/set functions that we are passing to the private slot..

Yk: they don't know the name

MM: the get/set functions are in a sense the reification of the name as a
WeakMap

YK: ...


YK: it takes a ths

YK: that is a tracking feature of what we postponed

YK: maybe that was urgent, but I decided it is way to speculative, we can
retrofit it later.

YK: i bought it up last meeting with more examples, I think it is unlikely
we wont need, as it will cause grief. But we can postpone.

YK: private slots and fields will feel very similar, things that make them
not compat will be a problem

MM: i understand

YK: thats all  stuff i removed, I worked with ron and angular folks on a
mirror based API. Which is the result of last meetings discussion. As it
turns out, it is a hard to design API. I would like to propose a seperate
mirror proposal, maybe at the next meeting I attend. Rather then passing in
a target/name you get a mirror, with APIs that allow your to perform the
required operations. The idea is to encapsolate the whole problem in a
specific API.

YK: I think their are many cases were the thunks are not require, some
still do. Static fields do, property fields dont.

JM: that would be a change in properties, back to what they were before

YK: Static fields are more like fields then they are like properties.
People really wanted to model them the same as properties.

E: Why doesn't it work

YK: Abunch of issues, TL;DR you want to be able to say, class C, saying
static singleton is class C.

DE: is their any case other then the self reference case?

YK: classes have this problem

E: this is a TDZ

YK: people don't want it to be TDZ

JM: I think mkaing static fields fields instead of properties, feels ok. I
haven't found any issues.

E: isnt it already a problem?

DE: which TDZ don't you want to add

E: no fields, but the self referential inner binding gets wierd up at the
end, instead of the beginning.

YK: you are correct, in one interpretation their can be a TDZ, but I would
like to avoid that

YK: the timing is complicated

AWB: this is a general problem with these initializers, i think the last
time we talked about it we assumed their were issues.

YK: instance initializers don't have this exact problem

E: these things will be wired up before they run

YK: there may be issues, the TL;DR static fields are fields not property

AWB: all a static field is a definition of a property on a constructor

YK: the definitiation is an instruction to install but not right now

AWB: static field name may be a property name, we will need to define the
order

JM: prior we were going to evaluate them as we install them

JM: now we treat them as a description for installation

AWB: i don't think thats right

YK: i feel we will want class decorators to modify the constructor, if we
do that the static properties will have been installed on the original
constructor. But the static fields will be install on the wrong constructor

AWB: We have to define the ordering

AWB: a field is something that is part of a class definition, but when the
instance is created the field is installed.

JM: At class definition time we will need to define the ordering

YK: this is basically the discussion that caused me to think it is not
important for use to.... The timing for initializers and instantiation is
all very observable. We need to be careful, as to not tie our hands to
much. At the point we discover a field that may not be time it is installed

YK: many different factors, suggest specifiying static field imparatively

AWB: i believe static fields, and object literals should share the same rule

YK: i believe

AWB: it would be disturbing, if I had an object literal with two decorated
properties, and a class with two static properties, and observed a
different initialization order.

DH: most class systems have several phases,  reality is subtle

YK: decorators interleaving with the initializer expressions.

YK: all decorators run before initializers

DH: instance initialzer expression happen at instantiation time, the whole
idea of top to bottom left to right doesn't work

AWB: it doesn't work for instance stuff

DH: there is only one syntactic block

DH: there has ot be some amount of interleaving of stages

MM: something factually wrong about what you said, top -> bototm, left ->
right, can be made without conflict if the instance fields and properties
are set in the constructor

YK: one world view, static side is an instantion of a singleton side. You
execute it as a single class, Another world view, is to embed the object
literal. Both are valid and we need to decide which one

WH: the problem is, in C++ it is possible to have a static property whose
initialized value is an instance of the same class. This is useful but has
unexpected consequences in C++. Because they let you do that, now constexpr
static value initializers cannot call static constexpr functions defined
earlier in the class!

YK: What i said is true

AWB: if we don't the scoping rules get complicated

YK: it is orhogonal

YK: if it is a singleton class, that is instantiated immidately,  we would
run the decorators top -> bottom, followed by the initializers. Because
they are seperate.

AWB: umm

YK: this should be obvious, static fields either as something as embedding
an object literal in a class, or an immediate invoked class

AWB: what does it mean to embed an object literal

YK: two semantics, object assign...

AWB: we know semantically, that static fields/properties become own
properties of the constructor properties

YK: both world views are consistent here

AWB: we are defining properties, so the two questions are when is the own
property created on the constructor object. And when is the value computed
that is the value of the property.

YK: the way classes work, there is a seperation of declaration of the class
and instances

MM: we aren't talking about the instances

YK: it is impossible to explain these seperately

MM: what happesn at class eval time

YK: their is a, i think many people here assume that you should not run the
decorators and then the expression that is wrong. It is not my sense, and
I'm trying to describe why.

YK: the only way it is observable without  decorators is self reference.

AWB: this goes back to static fields

YK: I tried that, and WH said we should disallow self reference

WH: no i said, we need to clear up the ambiguity

JM provides some diagraming.

```js
class Foo {

      static someFieldA = A; <--- 1. record this; <-- 4. intiatiate

      bar() { <-- 2. assign this
    }
} <-- 3. end

Foo;
```

MM: when does Foo get bound

YK: at the end

AWB: i don't believe the spec..

MM: from within the class, if you execute a reading of the variable Foo
before you get to the end of the }, you are in a TDZ

MM: the things that are creating observable side-affects are the execution
of A, but the instalation of bar is not observable

YK: this is today, but decorators/blocks/computed property names etc, make
this observable

AWB: computed properties are the way to bump into the TDZ today.

YK: the partially initialized class is not observed

MM: if you are executing the get of the name Foo, you get a TDZ violation

YK: i would like to avoid this

MM: im trying for a factual understanding

YK: you are correct

WH: what scope are the initializers run in

YK: current lexical

MM: they would refer to lexical names, names of properties are not lexical

AWB: elThis is really a discussion...

YK: I believe we will need to make static fields, which is why i was
initially over thunking.

YK: with mirrors you don't get the actual objects

AWB: is there a concrete API

BT: there is a must discuss topic about walking down the prototype chain

YK: i have no more slides

YK: We want to avoid viewing partially iniitialized state

....

MM: we should revisit this.

YK: i just reasoned from the use-cases

YK: slide (Property decorator, v.last)

AWB: mirrors on objects, and mirrors on function definitions are quite
different

MM: function definitions are not reified objects

YK: for v0 it hasn't come up

AWB: it may be relevant to constructors, you may want to see a method
definition.

WH: I have the same point, if the mirror mirrors a function it can call
rather than a function creation descriptor, what is the point of the
mirror, why not just use the function?

YK: the open question, is a mirror the snapeshop, or a singleton object
that mirrors the entity.

WH: even a snapshot is dangerous, as it could give access to mutable state.

YK: why?

WH: Shallow snapshot or deep? A shallow snapshot can point to newly created
internal mutable state that the class wasn't expecting to have gotten loose
yet.

SP: i believe a shallow snapshot is being described

MM: a deep snapshot is off the table

DE: *trying to interrupt to switch to a different agenda item* can we move
this to a break out?

BT: this is relevant, but lets avoid rambling

YK: a snapshot may be wrong, if someone wants a stable reference. Which
enables talking about that entity.

AWB: something is bothering me, in ECMAscript, other then modules. Have two
sorts of constructs, which have complex evaluation semantics, that result
in the creation of one or more objects.

1. object literals (sorta complex)
2. class definitions (very complex)

It seems like fundamentally as we talk about decorators, we want to
formalize those.

MM: I feel like I have learned something

AWB: i the piece I am missing, although you may have it in your head, but I
would really like to 1 and 2 formalized.

YK: everything you said rings true to me, my current.. To go through the
runtime semantics, I should submit this. It is reasonably clear where
things go.

WH: i dont think so

YK: im not saying anyone can do this, but AWB analysis is correct

AWB: one could imagine a hook point, a processing pipeline that every class
definition goes though. This could enable the extends clause aswell. This
elevates the control

MM: it is a new way to think about it for me, I really like it. I have
always thought about decorators as merely desugaring. But really, it is
hooking the complex initialization process.

YK: yes, the motivation is to enable flexibility in the current declarative
blob. I agree with the analysis. I believe it is correct to address this.
We should discuss the snapshotting in a breakout. I believe having one
mirror that lives the entire life.

MM: decorators thought of as multi stage programming model

YK: i think my last topic was quite long

MM: it is possible that the presentation was only understandable with this
new world view.

MM: the hooking of instantiation if very distinct from multi-stage
programming.

YK: yes, we should talk about this in a break out.

YK: ok, my question. I don't know how people feel about non-snapshots.

MM: Deep snapshots won't work, shallow are making a promise they can't
deliver.

MM:  the classic reflection APIs I am aware of are live.

MM: decorating reified things, vs multi-stage programming. Determining what
the program is vs determining the value

YK: I agree, that seems fine. Im not sure what my next steps are

WH: it would be more productive if this was less vague, nothing we can
carry on productively until that.

YK: that doesn't match what I need.

MM: as TC39 this isn't quite productive

WH: By more concrete, I mean a less vague proposal that we can discuss, not
start implement something right away. We're not at the stage where we
should be implementing yet.

DE: can you take an idea on those proposals and write it up

MM: any one of these perspectives needs to be fleshed out.

MM: fleshing out your persective is wonderful, fleshing out mutiple is also
wonderful

YK: it was roughly fleshed out...

DE: I have not seen a sufficiently detailed proposal. Can you share a link

YK: i can send links, but their may be not something sufficiently speced out

MM: What is bothing me, is that as a designer you seem to be straddling
multiple perspectives.

WH: the problem is, togglilng perspectives makes discussions compleciated

YK: tell me how

WH: For example, it all depends on the ordering of initialization — the
different world views conflict on this.

E: isn't that the crux of the design of the whole thing the point of this

E: he is trying to figure out

YK: i am asking how to make this more conrete

MM: their are 3 distinct perspectives

1. classic OO Design Patterns book: decoration replaces value with similar
value, typically wrapper of original
2. the hooking of the instantiation process
3. mutli-stage perspective

These are very distinct, I would prefer to see one perspective fleshed out,
this will help provide a more coherent model.

YK: I believe I am in the second camp, what leads you to believe I am not.

### Conclusion/Resolution

AWB + MM + YK will break out.


### Object.Prototype Security issue with Proxy
presenters: Dan Ehrenberg / Jeff Walden

JW: slide (the attack: same-origin polciy workaround)

WH: we would have more of a problem if we expanded JS syntax?

JW/DE: slide (Why not, and not earlier?)

JW: getters are more constrained, but it is slightly harder.

YK: this seems also bad

YK: can you force SW to cache the opaque thing.

JW: the browser cache is sufficient, each new script element gets invoked.

YK: throttling that seems like one way to mitigate

… some discussion to clarify the attack vectors of CSRF …

JW: slide (The attack: Some-origin policy workdaround)

JW: Object.prototype/ Window.prototype. EventTarget.prototype

WH: Could the system say, this is not a a script?

MM: there is a header that can be used

DE: sights should use that, but that isn't sufficient.

JW: the browsers must support the flexilibty, due to far too much content
depending on this.

JW: slide (...)

JHD: would [] cause the same issue wrt Array.prototype?

JW: no, not observable

JW: slide (Why not, and not earlier)

DE: i added some counters to chrome, and discovered far to many such
occurances. Forcing mime-type/no-snift would break the web.

JW: slide (one solution: lock down __proto__)

AWB: ECMAScript requires that the global object had object.prototype in the
chain.

JW: as of yesterday release FF ships with an immutable global object proto
chain, with no compat issues so far.

JW: alpha 12 weeks, beta for 6 weeks. still no issues. (October)

YK: if you want to do this, we may explore the realm API.

JW: why?

DE: BT said they have an embedding object that uses this.

YK: you can imagine a realm API, that would allow a proxy wrapped global.

MM: wouldn't that cause the issue.

SP: no, the custom realm would not get script tags invoked with it in

YK: We should make sure that we also prevent the attacker from using realms
for this, so being sure we can't get the scrpt tag behavior in it.

JW: slide (but how?)

A. make pbject.prototype exotic
B. add a MOP operation

MM: i've wanted option B

BT: are you ok with A. now?

MM: yes, we should explore B later.

YK: is it possible to say, it can't be a proxy?

DE: The V8 team had an idea, to prevent the global trap to be a proxy

MM: it would allow the ability to discover whether an object is a proxy or
not.

... discussions. some rabbit whole ...

MM: this is fairly strong, re: web compat

YK: it is not obvious to me, as we have seen IE ship for years, and only
when chrome ships do we notice the web compat issue.

DE: we will have moderate evidence by march when this freezes

DE: IE has some anti phishing technique that no one is quite sure how it
works.

MM: i am in-favour of accepted ??? now

DD: I second

MM: thank you Mozilla for doing this experiment.

### Conclusion/Resolution
- lets do A (merge the PR now)
- TC expresses interest in B, it requires a proposal (will be stage 0 once
written)

## quick interjection: method param decorators, function expression
decorators (YK, MH)

YK: stage 0 for function decorators?

AWB/MM: stage 0 is exploratory, make it part of the same proposal?

… discussion about splitting/decoupling proposals …

… MH putting up slides …

MH: first slide, method param decorators example: `refresh(@lastRefreshTime
timeStamp) { … }` as example

YK: additional metadata about the param they're attached to

MM: can not change meaning?

YK/MH: can change meaning. decorator gets extra info to identify that it is
a function param.

MM: happy with stage 0.

MH: function param decorators: `schedule(@memoize (value) => ...)`

WH: Syntax conflict with the method param decorator example `@leg('right')
rightLeg`. When used with arrow functions above, the `@memoize` decorator
would swallow the arrow parameter list `(value)`, just like the `@leg`
decorator swallows `('right')`.

MH: corrected function param decorators example: `schedule(@memoize
function (value) { … })`

… discussion that clarifies that they could replace the value, like all
decorators …

MM: keep as separate stage 0 proposals

MF: tl;dr about problem trying to be solved?

MH: 1) dependency injection, example shows on constructor parameters

MH: motivation: testing (@timeout), @flaky, @disabled, @slow/@expensive,
@description, @async, etc

#### Conclusion/Resolution
 - Method param decorators at stage 0
  - Function expression decorators at stage 0

## Function#toString && Function#isPortable (MF)

MF: slides: current stage 1

MF: original goals:
   - remove forward-incompatible requirement
   - clarify "functionally equivalent"
   - standardize string representation
   - clarify "actual characteristics"

MF: revised goals:
    - define "portability" with `Function#isPortable`
    - make a guarantee about the behavior of portable functions after
deserialization in an equivalent lexical context

MF: what does "portable" mean slide:
     - a function F defined in a lexical context L is portable is any
function generated from the eval of Function#toString in L has a [[Call]]
that's indistinguishable from F.[[Call]]

MM: closest to "no free variables" that you want is "no free vars besides
standard globals". this might allow failing on the sending side instead of
the receiving side.

JHD: use case of "list the free vars" might be, user deciding if they can
send a function to a webworker for example and reconstitute it safely

MM: allows description of behavior to be moved

DH: perhaps isPortable shouldn't be something we encourage people to use
and we should put it not on Function.prototype

WH: Why did you define the concept of portability?

AWB: when reading the agenda, i didn't know what "isPortable" meant, nor an
intuitive sense

MF: that's why i've defined it on this slide

WH: *commenting on slide with definition of portability in terms of
function observational indistinguishability*: What does it mean to be
indistinguishable? If functions A and A' both return the current time, are
they indistinguishable? If A returns 5 on big-endian machines and 7 on
little-endian machines and its clone A' happens to run on a different
endianness from A, are they indistinguishable?

MF: ?

MF: slide (goals);

YK: some function exist, which when calling toString may not produce an
evalable function.

MM: MF is addressing that, but it doesn't answer, among functions that give
you an evaluable string

MF: slide (what is the lexical context?)

MF: slide (what isn't portable)

YK: does the proposal introduce isPortable false, that is evalable?

YK: isPortable means, is evaluable then.

MF: slide (what isn't portable)

MM: isPortable is things that will evaluated without a syntax error.

MF shares spec text

ARB: indistinguishablity criterion is trying to use obsrvational
equivalence, which is superhard even for much simpler languages. Moreover,
this requirement is impossible.

WH: Any kind of definition of isPortable like this is not sufficient to
meet the indistinguishability criterion. There are plenty of places where
ECMAScript gives implementations latitude in how they implement features
(sort, Unicode version, and floating point library accuracy are some
examples; there are many others). A deserialized copy of a function
serialized on a different engine will observationally differ from its
original. Given this, I still question the use for defining the concept of
a portable function or isPortable.

ARB: Much simpler counterexample to indistinguishability criterion:
```
let g = function f() { return f === g }
```
Eval'ing g.toString() cannot create an indistinguishable function.

MF: already in existing spec

ARB: then it's a bug

*parse tree discussion exploring the idea of replacing function equivalence
with parse tree equivalence*

WH: What exactly is a parse tree? What about whitespace?

DH: White space and comments should be preserved.

YK: No, they shouldn't.


… discussion about parseability, errors, `new Function` to detect,
toSource, etc …

MF: "possible solutions" slide

#### Conclusion/Resolution
 - none yet, will continue tomorrow morning, first thing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160205/1a085a4d/attachment-0001.html>

January 28th 2016 Meeting Notes

Eric Farriauolo (EF), Caridy Patino (CP), Michael Ficarra (MF), Peter
Jensen (PJ), Domenic Denicola (DD), Jordan Harband (JHD), Chip Morningstar
(CM), Brian Terlson (BT), John Neumann (JN), Dave Herman (DH), Yehuda Katz
(YK), Jeff Morrison (JM), Lee Byron (LB), Daniel Ehrenberg (DE), Lars
Hansen (LH), Nagy Hostafa (NH), Michael Saboff (MS), John Buchanan (JB),
Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar Horwat (WH), MarkS.
Miller (MM), Sebastian Markbage (SM), Zibi Braniecki (ZB), Andreas Rossberg
(ARB), Ian Halliday (IH), Keith Miller (KM), Tim Disney (TD), Misko Hevery
(MH), Brad Green (BG), Kevin Smith (KS), Brad Nelson (BN), JF Bastien
(JFB), Shu-yu Guo (SYG), Rick Waldron (RW), Staś Małolepszy (STM), Dean
Tribble (DT)


## Agenda

https://github.com/tc39/agendas/blob/master/2016/01.md


## Function#toString && Function#isPortable (MF)

Slides:
https://docs.google.com/presentation/d/1o8jVhyVHljCFyXdxe-V4X1pUmCgx0FuFvEO0fFP4LJU/edit?usp=sharing
Spec text:
https://raw.githubusercontent.com/michaelficarra/Function-prototype-toString-revision/fc69a0a31dc6d625736bfbb712ac782eb241ff3d/proposal.html

MF: No longer interested in "portability"

YK: Do your changes cause a method with super to produce an evaluatable
function with .toString()

MF: No.

MF: < Presents new spec text >

MF: Either you are a bound function exotic object or other callable or
throw an error.

WH: What case does calling toString on Math.sin fall into?

MF: The last one: [native code].

AWB: What if I want Math.sin to be self-hosted in ECMAScript?

MF: Host can control the internal slot...

AWB: Not if it's an ecmascript function object. An ECMAScript function
object is an object that is created syntactically from ECMAScript code.

MF: implementation cna pretend there's a slot.

AWB: Concern is for self hosted built-ins you want them to be opaque.

MF: We can add a case for built-in functions. Is that something that we
want to do?

BT: We should mandate that built-in functions show [Native Code]

YK/MF: Agree.

AWB: Are implementations allowed to hide source code for ES functions?

YK: toString is a defacto reflection mechanism. Web depends on it.

AWB: Not all code runs on the web.

AWB: Seems like a value add.

MM: It would be a value add for an implementation not to support sloppy
mode.... but it can't claim to be conformant.

(Discussion of how imortant toString returning source is...)

BT: Bound functions should show [Native Code]

MF: Currently an option.

(Agreement that it should be required)

MF: Ok.

*discussion about what method name to use, and what if it isn't an
identifier*

MM: Don't use the current value of the name property.

WH: This won't solve the problem of it sometimes not being an identifier.
You can have a computed property name for a method that doesn't evaluate to
an identifier.

MM: Treat the [computedname] expression, instead of the string it evaluates
to, as part of the source code of the function?

WH: That's not really part of the source code of the function. It's part of
the context.

MM: It's the same situation as with class extends expressions.

YK: The fact that you can omit the extends clause is an issue.

?: Just use the original source's AST.

MM: Let them throw away comments.

?: What about calls to `new Function`?

WH: Don't want to require comments and whitespace to be preserved. And what
about comments on the boundary of the function (before the first token or
after the last one)? Are they part of the function or not?

*back and forth about preserving whitespace or not*

WH: Current engines are inconsistent about whitespace, even within one
implementation. Firefox sometimes preserves whitespace, sometimes doesn't.
Different implementations differ in many ways on this. Reiterate not
mandating preservation of whitespace and comments.

MM: Agree.

*later MM changed his mind again*

No consensus on whitespace treatment.

#### Conclusion/Resolution

Keep exactly the original source text starting from the position of the
first token of the production and ending at the position of the last token.
Within this text, keep comments and newlines. Still no conclusion about
insignificant whitespace, i.e., whitespace other than newlines.

- MF will adapt what was discussed into the spec text, advance stage 2 that
is complete

- Reviewers: MM, WH, YK

## larse

LH: slide (formal reviewers)

LH: looking for multiple reviewers

WH: I have memory model expertise and will review that aspect. Also suggest
having Hans Boehm look at it.

BT: this specification requires continent etc.

LH: it doesn't have to be deep, but we require some framework to be
in-place.

DE: any typed array designers inovled

AWB: me

DD: If he comes to us in afew months, and presents the API, we would prefer
to not then have to dig in

DD: last time the TC made changes quite late, it would be great to catch
those early

...

LH: some changes to the typed array spec, to accomodate SharedArrayBuffer,
should be vetted

AWB: I would be happy to discuss

#### Concluson/resolution

* DD DE AWB will be reviewers

Rundown of reviewers (from LH's notes):

- littledan will represent v8
- brian for chakra (but he will look for a delegate)
- unclear for jsc (LH will ask filip pizlo)
- waldemar for the memory model
- allen (informally possibly) for TypedArray changes
- domenic for agents/vats/whatever

LH: Also desirable for everyone to read the spec and pitch in, the more
eyeballs the better.

## 5.xix Proxy Enumerate - revisit decision to exhaust iterator

(Brian Terlson)
https://github.com/tc39/ecma262/issues/160



BT: issue with proxy enumerate trap and for-in, where iimplementations are
prevented from pre-populating the list of keys in the object, because the
iterator causes observable affects. Which means the iterate must be pulled
for every iteration. Last meeting we thought it would be ok if the
enumerate trap exhausts the iterator, we thought that would solve the
problem. The issue was, now their is an observable difference between an
object and proxy of that object, mainly due to delete.

AWB: thats wrong

AWB: if you doit as part of for-in it wont be a problem, as for-in can be
specified to ignore deleted keys.

BT: right now, for-in does not do a has-check for every property. If a key
is deleted, it wont be seen. That is how proxies in edge work today,
deleted keys (during enumeratino) are not visited.

BT: We could say, for-in (or proxy enumerate trap) will exhaust the
iterator and check on each iteration

ARB: that is what v8 does

BT: I dont want an observable difference for for-in

YK: the has check on a proxy is non-observable anyways, and often it can be
skipped anyways.

AWB: the classic spec if i recall, you cannot get a duplicate key, if
something is added during enumeration you may or may not see it, if it is
deleted before you enumerate it you must not see it.

ARB: enumerability is also something we need to take into account, I think
more issues exist, we should likely keep it vague.

YK: thats one approach, as we don't have this defined, maybe the proxy
needs to reflect the implementation

AWB: proxies can do very interesting things

YK: the enumerability is already quite  hazardous, this isn't really
anything new.

MM: it seems like these rules could be specified, could we just do that?

MM: v8 on normal objects does snapshot + has check, but not post-snapshot
enumerability check.

YK: So far, we have spec'd this as vague, to allow divergence

MM: we should specify this,

BT: i will need to do some exploration

MM: does anyone, based on their implementation know that they would object
to specifying proxy + regular objects, the semantics of snapshot + has-check

BT: I would love that

MM: let's leave this to you to investigate, and a future meeting.

YK: we want this for es7

DE: can we get consensus on GH.

WH: Are we specifying a long delay before you get the first element if you
begin iterating on an array with a billion elements, even if you just want
the first few?

BT: yes we are, but we all do this already

ARB: one issue with snapshotting, is how does it relate to the prototype
chain

BT: yes this is under specified

YK: we should try to

AWB: the reason it was under specified was

BT: jscript?

AWB: ya sorta, minor variations among implementations. At that point in
time, consensus  was dificult it seemed like we couldn't do this. If we
can, we should

BT: unsure

YK: if we can, we should

AWB: the other issue is: it isn't clear to me why we have an enumerate trap

BT + ARB: me neither

AWB: for-in has enough meta operations to define what we want.

MM: we should ask tom, as he thought this stuff out in great detail

DH: isn't that question too late?

DE: it isn't a web compat issue yet.

DH: it isn't obviously a mut question, but we may not be able to.

DH: i do not know how often this is used, isn't enumerate a fundamental
trap.

YK: i agree that is a thing

... discussion if enumerate is fundamental ...

YK: spidermonkey people have the strongest here

BT: We have internal users of proxies, we may have a constraint

YK: that isn't a constraint it can be deprecated,

BT: comes at as cost, but i doubt its actually used.

ARB: one reason for enumerate trap may be that the set of all properties is
larger then the set of properties that are enumerable, so a performance
difference is pssible.

YK: getOwnPropertyDescriptors + filter out enumerable, covers this

BT: what is the trap name for all property names .... getOwnPropertyNames

BT: should for-in just be implemented as that.

BT: we would get rid of enumerate trap

ARB: doesn't one return an iterator

AWB: i think the enumerate trap was the only MOP operation that returned
the iterator

...: if we have serious performance implementations for internal, we will
keep it, but wont expose it

BT: it might not be possible to... we will have to give an explicit
ordering for prototype properties.

AWB: the only way to doit, is to set some requirements, vague or not

#### Conclusion/Resolution

 - provisional consensus to kill enumerate trap, contingent on running it
by tom
 - for-in does [[HasProperty]]


************** Response from Tom: **************

A few things come to mind:

1) Faithful virtualization of the prototype chain. We decided that the
Proxy should always be in control of operations involving prototype
inheritance. This includes has, get, set and enumerate. For all of these
operations, when executed on a normal object, they will walk the prototype
chain until they hit a Proxy. After that point, full control is delegated
to the Proxy. If a Proxy would only be able to override get() and set() but
not enumerate(), this may lead to inconsistencies (without an enumerate()
trap, the VM will have to externally walk the prototype chain of the Proxy
via getPrototypeOf()).

2) When we designed Proxies originally, we made the design decision to map
many built-in operations directly to specific traps, even if these
operations could be expressed in terms of more fundamental operations (get,
set, has, enumerate are all examples here). The design argument here was
always improved performance by reducing the number of temporary allocations.

Much later in the design, others started pushing back on the number of
traps, leading us to reconsider some traps, e.g. I recall the "hasOwn" trap
was dropped in favor of checking whether (getOwnProperty() !== undefined),
even though it is strictly less efficient. I don't have a view on the
actual cost of expressing enumerate() in terms of lower-level MOP
operations, but it seems obvious that there will be more allocation costs
involved. The question is then: if enumerate() gets dropped on these
grounds, why not get(), set() and has()?

3) As far as I recall, enumerate() is the only trap that actually returns
an *iterator* over the property names, allowing efficient virtualization of
objects with a large (or potentially, infinite) number of properties. The
only other trap that returns a list of property keys, "ownKeys", returns a
manifest array of property names.

4) enumerate() had weaker invariants than ownKeys() [just like all the
traps that deal with prototype inheritance, since a frozen object can still
inherit from a non-frozen object, leading to weaker observable invariants
in general]. If one would express for-in in terms of repeated calls to
ownKeys(), the invariant check overhead may be substantial compared to just
calling enumerate().

Unless there are really good reasons to get rid of enumerate(), I think it
should remain in. For me, (1) and (3) are the killer arguments: consistency
with has(),get(),set() and efficient enumeration via iteration.

Feel free to forward this mail to TC39. I'm happy to engage in follow-up
discussions, just ping me when needed.


*********************************************************


## 5.xviii Exponentiation Operator (RW)

RW: i implemented the changes, tried to get brendan to review it (no luck).
BT reviewed, and chakra implements

RW: BT and I went over it line/line, followed up with new tests, and in the
last 20 minutes per domenics suggestion I duplicated the applying **
operater tests, so both map.pow and ** tests. the SM folks will be happy
that they all passed (except for one, but that's expected).

RW: chakra implements, applause for OSS chakra

RW: motion to include to stage 4, inclusion for 2016

BT: thanks rick

RW: any objections

#### Conclusion/Resolution

 - stage 4!

(Lunch)

## Afternoon Agenda

1. Date and place for the next meetings

#### Conclusion/Resolution

Meet in Munich Monday May 23-Wednesday May 25

## 2. 402 needs reviewers (20min)

CP: HTML version of the second edition is now public (
www.ecma-international.org/ecma-402/2.0/),  just like 262. We have done
some re-orgs on the spec to make the new features easier to include. Many
new features have been proposed, lots of new contributors, good momentum.
At this point we need reviewers

DE: first we need to propose to stage 2.

CP: we want to move 3 things up, and get reviewers, and one small detail

AWB: before we get to stage 2 things, what is the status of 2016 402. COuld
we have a summary of what is in 2016 402.

CP: it will be very small, some fixes related to locale parsing. One or two
functions, that will expose existing abstract operations.

AWB: are those written up, you know the schedule, that means by the next
meeting you have to be done

CP: yup

EF: we have one potential problem to discuss,

EF: slide edition 1 [[CALL] Behavior (Considered a Spec bug)

AWB: thats basically, at the time the spec was drafted that was how the
current thinking of internal slots to happen. This allowed internal state
to be dynamically added to instances, that was decided inappropriate, and
ultiamtely abondoned.

EF: the problem was, a library intl, format cache. using memoizing used
this pattern. This pattern was introduced in sept 2014. The issues rolled
in nov 2015.

EF: I fixed this in a patch release of the library

EF: slide (tl;dr of intl-format-cache dep on Edition 1 Behavior)

EF: slide (intl-format-cache at 2.0.5)

EF: slide (Potential Impact? (Excluding Yahoo's Usage)

EF: slide (ative wart removal)

EF: impact is likely large.

AWB: in addition 1 of 402, it was possible for a single object to be
multiply constructed, and get the private state of each constructor.
Hopefully no-one has done that

EF: ya, not our problem.

AWB: it occurs me, leaving it as addition 2, their is likely a work-around.
Specializing object.create for this pattern.

DE: no...

EF: slide (tl;dr of intl-format-cache dep on Editirion 1 behavior)

DE: if we can scope these changes to the intl functions, rather then
O.create

AWB: you don't want this to be in the spec. So what is the smallest thing
one can do to maintain the compat.

EF: we can also rollback the changes in 3, and see the impact.

EF: slide (active wart removal)

RW: the first addition was a mistake,

everyone agrees

RW: we fixed it because it was broken, the fact that library relied on the
brokeness is unfortunate. The only way to fix this is to re-break it.

DE: What should implementations do

MM: i think we can fix this

RW: @MM, did you review the comment i posted?

MM: please send me the link to review.

EF: presents comments on GH issue 57

...MM explores the code...

MM: what you do, is the call behavior of Intl.Collator if its sees an
object that inherits from Collator.prototype that is not a collator, it
creates a new Collator and uses a unique Symbol to hang that newCollator
off of that object. All the builtin Collator methods then checks whether
their alleged Collator argument is a non-Collator with a property named by
that Symbol. If so, it looks up the Collator state on the value of that
property, i.e., it forwards all state lookup to the value of that property.
A hack to deal with an emergency. No security issue here, so no problem
that the Symbol can be read and used for other purposes. No accidental
collisions, all the primitives must then detect the collator.

SP: this isolates the fallout

MM: it can be self hosted, after the emergency is over can be removed.

RW: (Agree)

YK: We may want to leave a note

AWB: Annex in 3rd Edition that explains the compatibility issue and how to
address it.

YK: as long as its in the actual spec we are good

EF: DE could google try Mark's suggestion of restricting .call's extra
behavior to just this case, on the output of Object.create for a given Intl
instance type this out?

DE: yes, it seems reasonable

#### Conclusion/Resolution

- wont roll it back
- try MM suggestion in chrome to support web compat
- add note to 402 annex (third edition, references second and first)


## 5.xix (Revisit) Proxy Enumerate - revisit decision to exhaust iterator

BT: Proxy.enumerate is removed, should Reflect.enumerate be removed?

JDH: it would be unfortunate

YK: I think its worth having a bucket that is 1:1 with the MOP operations,
reflect happens to do that. If we remove Proxy traps, MOP should also see a
similar removal.

AWB: it seems alot harder for Reflect.enumerate then Proxy enumerate trap

BT: the usecases for Reflect.enumerate outside of proxy enumerate trap
isn't very compelling. If we feel comfortable removing the proxy trap, we
should feel comfortable removing Reflect.enumerate

MM: i think you are correct, but if some interleaving between enumeration +
proxy traps

MM: cross browser web-pages, can't

JHD: polyfils have this

YK: they will continue to work

BT: any objection to remove Reflect.enumerate

MM: We need to check with Tom Van Cutsem first.

#### Conclusion/Resolution

- Remove Reflect.enumerate, contingent on further information from Tom


************** Response from Tom: **************

A few things come to mind:

1) Faithful virtualization of the prototype chain. We decided that the
Proxy should always be in control of operations involving prototype
inheritance. This includes has, get, set and enumerate. For all of these
operations, when executed on a normal object, they will walk the prototype
chain until they hit a Proxy. After that point, full control is delegated
to the Proxy. If a Proxy would only be able to override get() and set() but
not enumerate(), this may lead to inconsistencies (without an enumerate()
trap, the VM will have to externally walk the prototype chain of the Proxy
via getPrototypeOf()).

2) When we designed Proxies originally, we made the design decision to map
many built-in operations directly to specific traps, even if these
operations could be expressed in terms of more fundamental operations (get,
set, has, enumerate are all examples here). The design argument here was
always improved performance by reducing the number of temporary allocations.

Much later in the design, others started pushing back on the number of
traps, leading us to reconsider some traps, e.g. I recall the "hasOwn" trap
was dropped in favor of checking whether (getOwnProperty() !== undefined),
even though it is strictly less efficient. I don't have a view on the
actual cost of expressing enumerate() in terms of lower-level MOP
operations, but it seems obvious that there will be more allocation costs
involved. The question is then: if enumerate() gets dropped on these
grounds, why not get(), set() and has()?

3) As far as I recall, enumerate() is the only trap that actually returns
an *iterator* over the property names, allowing efficient virtualization of
objects with a large (or potentially, infinite) number of properties. The
only other trap that returns a list of property keys, "ownKeys", returns a
manifest array of property names.

4) enumerate() had weaker invariants than ownKeys() [just like all the
traps that deal with prototype inheritance, since a frozen object can still
inherit from a non-frozen object, leading to weaker observable invariants
in general]. If one would express for-in in terms of repeated calls to
ownKeys(), the invariant check overhead may be substantial compared to just
calling enumerate().

Unless there are really good reasons to get rid of enumerate(), I think it
should remain in. For me, (1) and (3) are the killer arguments: consistency
with has(),get(),set() and efficient enumeration via iteration.

Feel free to forward this mail to TC39. I'm happy to engage in follow-up
discussions, just ping me when needed.


*********************************************************



## 8 Ecma 402, Edition 3, Advance stage 2

(Zibi Braniecki)

402-related slides:
https://drive.google.com/drive/u/1/folders/0B1rFz38aICo2YUpVd0VfTUdwRW8

## formatToParts

https://docs.google.com/presentation/d/1GuPC_pD84VFf4Yc8NKNDFBBmX6uY9DMA5CtKZoAdrzM/

ZB: slide (format to parts)

ZB: further customization, requires exposes of abstract operations such as
format to parts.

ZB: slide (current status)

ZB: polyfil has it, gecko has it behind flag

ZB: we are looking for reviewers

AWB: how about formatParts

DE: its the output  not the input, so formatToParts

DE: I will review

RW: I will review


#### Conclusion/Resolution

- stage 2
- Reviewers:
    - Rick Waldron
    - Daniel Ehrenberg

## Intl.PluralRules

https://docs.google.com/presentation/d/1WflzD4YMOYYmJDAmjwmG0wi5GnLZd74EwvDRKSL9vA8/

ZB: slide (usage)

ZB: we are just following CLDR conventions here

ZB: we are at stage 1, we have spec text. Current status we worked on
decimal parts, which was a previous concern

WH: How do you distinguish between 1 and 1.0? These two have different
plural rules in some languages but 1 === 1.0.

DE: extra fields in the input to specify number of fractional digits

EF: to mirror what number format has

ZB: reviewers?

MF: Is there a reason why we are using strings instead of other output

ZB: yes, the users will use this in a switch catch, those categories are
part of the CLDR

MF: some other identifer could be used on a stable object

YK: the web has moved away from this

YK: the web has stopped to create constant that point at a number

DD: yes, absolutely

AR: Yes, anyone presenting a sepc with a number constant will be asked to
re-work it

DD: userland could implement if they want.

AWB: what value would we actually deliver, in both cases they need to know
the name

YK: they are both constant

SP: userland can do this

AWB: Yes, I don't know how...

ZB: reviewers?

SP: me

DE: me

#### Conclusion/Resolution

- stage 2
- Reviewers:
    - Daniel Ehrenberg
    - Stefan Penner


...


## Abstract Locale Operations

https://docs.google.com/presentation/d/1JvUv_i7rb0UF6G-nl-Eu3pHvJsmhpfqV6qWwJ6yP2aA/

ZB: we wont provide all formatters, but we will all users to build their
own.

ZB: will allow users to build language negotiations

ZB: slide (Intl.getCanoncialLocales(locales)

ZB: Intl.getParentLocales(locales)

ZB: many exceptions here,

ZB: we have all these operations, somewhat inconsistently used internally.
Now we will expose them, and also use them in-consistency

ZB: there are 100 exceptions to the rules

ZB: slide (Intl.resolveLocaleInfo(locale[ ,options])

WH: What's the point of passing in {direction:true, firstDay:true,
hour12:true} when retrieving the options object? Why not just return the
whole object?

CP: why filter, why not just return everything

ZB: optimization? We can drop it

ZB: slide (current status)

MM: can we agree that the second argument that contains the filter, that we
are getting rid of that

ZB: yes

CP: yes

WH: yes

MM: does the api return a fresh one?

MM: It needs to either return a fresh one or a deeply frozen one. Otherwise
you'd have a global communications channel.

ZB: unsure

DE: yes

CP: whats in the content of the object returned, is it spec'd

SP: needs further exploration

### Conclusion
- stage 2
reviewers
    - Stefan Penner
    - Daniel Ehrenberg

### Intl Formatter preview

ZB: this is still exploration

ZB: slide (Intl.UnitFormat)

ZB: lots of un-answered questions

ZB: slide (Intl.DurationFormat): Video player or timer in a watch. Distinct
from UnitFormat

ZB: slide (Intl.ListFormat): Localize "Mary, John and Nick", including
change String.prototype.toLocaleString()

ZB: slide (Intl.RelativeTimeFormat): "two seconds ago", etc.

ZB: everything is in CLDR, and we want to expose this

DH: A lot of these are solved in userland, what is the scope? Is it for
things that are already there, we want to surface those? If its not in CLDR
do we leave it to userland

ZB: yes

CP: also prioritize it on the amount of data and complexity

ZB: these 4 handle the most common problems we have seen.

CP: considerable existing bikesheeding, but more are invited to join.

ZB: stage 0?

### Conclusion

- advanced to stage 0

### Async generator functions
presenter: Kevin Smith
link to presentation:
https://docs.google.com/presentation/d/1OwDb4WH9pkdEFVhsY5kjaJ6MF1KrxBNQWpWc9SymweQ/edit#slide=id.p

KS: slide (overview)

KS: Async generator functions return AsyncGenerator objects, with a
for-await loop

KS: Review iterator interface. Async iterators are analogous, but return a
promise of the the IteratorResult, and use @@asyncIterator

DH: AsyncIterator extends AsyncIterable, right>?

KS: Yes.

KS: AsyncGenerator is what you expect, with next, throw and return. Why?
Integration of existing concepts, rather than creating a new one.
Pull-based, no extra backpressure protocol required, easily converted to
push-based Observables. A nice feature of this, with streaming applications
no backpressure is required. It can easily be converted to a push based
source, by taking the async iterable and pushing it.

MM: by convert you mean adapter

KS: yes, exactly

KS: slide (The async iteration statement) – async variant of for of

KS: slide(Bikeshedding: Why for-await?)

DH: pretty strongly agree, the thing that is actually signalling, is that
there are additional awaits

MM: additionally, these are interleaving points.

KS: ctrl-f for await, makes it easy to find interleaving points

YK: it is important that we are allowing two more control states to be
reified through this mechanism

KS: that isn't a bikeshedding concern, rather a concern about modelling...

YK: No, I am fine with the modeling. I want to be sure break/continue
control state to happen.

YK: async modifier takes a construct..

DD: it converts it into an async context, does it make it async itself.

DH: i dont think thats the intention

YK: Introducing more async functions would be good, but here we're talking
about not introducing one so await makes sense

KS: we can explore other contexts, async do etc No baring on this.

KS: Slide (Details: Promise Unwrapping)

SP: so yield will unwrap any thenable (not promise)

DH: i am having a danger will robinson moment, composing two concepts, and
now we merged them.

```js
async function* agf() {
    yield Promise.resolve(1);
}
````

WH: Are you proposing that the above do the same thing as replacing the
yield line above by 'yield 1`?

KS: Yes

WH: We've had the discussion before about whether promises stack or they
are idempotent. We decided that one after a long debate to prevent promises
stacking.

DH: yield and await merging.

YK: yield and await have different precedence is pretty bad

DE: doesn't it already do this, as we recursively unwrap.

KS: But we recursively unwrap the IteratorResult, not the data slot!

DE: Oh! So you want to await that?

KS: Yes, and we await as part of yield.

KS: these are still open question, what if i swap `yield Promise.resolve`
with `yield Promise.reject`

DT: in midori we had iterator of promise, the producer can run ahead,
launching the subsequent async computations.

DD:  these are both handled: sync iterator for promise, async iterator for
promises

DT: i think it is orthogonal

DD: there is no distinction, we can collapse them down to one level

DH: So because we don't have promise for promise, this structure wont
absorb them.

DH: yield / await wanted to absorb

KS: originally i didn't have this flattening, the discussion was that well
we have made choices were we dont want to have promises for promises, and
that would seem to make it the same as a promise for a promise with an
extra done bit

MM: I dont know what side of this I'm on yet, but let me put this into
other terms. The things you can have a promise for are non-promises.
Promises can only promise non-promises. The design question here, are async
generators sources for a sequence of non-promises, or are they are source
for a sequence of anything. Consistency cuts both ways, collapsing can be
good. On the flip side, when you create a container, a container can
contain any value not just non promises. A container can have more things
over time. If you see a stream like this as simply a container. Then most
containers can contain promises.

DD: you can swap the word "container" for promise, and the argument flips.

DD: complete abstract concepts should synergize

WH: i don't know what that means

DD: Async Iterator should have unique behavior that is the composition.

DD: I think that you are saying, that a type with a certain structure, that
semantics are entirely containeed rather the surrounding semantics.

DD: there could be semantics on top of the compositional concepts.

DH: you guys agree 90%, there could be a new type Asynciterableresult, or
you are saying promises could absorb this.

YK: or syntax could absorb it, but that is only half the battle

DH: absorption at all?

MM: Back when we were doing promises, one of the questions that came up
regard the collapsing or not. Given collapsing, with the cooperation for
both sides, can we still somehow express the functionality of a promise for
promises? I have needed this. The work around is to wrap the promise in a
cell, and the reciever needs to unwrap the cell. By a simple cooperative
adaptation, can either functionality be layered on top of the other? I
believe the answer is yes. Given that, the remaining design constraints
should be "Simple things should be simple, complex things should be
possible." (Famous Alan Kay quote).

DH: Are you saying async iterator can be implemented in terms of the other
version?

MM: either of the two forms of async iterator we are discussing can be
cooperatively represented via the other, so the main criteria should be
simple should be simple, complex should be possible. The dominent use-case
is delivering non promises.

MF: you are mistaken about several things, the goal isn't to deliver a
promise of a promise. The goal is to deliver a promise of anything. We
don't care about promise for promise, we care about a promise of anything.
People see that as the simpler thing.

MM: you are correct, simple isn't the right word as simple can be used on
both sides. A consumer that knows to only deal with non-promises, is the
dominant kind of consumer.

MF: people write libraries that need to support this

MM: general polymorphic libraries that want to support any type of input

DE: we already have this precedent in promises, we should have this be an
edge case.

DH: i think its really important to understand, some think interms of types
and parametricity. The fact of the history of promises, JS types are split
tino 2 universes. (promises and non-promises)

ARB: one is included in the other, which is the problem

YK: it is already the case ...

ARB: contents of promises is were the worlds "collide", otherwise
unwrapping wouldn't be useful

KS: let me put a bookend on this part, clearly strong feelings on promise
unwrapping.

KS: the difference would be, if you didn't do the unwrapping someone would
need to do yield + await

MM: a worse issue, consumer side. Does it see iterations. Are we trying to
define an abstraction to see an iteration of non-promises, or are we trying
to define and abstraction to asynchronously deliver values.

WH: Collapsing is trying to remove the need to say `await` when calling a
function in a `yield`. But how does this work in a regular async function?

Compare

``async function* f() {
    yield g();
    yield h();
    yield i();
}```

with

```async function f() {
    g();
    h();
    i();
}```

The latter one doesn't implicitly put awaits in front of the calls to g(),
h(), and i(). Consistency would imply that the former shouldn't either.

*more discussion*

KS: It unwraps it recursively

KS: for-await falls back to Symbol.iterator when Symbol.asyncIterator is
missing

DT, MF: This may be a hazard, or maybe not if you insert the right
turn-taking

KS: slide (Queueing). What do you do when someone calls next repeatedly
without awaiting?

DH: Unbounded queue?

KS: You could return a rejected promise, or put it into a queue and pick
them up as appropriate. I've been going back and forth on the various
options. It's not essential to the design yet--at some point, I switched to
rejecting, but this caused some bugs in my program, but it ended up being
fixable

MM: in the queueing case, it still returns the exact same thing

MM: the queueing up seems much friendlier.

SP: yes

MM: one guy calling .next (can take an argument) because the consumer is
assumed to be paused on a yield, allowing it to go to the consumer without
an intermediate buffer. The whole reason for this, is 2 async coupled
entities, allowing one to run ahead sounds very fine.

TD: we started with "it fails" and worked around it, ultimately giving up.
As soon as anything got speculative, it got complicated. Pushing it into
the infrastructure, making it queue, up so that everyone had it.

MM: This can be very useful, not buggy

YK: the fact that is different that is is different from the flip side algo

KS: actually, examples exist.

KS: this is the same

YK: ...

DH:  mapping these to known analogies were i feel more confidence, falling
async is JS approach to threads. The analogy from a sync threading
language, I have a thread that is producing me abunch of values, I block
waiting for the next value, I as the consumer should not be sensitive to if
the other thread is blocked or not. It should be internal to the thread
implementation details, leaking this to the cosumer isn't correct

MM: both sides block, in JS that is a promise.

KS: slide (current status)

- partially implemented in regenerator
- its in there for several months, although for await isn't
- read for review

DH: please assume good faith, this is delicate. I think the space is
important, we need to figure out how these concepts work together, but
there is failure of our champion model, and that is over modularization...

DD: in the last meeting, we requested this specifically for big paper.

DH: No attack here.

DH: i don't see yet, how this fits in, with the other stuff that fits in
with Jafar. We have seen various variations, it is not clear to me... Maybe
the intention here is to drop all that stuff (possibly implied)

YK: is JH giving up on for on

JH:  for on, wasn't in the proposal

DH: we can't do all these things

DH: we need to figure out what our are async data types, and we need to
figure out the grand unified theory. KS has submitted great work, I still
don't see how this all works together.

DD: we said something stronger, we wanted both AsyncIterable and
Observables on stage, so we can properly view this.

DH: if we continue to advance these overlapping ideas, we need to be sure
we don't defer how to ensure the grand unified theory works.

YK: stronger concern, both proposals want to arrive at syntax. We can
likely only get one of the two syntaxes.

YK: we can get for on, or for await, not both.

DH: it seems far less for us to imagine the coexistance of both data-types
in the languages, but with the new syntactic constructs present much overlap

KS: My opinion is this is await for in is the only syntax, and observables
could use it. As I discussed above. In that direction, it should be
complete fluid. The other direction, the subject of the await for is more
complicated due to buffer differences. In my vision, observables would have
a method that would allow observables to choose buffering strats, that
returned an async iterable. Making it compatible with for await.

JH: KS and I are in alignment, for await is what i want. We can adapt an
observable to an iterator via a buffering strategy. Other types can achieve
this.

YK: an alternative design would be async iterable result, and we should
explore

DE: these things seem like refinement process tasks. They can be explored
at stage 2

AWB: this feels like stage 1

DD: does anyone have fundamental disagreement?

YK: someone needs to respond to my exploration request. I am pretty
uncomfortable combining the two types.

.... discussion ....

DH: let me add structure

DH: their are several work areas, that have been structured as independent.
JH has been a champ in 1 direction, and KS in another. Several areas of
unstability:
    - work on observables + syntax
    - work on API for async sequences + syntax
    - it sounds like KS + JH are in aligment, observables aren't the base
for syntax. And it is orthogonal

- observables championed by JH
- we want some syntax (which obviously needs a protocol)
- API for async sequences, but without full consensus. But we need to
continue exploring.

YK: I totally agree, I am concerned that I must present an adequate
argument but do not feel able to at this time.

DE: we should explore this explicitly

DH: we should explore for await, and async sequences. We need to shake more
out.

DH: its obvious to me that those could be stage 0

DD: my opinion is this proposal is ready for stage 2, if we can agree that
the changes can be resolved during stage 2.

YK: it depends how fundamental the type composition is to the proposal

KS: I think that we ought to use promises for something that will be
delivered async. As it works with the rest of the

YK: it can be skinned many ways, additional protocols can be created.

MM: await does a Promise.resolve, maps a value to a promise, and I don't
want to reopen this.

MM: if an AsyncIterationResult is something that is not a promise

YK: is it important that it is a nominal instance of the promise
constructor?

MM: yes i believe so

YK: i am surprised

MM: if it is a thenable that it will be adapted by Promise.resolve. I am
not ok with reopening await being Promise.resolve(x).then(continuation); I
am not willing to change what that means

DE: can we decide stage 1 or stage 2, we have more to cover.

AWB: we cannot make it stage 2,

DE: we can say its stage 1 pending further review.

MM: (Somewhere in here I made the following unrecorded observation)

There is a third alternative. The async generator can be a generator of
anything. "yield" does not imply an implicit await, so no collapsing
happens on the generation side. The async iterator that is produced is an
iterator of anything. No implicit collapsing within the async iterator
itself. Its API remains fully parametric. Rather, the for-await construct
does the collapsing, in service of the simple-dominant-use-case consumer,
who wants to see an asynchronous sequence of non-promises. Each iteration
of the for-await loop does a double await -- one to get the
IterationResult, and one to get the promised value.

Any consumer who, instead, wishes to see an asynchronous sequence of
anything, can instead write their own loop rather than using the convenient
for-await sugar.

Big advantages of not collapsing at the generation side:
    * yielding an unresolved promise does not prevent the generator from
proceeding to generate. It is not surprising stalled at the yield point.
    * yielding a rejected promise does not cause a generation-side
exception. Rather it simply transmits the rejected promise. A simple
for-await consumer is stopped by the rejection throwing the reason.
    * (Pointed out by Dean): An implicit "await" at the "yield" violates
the rule that we can find all interleaving points by looking for "await".

### Conclusion/resolution

- Stage 1
- needs more exploration as per above discussion.

### Strong Mode Discussion

Presenter: Andreas Rossberg
link:

ARB: slide (recap)

ARB: slide (progress)

ARB: slide (strong mode)

ARB: slide (what worked well)

ARB: Disallowed implicit conversions.

WH: Even toBoolean???

ARB: toBoolean is the only one that remains

ARB: string conversion is used alot, but it wasn't a problem. In es6 we
have template strings, which becomes explicit.

AWB: what about toSelector, number -> string for property

ARB: ya, it comes down to some things. This one is still allowed.

ARB: slide (what not worked well) Mutually recursive classes,

MM: what was the motivation for unbound variable ban

ARB: to make errors static and avoid runtime checks

ARB: interopt made locking down classes via seal

... discussion above strong vs non-string inheritance mixtures ...

ARB: slide (takeaway)

ARB: slide (soundscript)


### Teset262
presenter: Dan

DE: reptitive tests, lots of tests that repeat each other. Their exists a
proposal to generate tests precedurally, we require implementors feedback.
Ask me and I will provide more information

### Conclusion / resolution

- implementors need to provide feedback

###

#### Conclusion/resolution

# Test262 Updates
Presenter: DE

DE: We have some changes coming into test262, e.g.,
https://github.com/tc39/test262/issues/470
https://github.com/tc39/test262/issues/467. Users, please give feedback as
to whether these are appropriate for you! Please reach out to me if you
have any concerns.

#### Conclusion/resolution

# Progress review: Callable class constructors (Allen)
presenters: AWB / YK

AWB: slide (callable Class Constructors)

AWB: slide (refresher)

AWB: slide (refresher pt.2)

AWB: slide (refresher pt.3)

AWB: slide (refresher pt.4)

AWB: slide (interesting feedback via twitter and other channels after
publicizing proposal)

YK: some feel the new fork is non compositional

AWB: slide (more feedback)

AWB: inheriting is complicated

MM: it is possible, make the default call behavior on a derived class to do
a super *call* to its superclass constructor.

YK: ya

YK: another way to say, is that we install a constructor

MM: not suggesting it is a good idea

YK: not including it, caused confusing.

YK: baseclass providing default functionality was a big concern

AWB: we will remove the rocket

AWB: we do want to enable the calling constructor

YK: almost all people people want call to delegate to new

AWB: ya, 99.9% case. Two bodies is confusing, it clearly seperates it for
the 0.1% case, like date function.

YK: it is a middle ground

AWB: todays proposal (slide An alternative approach)

```js
class RegExp {
   factory constructor(pattern, flags) {

    }
 }
```

MM: what about inheritance?

SP: it could now just be made to work, because its a unique function body

MM: does the factory bit inherit

AWB: i would say no, but it could.

MM: if the subclass does not say factory?

AWB: it reverts back to the default behavior to throw

WH: Almost the same as the original proposal. Can you use this to implement
the Date use case as on the first slide?

AWB: yes, if you want to implement date (slide -> Use single body and
new.target for date-like case)

DD: something seems bad

YK: i would expect, it installs new

AWB: we don't quite support the date case, but the 99.9% has been sorted

AWB: I will think some more about this.

YK: ES5 can still be used for the edge-cases

..: it will be hard to implement

AWB: slide (an alternative approach)

```js
class RegExp {
   factory constructor(pattern, flags) {

   }
 }
```

MM the only thing that gives me pause here, if long term we will only
address this with a specified mechanism. Date case goign back to es5, then
we are not gaining any value from having the default constructor throwing.

YK: incorrect.... i would make a looser term.

YK: lets go back to es5, a massive hazard to forget use. This made many
people not want the newless behavior.

MM: I'm not buying this

YK: the world you want to live in, they can choose new or old style, If you
happen to not like new, you call without. That world only works if all the
classes are es6 classes, if you encounter an es5 class you will likely
encounter a hazard.

MM: what I'm saying, we don't require new, the default call constructor is
to `new`

YK: i almost proposaed this...

...: from an implemenators perspective, we only included the new.target  in
frames if we new we needed this. It is a huge pain in the neck to implement
this default forwarding

BE: some wont use classes anyways, we shouldn't cater to them

MM: we should not help them

DD: their is an implementors concern.

AWB: the factory world is almost noise

... discussion ...

WH: This is unnecessary. It's creating a redundant way to create instance,
for those who don't like `new`. Given the implementation concerns, we
should not be doing this at all.

...  (the implementors) it wlil be crappy

MM: could we make something shorter than "factory constructor"

AWB: maybe, but it is a factory call

MM what about

````
class RegExp {
   () {
      // ..
    }
}
```

DT: seems like syntax and implementation default are two seperate issues

WH: Again, we shouldn't be doing this at all. Drop it instead of
bikeshedding syntax.

MM: I withdraw my proposal due to the implementation concerns

YK: i am on the side, that not using new is a minority opinioin. We should
still not lock it out

DD: we should likelynot provide constructs that will allow those to shoot
themselves in the foot, they can just use =>...

YK: decorators could enable this ergonomically

MM: we should drop this completely, and solve it with decorators.

#### Conclusion/resolution

Proposal dropped.


# Object.getOwnPropertyDescriptors to stage 3? (Jordan Harband, low
priority, but super quick!)
presenter JDH:

JDH: reviewers and editors +1'd, can we move to stage 3

all: yes

## Conclusion/resolution
- advance stage 3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160205/72f24a01/attachment-0001.html>