In NBL, I would like to use composite name in the namespaces. E.g. OpName("myoperator",2) where 2 is, say, the arity of the operator. Spoofax fails on URI processing. I tried to hack the problem, but it goes beyond my knowledge of URI processing.

I could model the problem as follows:

• Create a new sample project with the “entities” syntax.
• Change the syntax so that ID is replaced by TName(ID) for type names, and by PName(ID) for properties).

The modified syntax:

imports Common
exports

context-free start-symbols

  Start

context-free syntax

  "module" ID Definition*       -> Start {"Module"}
  "entity" TName "{" Property* "}" -> Definition {"Entity"}
  PName ":" Type                   -> Property {"Property"}
  ID                            -> PName {"PName"}
  TName                            -> Type {"Type"}
  ID                            -> TName {"TName"}

Last step:

• Disable or correct constraint-warning to avoid useless warnings.

You will get URI of the form [Entity,TName("URL"),"example"] that Spoofax cannot handle.

My objective is to process URIs like [Operator,Name_Arity("myoperator", 2),"somemodule"].

Note: the first error that you will encounter is a concat-string error in index-path-to-string. I corrected it so that I get nice URI strings, but name resolution still fails.

Submitted by Emmanuel Castro on 8 December 2012 at 13:47

Currently the index library expects the URI to only contain a namespace constructor and then a path which is a list of strings.
This is mainly for code completion to work correctly, since code completion needs to do string prefix matching on the URI to find out which identifiers to show.

The idea is that an URI does not contain any data about the definition, it should just be an identifier for it.
To store data about a definition you can define an adjust-index-def-data rule, see the documentation for that strategy in analysis-library.generated.str.
For example, to store the arity of a function definition you’d have a store rule like:

adjust-index-def-data(store-results|namespace, path):
  Function(_, parameters, _) -> <store-results> DefData([namespace|path], FunctionArity(), arity)
    where
      arity := <length> parameters

You can then retrieve the arity during error checking or compilation when you encounter a function call like this:

  FunctionCall(name, _) -> <index-get-data(|FunctionArity())> name

The name term in FunctionCall is an annotated name because it refers to a function, so it has the URI to the function definition as annotation.
If the function call is unresolved, index-get-data will fail because the data cannot be found.