An Introduction to Nitra

  • This gets us ever closer to the goals of the elusive (and presumably abandoned?) Grok project [1].

    I'd love to see syntax highlighters (like Pygments), editors and IDEs, autocompletion providers, debuggers, and all other language-related tooling consume a standardized canonical "language description format". Making a new language? Bam! It's automatically supported by Visual Studio, Eclipse, Emacs, vim, Sublime Text, gdb, Pygments, the list goes on.

    The extension capabilities are also awesome. Let's say I have a huge project and, at a certain level of abstraction, users aren't allowed to use fprintf(stderr, ...), they need to use LOG(...). It would be great to have a file in your project that can tell your environment to give you the "red squigglies" and autofix information for such situations.

    http://bsumm.net/2012/08/11/steve-yegge-and-grok.html

  • Looks very similar to OMeta (http://tinlizzie.org/ometa/)

  • I hope some of the work they've done filters back into Nemerle. A lot of people were very excited when JetBrains picked up the Nemerle team but it's not clear that they have any intention of supporting the project - they just wanted the team...

  • I've been waiting for this for a year; the idea of having a language-within-a-language is extremely powerful.

    Take our product: we have javascript, typescript, XML and SQL stored in strings in our C# codebase. As you can expect, these are really hard to maintain, and just has hard to move to separate templates.

    Oh, did I mention that we also have our own templates, our own DSL, handlbar templates, jQuery templates and templates used in various libraries.

    Nitra can support that all in one tool.

  • Am I being too simplistic when I think the following holds?

    Easier to make a DSL => Wider adoption of new languages => Better grounds for experimentations => Much more creative stuff => More accessible technology

  • This is so awesome! I hope the resulting assemblies will be PCL though.