search

techfort / skrymir

LokiJS v2.0 experimental repository
MIT License
3 stars 0 forks source link

Contribution Policy #7

Open techfort opened 9 years ago

techfort commented 9 years ago

Proposed language spec:

Frameworks:

Code style: https://github.com/airbnb/javascript

Feel free to add.

techfort commented 9 years ago

Regarding Babel, how optimized is the generated code?

seriousme commented 9 years ago

The question is not: how optimized is the code, but how optimizable :-) My answer: no idea ;-) However we can expect that pretty soon all engines will have native support for the mainstream ES6 stuff. So e.g. if people are trying to wrestle the last cycle out of their Loki install they better use iojs 1.7 than node 0.6..

techfort commented 9 years ago

Sure, I suppose it'll be while before Loki 2.0 is out anyway. A lot may change.

On Tue, Mar 31, 2015 at 8:54 PM, seriousme notifications@github.com wrote:

The question is not: how optimized is the code, but how optimizable :-) My answer: no idea ;-) However we can expect that pretty soon all engines will have native support for the mainstream ES6 stuff. So e.g. if people are trying to wrestle the last cycle out of their Loki install they better use iojs 1.7 than node 0.6..

— Reply to this email directly or view it on GitHub https://github.com/techfort/skrymir/issues/7#issuecomment-88226530.

seriousme commented 9 years ago

Darn, wish we could use ES6 Comprehensions as that would enable 

var results = [
  for(c of customers)
    if (c.city == "Seattle")
      { name: c.name, age: c.age }
]

which would be a quite powerful way to define a query :-) (to see it in action check out this)

Hard part of course being able to apply index lookups to preselect the candidates for the result set. (one would need to parse the AST of the query to figure out what props are being matched) Would be really cool (but out of my league ;-)) to make this work :-)

techfort commented 9 years ago

Yeah list comprehensions are one of the things i love about python. Having said that, it looks to me that for the moment it's more syntactic sugar than performance improvements. Unless this is something that at some point involves TCO in which case it will perform much better when ES6 is stable.