When implementing scope please consider

• Dynamic scope
• 1st Class scope and scope environments (E.g. http://r-project.org/)

Editing nemerle/nitra code is gradually slowing down the VS - after a half day use. Closing and reopening the files does not help - only the full VS restart. Sometimes it even crashes the VS.

Doing it with our own grammar (a DSL created in Nitra) and put into NitraGlobalConfig.xml the performance is even worse.

https://github.com/JetBrains/Nitra

It would be good to have F* for language verification as it has effect system which is not present in the other languages chosen for verification.

Can you add C# Light like extention to the C# definition.

This is not a real language but a good idea:http://fsharpforfunandprofit.com/csharp-light/

Build instructions is incomplete and not fully described. Listed BuildBoot.cmd did not build everything what needed. So - it is completely missed any build automation.

General thoughts about build, after fighting with nitra build, and as result anyway i'm got build error. So i'm even can't report error, 'cause it is possible that there is something wrong in build.

There is exist common assumptions what are violated during by build and current instructions:

1. Do not require administrative privileges.
2. Do not change global state.
3. Provide correct integration to build dependencies (if them should be built).
4. Do not expose developer environment to build environment or production environment (i.e. do not assume that your developer workflow and configuration are good for others) - this is about magical environment variables, magical install locations. All of them should be collected or passed during build automation.

In facts:

1. Nemerle dependency is subject to be built because changes in nemerle happens as part of nitra development => provide nemerle build automation.
2. Reference dependencies by tags or commits. Yours nitra builds should not be becomes to be broken with (upstream) nemerle changes.
3. Nemerle itself tries to install itself on default install location, at least if it is built with DevBuildQuick-4*.cmd as listed in build instructions.

Visual Studio:
Visual studio integration is important part during development, and as goal of development, but it is completely not needed to build nitra and use nitra during build process of other software. So build VS integration should be optional (and for nemerle too).

pls vs 2017 support

This will be the ultimate test of usability. Also help define new versions using the old version.

Meta circular evaluation maybe the best feature to have.

For languages written in Nitra it might be best to distribute the libraries as AST / TST than ByteCode / CIL.

Great to see the Nitra repo in finally in GitHub.

Is it possible to add the license file to the project.

Disregard this issue. I guess SimpleSharp is my best bet to learning how to define syntax.

Is it possible to consider AST transformation and type inference formalised through rewriting / reduction systems.

Please rebase and squish your commits, it will be easier to follow and understand.

Thank you!

Just tried nitra from binary distribution (without installer). It is just not work as expected or documented and fails with error:

Nemerle command line compiler 'C:\Program Files (x86)\Nemerle\Net-4.0\ncc64.exe' not found.

This happens because runInAppropriateProcess follow NemerleBinPathRoot environment variable, and fallback to predefined value (program files).

Also, note, that it is not deal with default search path, as it is documented in Install.

From user perspective, it should choose ncc what are located near nitra.exe, and only if it is not exist - fallback to other choices (NemerleBinPathRoot, default install location, or may be let system to search path).

Recently I have noticed: https://github.com/rsdn/nitra. What is the purpose of 2 repos? Which one should you watch? Which is the most current?

del

This again is relevant for the back end phase.

When generating / targeting native code then memory access, pooling, memory models and management will become very important. Since .net is used to bootstrap this can easily be forgotten or get the back seat. E.g. if you are trying to implement C/C++/Rust like schematics on Nitra.

Also in GC languages you might need to consider the GC schematics. E.g. Reference counted, mark and sweep, other GC schemes and algorithms. Especially when you are looking to generate / target the code to native. If you targeting a VM of course you use what the VM provides.

So you might need to pay special attention to portability issues. One of the main concern being this.

When designing the back end generators, provide a way custom generate a VM using Graal and LLVM optimized for the language. With the above project it might now be feasible to have own VM generated along with just targeting existing VMs.

Is it possible to have macro support for Nitra definitions:

• AST for Nitra it self
  • Nitra AST and module
  • Nitra AST monadic manipulations and transformations to produce new AST
• Quasi Quotes for Nitra definitions
• GADT based construction of Nitra AST
• Extend all above features for Nitra defined languages

A good compiler generally give very useful error messages. So any implemented language should be able to do so when there is a syntax error.

Grammar:

syntax module Grammar
{
    extend token IgnoreToken
    {
    | [SpanClass(Comment), ExplicitSpaces] SingleLineComment;
    | [SpanClass(Comment), ExplicitSpaces] MultiLineComment;
    }

    [StartRule]
    syntax E = "E" "{" "}" !Any
    {
        Value() : int = 0;
    }
}

Test program:

module Program
{
  Main() : void
  {
      def source = SingleLineSourceSnapshot(
      <#
      E {}P {}
//#>);
      def eParseResult = Grammar.E.Parse(source);

    WriteLine("Hi!");
    _ = ReadLine();
  }
}

Note: Whitespaces and commets are significant, changing one symbol may cause successful parsing

I downloaded Nitra and am very anxious to start working with it. However, when I ran BuildBoot.cmd, I got a series of error messages similar to this:
Internal\ExtensibleRuleParseTreeConstructor.n(74,36,74,39): error : typing fail
s on accessing member Add in the ? type [C:\NitraBase\Nitra\Boot1\Nitra.Runtime\Boot.Nitra.Runtime.npro
j]

Also, I get this error when building in VS . . . The referenced assembly “C:\NitraBase\Nitra\Nitra.Runtime\bin\Debug\Nitra.Runtime.dll” was not found. If this assembly is produced by another one of your projects, please make sure to build that project before building this one. Nitra.TestsLauncher

What I'm wondering is, could I use Nitra to define grammars that have to do with a user dialog that is similar to an SQL query, in the sense that they would be prompted with the "next logical word suggestion" as well as suggesting a word once they type a letter.
For example, this would be the typical sentence that the user would type:
'Include' 'areas that are' '<=' '10 miles' from 'train stations' 'where' 'the road surfaces are paved'.
I would need the intellisense to prompt them with each section of the sentence that I have inside the ' marks.
Would I be able to accomplish that with Nitra?
Thanks,
Renee

This is a minor glitch only.. when using SpanClasses the coloring has two issues. Consider:
span class Keyword = ( ['a'..'z', '_']['a'..'z', '_', '-']+ ) - "disable";
syntax OptionalDisable = DM=(DisableKeyword sm)?;
[SpanClass(SpanWarning)]
syntax DisableKeyword = "disable";

We set SpanWarning to a different color and yellow background color. The purpose is to make the 'disable' keyword stand out.

Problem 1: we had to subtract the disable word from keywords, otherwise the SpanClass on the DisableKeyword will not be applied. This is a matter of taste, however it would be nice, if the explicit SpanWarning on the DisableKeyword syntax element would have priority compared to the generic Keyword one.

Problem 2: with the above setup the sm space after the disable will get highlighted to yellow.
e.g. disable scenario [XY] {... } will highlight the space between disable and scenario while the spanclass is only defined for DisableKeyword.

When designing a language a specification of the syntax and the language is very important. Can you add documentation feature through which you can extract the language specification / documentation.

Language for collecting data on AST. Add to AST the [dependent properties] language (analogue of attribute grammar). - done

Recently I've installed Nitra plugin for Visual Studio (v0.1.146.0), but it seems that it doesn't work properly with Visual Studio 2015. No Nitra project templates appear (I can see only Nemerle templates themselves), also after downloading existing Nitra project *.nitra files are not recognized (they appear as plain old text file in VS editor).

Hi,

It would be great if single parser DLL could easily be re-used across different platforms:

http://developer.xamarin.com/guides/cross-platform/application_fundamentals/pcl/introduction_to_portable_class_libraries

http://msdn.microsoft.com/en-us/library/gg597391(v=vs.110).aspx

Will PCL DLL be supported as an output target of Nitra or at least raw CS files that could be adjusted manually? There is no mention of target platform configuration on this page at the moment: http://confluence.jetbrains.com/display/Nitra/Using+nitra.exe

Thank you.

When defining the type systems for languages please make sure that it is comprehensive enough to model different type system including but not limited to Substructural Type System and Dependent Types.

Add a feature so you can reuse Antlr grammar definitions.

Can you guys considering moving the Wiki into Github itself.

Another area to consider is Staging support. This will have the IR and also parsing the IR if they are text.

I'm loving this project. I was able to start a new grammar that works fine in the Visualizer application, but I can't seem to get it to recognize my files in VS. The included .njson and .ncs grammars work fine.

I am running Nitra v0.1.1433.0 and have installed the extension in VS2013 update 4. Are there any known issues / workthroughs for editing new grammars in VS?

To keep portability in mind perhaps you guys can consider not to have .net types leaking into syntax definitions.

Once you have ability to target other backends this might be used to port nitra itself to other platforms. You can have platform specific types in Nemerle 2 (similar to Haxe) but best is to avoid it in Nitra.

This is a little bit howto question - was unsure where to post..

When designing a parameter list, is it possible to force the different types of list elements to appear only once? I mean:

syntax NamePar = "name" ":" Identifier;
syntax AuthorPar = "author" ":" UserIdentifier;
sytnax DescriptionPar = "description" ":" StringLiteral;
syntax MainDefVersion1 = Identifier "{" NamePar? AuthorPar? DescriptionPar "}";
syntax DefParts
{
  | Name  = NamePar 
  | Author = AuthorPar
  | Description = DescriptionPar
}
syntax MainDefVersion2 = Identifier "{" (DefParts; "," )* "}";

So under MainDef I would like to accept the NamePar, AuthorPar, DescriptionPar in any order but max only once. MainDef1 is almost ok, but enforces order, MainDefVersion2 works without order but accepts any number of parts, and also accepts the same one multiple times. (Currently we use the 2nd with postprocessing..)

Was thinking to just enter all permutations, but I have 15+ different of these params, so that's a no go..

The problem is somewhat similar to C# constructor initialization where you can give each property only once. e.g.

var exampleInstance = new MainDef { 
  Name = "Friends", 
  Author ="Chandler M.", 
  Description = "Bing!" ,
// can't write here Name again
}

Thank you
Adam

Nitra can benefit from a template language. This can be used to apply a template for pretty printing as well as doing the reverse. Run the output from applying the template though a specific parser reconstruct the original. Keeping it generic will be better in the long run than having a specific HTML pretty printer.

NITRAPATH with path terminated with \ , but VS Nitra is looking after NitraPath env variable without \ terminator.

If there are some gotchas, please update the documentation.

With a view to better support VM based languages (#14) it would be good to have an AST interpreter at some later stage. Since JVM already has once (Graal / Truffle) this can be used in this case.