Child pages
  • Node type generation

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

While building parser assembly, we need to generate types for AST nodes. These type should have some organization making it easy to use them from different CLR languages.

Each syntax is identified by it's QSN (qualified syntax name), which include namespace, module(s) and syntax(es) on the way to syntax.

Code Block
syntax module JetBrains.Languages.Java // module Java in namespace JetBrains.Languages
{
 syntax TypeDeclaration // QSN is JetBrains.Languages.Java.TypeDeclaration
 {
   syntax Modifiers // QSN is JetBrains.Languages.Java.TypeDeclaration.Modifiers
   { ... }
 }
}

We have to generate types for Java module, TypeDeclaration and Modifiers syntaxes. Hence, we are talking about mapping QSN to CLR type FQN.

Namespaces

For each name part of QSN except last generate namespace, last name part is type name. E.g. Modifiers type in JetBrains.Languages.Java.TypeDeclaration namespace.

Pros:

  • Simple and easy to compose
    Cons:
  • Namespaces will collide with type names, e.g. for TypeDeclaration, and C# doesn't like this.

Nested types

Namespace maps to namespace, modules and syntaxes are mapped to types, nested within each other

Code Block
namespace JetBrains.Languages
{
 class Java
 {
   class TypeDeclaration
   {
     class Modifiers {}
   }
 }
}

Pros:

  • Cons:
  • You can't add "using" for type in C# and user have to specify full nested type name all the time

Problems

  • Too many types slows down assembly loading
  • Name ambiguity problem:
    Code Block
    syntax module A 
    {
      syntax Foo
      {
      }
    }
    
    syntax module B 
    {
      syntax Foo
      {
      }
    }
    
    syntax module C
    {
      extend syntax A.Foo
      {
        | Identifier
      }
    
      extend syntax B.Foo
      {
        | Identifier
      }
    }