When different namespaces share a common scope, which is extended with an anonymous scope, the namespaces do not longer share a common scope. This is typically unintended.

Consider the following NaBL rule from MiniC:

Program(_): scopes Function, Struct, Variable

Before the AST node is processed, the scope URIs for Function, Struct, and Variable are the same. Afterwards, they have three different anonymous scopes. This is problematic, because variables inside functions cannot refer to global variables anymore, because the surrounding functions are in a different scope than the global variables.

Submitted by Guido Wachsmuth on 14 November 2013 at 18:36

Has this been fixed yet? Or is there a workaround for this?
I think I might have this problem, here is the situation:

Consider the following (simplified) example:

act p;
proc p;

This gets parsed to Specification([ActionDecl("p"), ProcessDecl("p")]).
In my language each file is a single entity (i.e. no imports). The Specification therefore scopes Action and Process.
The NaBL rule: Specification(_) : scopes Action, Process generates 2 anonymous scopes (one for Action and one for Process).

Now I want an error when an Action has the same name as a Process, but <nabl-lookup-lexical(|ctx, NablNsProcess())> doesn’t work, as it looks for a Process in the anonymous scope of the Action.

To solve the problem I need to prevent the creation of multiple anonymous scopes, I currently do this like:

Specification(terms) :
    defines WHATEVER terms
    scopes Action, Process

But as the terms are not necessarily unique for each Specification I have no clue how this might affect the situation where there are 2 files with the exact same Specification.

What would be the recommended approach?

Volker: if Actions and Processes cannot have the same name, why not use a single namespace?

The main reason for that is that in some cases a reference is only allowed to refer to a Process. I figured there would be no way to make that distinction if Actions and Processes are the same Namespace.

But I guess I could just store whether it is a Process or not as an NaBL property. I think that would be the way to go then.

Thanks!