Having a minimal idea of how these work, how similar is this to antlr?
"It is also a build tool to compile the grammars into parsers" this line specifically caught my attention.
Nitra, JetBrains’ research project for language tooling, goes open-source
21–30 of 42 posts
Re: Nitra, JetBrains’ research project for language tooling, goes open-source
#22Kinda like Lex and Yacc and Bison Antlr Lemon LPEG Ragel re2c or any other tool on this list http://en.wikipedia.org/wiki/Comparison_of_parser_generators
Except, of course, for the areas where it's different as explained in the original post and their post last November:
http://blog.jetbrains.com/blog/2013/11/12/an-introduction-to...
Before dismissing someone's work you could at least skim a blog post.
Re: Nitra, JetBrains’ research project for language tooling, goes open-source
#23The article was written as though Emacs didn't exist.
Re: Nitra, JetBrains’ research project for language tooling, goes open-source
#24they also have MPS on the grammer less IDE/Language tooling...
Re: Nitra, JetBrains’ research project for language tooling, goes open-source
#25Having a minimal idea of how these work, how similar is this to antlr? "It is also a build tool to compile the grammars into parsers" this line specifically caught my attention.
The parsing part is similar conceptually and syntactically, but their implementation is very different. Antlr parses LL grammars - an unambiguous subset of context-free-grammars which are quite restrictive in the production rules they allow. This tool on the other hand uses PEGs, which parse a different (but overlapping) set of grammars, which aren't necessarily limited to CFGs, but are always guaranteed to be unambiguous. The main feature of PEGs that allows this is that the ordered choice operator (|) - the correct parse depends on the order you specify alternations, unlike with Antlr, where all alternations have equal precedence.
It should be noted though that this tool is much more than just a parser-generator - it's a framework for developing tools for interacting with languages, which just happens to use PEG as part of that implementation.
Re: Nitra, JetBrains’ research project for language tooling, goes open-source
#26Sounds a lot like parser combinators, without ever mentioning parser combinators.
Because they use PEGs, not parser-combinators.
Re: Nitra, JetBrains’ research project for language tooling, goes open-source
#27I would love to see some ReSharper-quality IntelliSense for Rust code in Visual Studio :)
Re: Nitra, JetBrains’ research project for language tooling, goes open-source
#28Earlier quoted context omitted.
It's written in Nemerle, that runs on top of CLR. I believe it's targeted to .NET, VisualStudio & Resharper audience.
I don't see how that is addressing my point. Emacs Lisp is the scripting language of Emacs, and you can use it to build AST to deal with syntax highlighting and autocompletions amongst other. And that's what Nitra is intended for, and it doesn't matter that it is written in Nemerle.
IntelliJ platform runs on top of JVM, Nitra runs on top of CLR.
Re: Nitra, JetBrains’ research project for language tooling, goes open-source
#29Earlier quoted context omitted.
The rest of JetBrain's products are cross platform, so there's a good chance that this will be in future.
We do have a lot of future plans for Nitra, but for now, it's worth pointing out that the products that are cross platform are Java based, while Nitra is based on .net. The project is currently Windows only.
Interesting, what made you decide on .NET (i.e. given you're predominantly JVM based)? Was it just based on the Nermerle's team preference?
Re: Nitra, JetBrains’ research project for language tooling, goes open-source
#30Can't wait to have a play with this (once I dig up my windows laptop...). I have such amazing respect for the amazing products from jetbrains; having toys to play with like this is just fantastic. I'm particularly interested in the component based grammars; I'd don't quite understand how you can get away with not breaking the 'parent' grammar when you drop an arbitrary child grammar inside of it, but quite looking fo…
This doesn't solve the problem of combining arbitrary grammars - there's obviously restrictions on what you can add where, or a requirement to add special delimiters around child grammars so that they can be parsed correctly, but Nemerle takes a practical approach to the problem. You still cannot nest arbitrary grammars inside others several layers deep - as each nested language requires consideration of its parents to get the parse you intended.
If you're interested in the problem of combining grammars, I'd encourage you to check out Diekmann & Tratt's Language Boxes (http://soft-dev.org/pubs/pdf/diekmann_tratt__parsing_compose...) [demo: http://www.youtube.com/watch?v=LMzrTb22Ot8], which provide an elegant solution to the problem, although with the obvious caveat that it diverges from plain-text file representation of code, and requires an intelligent editor like their example implementation, eco (https://bitbucket.org/softdevteam/eco).
Perhaps an interesting project would be to combine the two approaches, by having a language-box aware editor which could automatically insert the correct delimiters around language-boxes (inferred by usage), and produce plain-text representations which could still be understood by Nemerle/Nitra, which is language-box unaware.