Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A better future for comprehensions

2e36436c692b2e5fbc172e9fb7563171?s=47 dherman
June 05, 2014

A better future for comprehensions

My presentation to TC39 on deferring comprehensions to post-ES6 in order to simplify and generalize the feature, based on recent input from Jafar Husain.



June 05, 2014


  1. A better future for comprehensions Dave Herman

  2. [for  (x  of  y)  if  (p(x))  f(x)]   (for  (x

     of  y)  if  (p(x))  f(x))
  3. • Parallel JS is moving in the direction of parallel

    pipelines – a natural fit for comprehensions. • Three strikes and you refactor! • LINQ: one comprehension syntax, unbounded number of (user-definable) traversable datatypes.
  4. let  a  =  for  (x  of  a1)      

                   for  (y  of  a2)                          if  (y  >  x)                              {  x,  y  };
  5. let  i  =  for  (x  of  map1.keys())      

                   for  (y  of  map2.keys())                          if  (y  >  x)                              {  x,  y  };
  6. let  p  =  for  (x  of  a1.parallel())      

                   for  (y  of  a2.parallel())                          if  (y  >  x)                              {  x,  y  };
  7. • The LINQ idea (which is actually the Haskell idea):

    comprehensions desugar into generic combinators. • Any datatype that supports those combinators automatically gets to play along.
  8. • Defer comprehensions from ES6. • Jafar and I will

    present an ES7 proposal for generalized comprehensions.
  9. Generator Iterator .prototype .prototype [[Prototype]] generator [[Prototype]] [[Prototype]] ??

  10. Iterator.prototype.      zip      filter      map

  11. table.keys().map(...)                  

           .filter(...)   ! //  versus   ! import  {  map,  filter  }  from  "itertools";   filter(map(table.keys(),  ...),  ...);
  12. (new  Iterator({      next()  {  ...  }   })).map(...)

  13. 5 Jun 14 Resolutions

  14. • Agree to defer comprehensions. • No future-proofing placeholder objects

    (can be added later with low compatibility risk). • May not generalize generator comprehensions since first RHS eagerly evaluated; more work to do.