March 28 meeting notes

Russell Leggett russell.leggett at gmail.com
Thu Mar 29 07:56:43 PDT 2012


Any discussion on maximal minimal classes? Just curious of the status.

- Russ

On Wed, Mar 28, 2012 at 8:42 PM, Waldemar Horwat <waldemar at google.com>wrote:

> Here are my rough notes from today's meeting.
>
>     Waldemar
>
> -----
> IPR discussion
> Intel changed their ECMAScript patent declaration to RANDZ.
> Now they wonder why no one else made a RANDZ declaration.
> Istvan described the history.
> Mozilla is also unhappy with the current state of affairs.  Even
> though this instance turned out well, it shows the potential for
> problems.
> Lots more IPR discussion
>
> Rick Hudson, Stephan Herhut:  River Trail proposal
> Proposal will appear on wiki shortly.
> Deterministic, except for things such as array reduction order if the
> reduction operation is nonassociative.
> Parallel arrays are immutable.
> Various parallel methods take kernel functions to operate on subcomponents.
> MarkM: Are the requirements on the kernel functions to allow them to
> be optimized well-defined?
> Rick: Yes
>
> var a = new ParallelArray(...)
> var b = a.map(function(val) {return val+1;});
> Allen: This can be done today sequentially by replacing ParallelArray
> with Array.
>
> var b = a.combine(function(i) {return this.get(i)+1;});
> var sum = a.reduce(function(a, b) {return a+b;});
>
> Competitors:
> OpenCL: GPUs do poor job of context-switching.
> WebCL: Too many things undefined.
> Browser-provided webworkers (task parallelism).
>
> Waldemar: Can the kernels do nested parallel operations, such as
> what's needed for a matrix multiply?
> Rick: Yes
> Waldemar: What data types can you use?
> Rick: This builds on the typed array work.
>
> Some desire for not having too many array times.  Can we unify
> ParallelArray with Array?
> DaveH: No. Holes alone cause too much of a semantic dissonance.
> Waldemar: Would like to unify ParallelArray with typed arrays.
> DaveH: No, because ParallelArrays can hold objects and typed arrays can't.
> Waldemar: Why not?
>
> Discussion back to knowing which kernels can be optimized.
> DaveH, MarkM: Nondeterministic performance degradation is preferable
> to nondenterministic refusal to run the code.  This leaves
> implementations space to grow.
> What about throwing exceptions only for functions that can never be
> optimized because they mutate state?
>
> Waldemar:  Is this optimized?  (Note that there are several different
> issues here.)
> let y = ...;
> function f(x) {return x+y;}
> a.map(f)
>
> Note that merely reading mutable state is not necessarily a cause for
> deoptimization because parallel functions don't run in parallel with
> other code, so that state stays fixed for the duration of the parallel
> operation.
>
> Allen: Concerned about every closure carrying along sufficient
> information to do the kind of abstract interpretation needed to
> optimize it as a ParallelArray kernel.
> Allen's issue summary:
> - Do we want to do this?
> - If so, how do we structure the activity (separate standard or part
> of ESnext or ESnextnext)?
> - Data parallelism or parallelism in general?
> Rick: Our goal is to get it into browsers.
> Debate about whether to do this for ES6 or ES7.
> Brendan, DaveH: Let's just do the work.  The browsers can ship it when
> it's ready, regardless of when the standard becomes official.  Need to
> get new features user-tested anyway.
> Structurally this will part of the mainline ECMAScript work
> (es-discuss + meetings), not in separate meetings as was done with
> internationalization.
>
> Allen's spec status.
>
> Olivier:  Concerns about latency issues related to module fetches
> blocking.  Multiple script tags can fetch their scripts concurrently;
> modules have latency problems such as:
> <script src=A.js>
> <script src=B.js>
> <script src=C.js>
> vs.
> <script src=C.js>
> where C.js is:
> module A at "A.js"
> module B at "B.js"
> // use A and B
>
> Alex:  Have modules block document.write.
>
> Long debate about asynchronous loading approaches.
>
> Olivier:  To get better latency, you can make your first module load
> simple, but after that you'll need to use the AMD syntax again.
> DaveH: Change the HTML semantics.
> Alex: Evaluate the outer module asynchronously in script blocks such
> as the one below, because there is no non-module code after the
> module:
> <script>
> module M {
>   module A at "A.js"
>   ...
> }
> </script>
>
> Olivier: This will error out if followed out by the otherwise correct:
> <script>
> M.foo();
> </script>
>
> DaveH proposal: Bifurcate grammar so that scripts (whether in <script>
> tags or in files included from those) cannot contain static module
> load statements, not even in syntactically nested modules.  Modules
> can include such statements but can only be parsed via dynamic loads.
> <script>
> System.load("interp.js", function(m) {...});
> </script>
>
> interp.js contains:
> module stack = "stack.js";
> export function evaluate(...) {...}
>
> stack.js contains:
> export class Stack {...}
>
> The body of an eval would be treated like a script body, not a module
> body.  This avoids the tarpit of dealing with synchronous i/o in eval.
>
>
> For-of design variants:
> Variant 1:
> import keys from "@iter"
> for let k of keys(o)
>
> Variant 2:
> for own (let k in o)
>
> Current way:
> Object.keys(o).forEach(function(...){...});
>
> Picked variant 1.
>
> DaveH: The people want Array.of and Array.from and don't want to wait
> for the ... syntax.
> Array.of(a, b, c) ≡ [a, b, c]
> Array.from(a) ≡ [... a]
>
> Brendan: Disallow initializer in:
> for (var i = x in o)
> MarkM: OK, as long as Brendan is the first penguin through the ice hole.
> Mozilla will take it out.
>
> Brendan's arrow proposal:
> ArrowFormalParams_opt -> Block_opt
> ArrowFormalParams_opt => AssignmentExpr
>
> ArrowFormalParams:
> (FPL)
> (this Initialiser_opt, FPL)  // Makes this dynamic
> (this Initialiser_opt)       // Makes this dynamic
> Identifier
>
> Brendan:  -> and => both use static this.
> DaveH:    -> defaults to dynamic this, => defaults to static this
> Debate about Tennent Correspondence Principle and to what extent this
> complies.
>
> ArrowFormalParams is actually parsed as the cover grammar:
> (CommaExpression)
> with later semantic restrictions on what the CommaExpression can
> actually contain.
>
> Waldemar:  A lot of problems that are individually nonfatal but too
> much in combination.
> 1. Two different arrows is confusing.  Will keep using the wrong one
> and get weird results.  Examples:
>   -> {a:b}  // intended to return an object literal, instead has a
> labeled expression
>   -> {}     // intended to return an empty object, instead returns
> undefined
>   => {}     // intended to return undefined, instead returns an empty
> object
> 2. Having both dynamic and static this options is overkill.
> 3. TCP hazards
> 4. Cover grammar introduces a lot of spec complexity.
> 5. Different 'this' defaults in DaveH's variant of the proposal
>
> Wild debate.
> Poll of who objects to which problem in the proposal:
> 1.  AWB, MM, AR, AR, LH, DC, WH, DH
> 2.  AWB, MM, AR, AR, LH, BE, DC, WH, DH
> 3.  AR, AR, LH, DC, BE
> 5.  AWB, MM, AR, AR, LH, BE, DC, WH, DH
>
> If we choose only one arrow, which is it?  Flow of debate assumed it's
> =>, with a do expression used to place statements there if needed.
> Luke, Waldemar:  Use only one arrow, but allow either a block or an
> expression there.  If it starts with a {, it's always a block.
> MarkM: What about => function foo(){}?
> No issue there; it's a function expression.  Only => { starts a statement.
>
> MarkM:  => assignment cannot be TCP due to yield.
> Debate over meaning of TCP.
>
> Some people have changed camps.  The ones above are from the original poll.
> Confusion about the meaning of poll polarity on item 3.
> New results:
> WH, AWB, MM:  object to 1, 2, 5; want TCP
> BE, DH, AR, AR, LH, OH:  object to 1, 2, 5; don't want TCP
> DC:  object to 2, 5; don't want TCP
>
> DC switched to middle camp.
> AWB, WH, MM prefer to keep TCP but are ok with switching to middle camp.
>
> Consensus on:
> - Have only one arrow, namely =>
> - this is always static.  No provision for dynamic this.
> - Other than the treatment of this, the function behaves like a normal
> function.  return, break, etc. behave as though the function body were
> in a function(...){...}.
>
> To be discussed later:
> The thing that comes after the arrow:
> 1. Always an expression (possibly a do expression)?
> 2. A block if it starts with {, otherwise an expression.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120329/29036858/attachment-0001.html>


More information about the es-discuss mailing list