I’ve updated from s41636 to s41763. The issue reported at https://yellowgrass.org/issue/NaBL/113 is indeed resolved. After changing the names.nab file such that it is syntactically correct for the current version of NaBL the NaBL generator produces an empty names.str file.

The rule causing the problem was:

  SortFunCall(f, parent-ref, arg*):
  refers to SortFunction f in Sort parent
    where parent-ref has type SimpleSort(parent-ty)
    and parent-ty refers to Sort parent

And now is:

  SortFunCall(f, parent-ref, arg*):
  refers to SortFunction f in Sort parent
    where parent-ref has type SimpleSort(parent-ty)
    and parent-ty resolves to Sort parent

Removing the last line causes the names.str file to be populated. Adding it back causes the file to be empty.

Submitted by Vlad Vergu on 16 July 2014 at 09:03

Do you get a cannot pp trace on the console?

On a second thought, what do you want to express here? The original where x refers to NS y had two meanings:

1. x is a reference of namespace NS (according to some other NaBL rule) and you want to know to which y it was resolved or if it really referred to a definition of namespace NS.
2. x might or might not be a reference according to another rule. Independent of that, you want to figure out, where it would resolve to, if it were a reference of namespace NS.

In most rules, we find the first interpretation.

Regarding your 1st comment: No, nothing on the console.

Regarding your 2nd comment: The construct is basically a method call: parent-ref.f(arg*) except that the parent and the method are in an usual order. I’m interested in meaning 1 of the refers to, where i first need to resolve the scope which holds the method in order to resolve the method.

The intended meaning of resolves to is meaning 2, but I am wondering if this is already handled accordingly.

Does

SortFunCall(f, parent-ref, arg*):
  refers to SortFunction f in Sort parent
    where parent-ref has type SimpleSort(parent)

work for you? This used to be the pattern for qualified names. A refers to clause was only needed when either the bound variable (parent-ty in your case) was not the name itself, but contained it somehow, or when you wanted to check if it was actually resolved to a particular namespaces (Sort in your case).

Yes, this does work me. Thank you. What would you like to do with this YG issue?