bd82

9 ms·

1. 31.▲
   by bd82 9y ago

   This is a really great way to customize error messages and ensure all error messages have been customized (or at least handled). I think I'm going to try and implement this in a parsing library I develop. :)
2. 32.▲
   by bd82 9y ago

   Is this what you are referring to? https://github.com/alexwarth/ometa-js Is it still relevant if it has not been updated for several years? Perhaps Ometa's younger's brother (Ohm) should have been referenced
3. 33.▲
   by bd82 9y ago

   I also slightly dislike parser combinators. Mainly because usually you cannot easily debug them by placing a breakpoint. In the best case scenario the specific parser combinator has good tracing support to enable debugging. However, imho th
4. 34.▲
   by bd82 9y ago

   The article mentioned using Parser Combinators as the sweet spot between Hand Written Parsers and Parser Generators. Another possible sweet spot would using something I call a "Parsing DSL" which is a sort of a cross between a par
5. 35.▲
   by bd82 9y ago

   Some more information in this interview: https://jaxenter.com/theia-ide-efftinge-interview-134467.htm...
6. 36.▲
   Theia – One IDE for Desktop and Cloud(typefox.io)

   88 points by bd82 9y ago|58 comments
7. 37.▲
   by bd82 9y ago

   Makes it much easier to use in continuous integration scenarios. For example running tests in a browser in your pull request voter.
8. 38.▲
   Chrome 59 stable released(chromereleases.googleblog.com)

   136 points by bd82 9y ago|79 comments
9. 39.▲
   Show HN: JavaScript Parsing Libraries Benchmark(sap.github.io)

   3 points by bd82 9y ago|0 comments
10. 40.▲
    by bd82 10y ago

    Or you could take the middle ground and use a library meant to make it easier to create hand built parsers. as opposed to a library that generates a parser for you. * Repo: https://github.com/SAP/chevrotain * Onlin
11. 41.▲
    by bd82 10y ago

    > 2) ANTLR was not good for speculative parsing or probabilistic parsing which would be the basis of today's generation of tools such as "Intellisense" not giving up on parsing when there's an unclosed brace or missi
12. 42.▲
    by bd82 10y ago

    Thanks for the article. What about Error Recovery capabilities? I did not find any reference in the docs regarding that. Is it something you would want to add to FastParse? Do you think it is even possible without a separate scanning phase?
13. 43.▲
    by bd82 10y ago

    Is it possible to detect and warn about the left recursion? Assuming a data structure representing the grammar is built at runtime to be interpreted. Won't it be possible to detect the left recursion instead of going into an infinite l
14. 44.▲
    by bd82 11y ago

    There are a few small things that still require conversion. But that is because Typescript also includes capabilities from ES7 (ES2016). For example - currently in Typescript but only planned for ES7: https://github.com/jeff
15. 45.▲
    by bd82 11y ago

    Thanks for the compliment. I Still need to produce more examples (contributions are welcome :) ) There is one bigger (but incomplete example) of ECMAScript 5.1. https://github.com/SAP/chevrotain/blob/master&#x
16. 46.▲
    by bd82 11y ago

    Answer to BTW: But what about debugging and stepping through the grammar execution? I assume that in the case you are describing EVAL is performed on text generated "in memory". If you want to debug your code snippets (grammar ac
17. 47.▲
    by bd82 11y ago

    The use case of only handling valid input is a very common one, Particularly during compiler construction. But what about the use case of building an Editor (IDE) ? In this context it would highly beneficial to be able to handle invalid inp
18. 48.▲
    by bd82 11y ago

    There is nothing special about the parsing algorithm. It is currently a naive LL(1) (single token lookahead) Parser. I may try to upgrade it to LL(*) in the future. However that does not mean Chevrotain it limited to LL(1) grammars. You can
19. 49.▲
    by bd82 11y ago

    Thanks for the feedback. The Lexer and Parser both expose a collection of Errors. http://sap.github.io/chevrotain/documentation/0_5_19/classes... http://sap.github.io/chevrotain/documenta
20. 50.▲
    by bd82 11y ago

    Thanks for the feedback. :) There is no way to generate a "parser file". Because no source is ever generated (not even "in memory"). If you want to bundle with the rest of your application. Your grammar is just another j
21. 51.▲
    by bd82 11y ago

    Another major difference is that Chevrotain does not generate any code, it is a Parsing DSL not a Parser Generator. It is actually implemented with something very much like Macros, The Grammar’s implementation itself is parsed at runtime in
22. 52.▲
    by bd82 11y ago

    Hello. I am the author behind Chevrotain. I would say the two major functional advantages (as already mentioned in this thread) are Error Recovery and Performance. Error Recovery online playable demo can be found here: http://sap
23. 53.▲
    Show HN: Chevrotain – Fault-Tolerant JavaScript Parsing DSL(github.com)

    42 points by bd82 11y ago|16 comments