Any discussion on maximal minimal classes? Just curious of the status. - Russ
On Wed, Mar 28, 2012 at 8:42 PM, Waldemar Horwat <[email protected]>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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
