-
-
Notifications
You must be signed in to change notification settings - Fork 258
Conversation
This particular motivation seems to be making a lot of assumptions about performance with no data to back it up, I'd be quite surprised it it made that much of a difference. Since I don't want to shut this down outright, can you help me understand the usecase for parsing individual expressions explicitly, where there won't be statement-level syntax in place to allow parsing using the existing statement parser? I'm definitely hesitant on this, since expressions on their own don't really have a parser target in the JS language grammar, so parsing a standalone expression ends up needing more flags, e.g. is the snippet strict? is it a module or script? Can it have |
Pug has a syntax that could be exemplified by the following p #{expression} where expression is any JavaScript expression. We current use Acorn to check if expression is a valid one or not, and that is one of the biggest improvements of Pug v2 over Jade v1, but Babylon would provide support for next-generation JS, which is our long term goal. Not being able to prevent cases such as the ones listed in #210 (comment) from compiling would be a major no-no for us. (Of course, one can argue that we should introspect and walk the AST to see if expression actually is an Expression, but that seems way too complicated for such a task.) With regards to performance. Indeed, I would be surprised if direct access to Babylon internals ( I understand your hesitation, but having a function that parses expression is not without precedent. For one, Acorn provides a |
To clarify the given example
is converted to something like (simplified)
and this is why we need to parse the expressions directly. I admit that I invoked performance without a satisfying benchmark to back it up. A For what it's worth, i did a small benchmark on my machine
The result of several runs on simple expressions (we have many simple expressions to parse and more occasional complex expression) is roughly stable with a 40% gain in ops/sec for parseExpression. expr: "a = b"
expr: "a + b + c"
expr: !a
expr: a ? a : ""
correct parsing is another aspect as we saw that neither the "(expr)" nor the "expr=expr" trick leads to a correct parser because of edge cases like "a)(" or "=a" that get incorrectly parsed as expressions. I could add tests if you guide me as to what kind of tests would be needed. Thanks for your consideration. |
@jeromew's benchmarks seem pretty compelling to me. My main motivation for wanting this was to fix the hack of having to; add characters to wrap the expression, discount those characters from the line & column positions of the resulting AST, dig into the body of the resulting AST to find the actual expression, guard against corner cases like |
Is there anything I can do to improve my PR ? Here is the current summary of the pros/cons as I understand them. babylon has a Parser that allows direct parsing of expressions without parsing at the statement level (cf PR). pug (ex jade) is a templating language that mixes html and direct javascript expresssions that needs to parse a lot of expressions when templates are compiled (1) to ensure that the templates are correct (2) to give appropriate debug messages with line/col information (3) to directly build an AST tree version of the template. pros:
cons:
If this PR cannot be polished until it meets merging status, could we consider exporting the Parser or exporting enough entry points that Thanks for your time. |
Ok so I merged #240 and if you rebase you can create a second fixture runner for parseExpression. Right now both of the new functions are uncovered, so at least enough tests to cover all lines. (https://codecov.io/gh/babel/babylon/commit/e800d72acce6763ab7db5d1e837ddfd31687b890) Maybe some counter tests (as discussed above) to see that Sorry that it took so long. |
422f8d3
to
25286a5
Compare
@danez I squashed my PR, adding tests. Apparently codecov does not update its review. The tests are in the You will see I added a new Tell me what you think and if we agree on this. I will then add documentation on the README regarding the new option and Thanks |
Could you please rebase the commit on current master? The commit it is currently based on seems to be broken, that's why codecov is not updating. |
Current coverage is 97.27% (diff: 100%)@@ master #213 diff @@
==========================================
Files 21 21
Lines 3999 4004 +5
Methods 489 482 -7
Messages 0 0
Branches 1169 1179 +10
==========================================
+ Hits 3890 3895 +5
Misses 49 49
Partials 60 60
|
@danez I just rebased the PR. I think it wants to start its history on the first commit I did that was squashed and replaced. This is probably linked to https://github.com/codecov/support/issues/126 as the coverage page states "Commit was deleted by force push or pull request rebase." Do you want me to try and open another pull request ? I could create a new branch on my side with identical commits and send it as a PR forcing github + coverage to start a new thread. |
Can you elaborate more on the new option you added? From your comment it sounds that this is added because of performance reasons? Somehow throwing an exception, because it is slower doesn't make sense to me. |
@jeromew I don't think we should have denyLineComment in here. We should either implement that as part of The |
@danez, @ForbesLindesay you are right. I tried to fit the "deny comment" feature that |
@danez I removed the After further examination, I think that |
Any timeline for when this can be applied? |
This change implements a parseExpression public method that allows to parse a single Expression with performance in mind.
This method's objective is to replace the module
is-babylon-expression
that stopped working after the migration to rollup since it cannot have access to the parser and inherit from the Parser anymore.The ability to parse an expression with performance in mind is needed by the templating language jade/pug which allows raw expressions in the templates. I need to parse these expressions in order to assert the expressions and generate an AST tree.
I am looking for a way to replace the now broken
is-expression-babylon
that would be acceptable for the babylon project and I hope that this PR could maybe be accepted in the project.Do not hesitate to tell me and give me directions if there anything I can change to the PR (naming, convention, tests) in order for it to be merged.
Thank you