nabl-uri does not work on names annotated with a use, because this has a result in it. As a consequence, nabl-get-property also does not work on use-sites.

Submitted by Guido Wachsmuth on 30 June 2013 at 15:05

Because a Use does not contain a URI. If you want the URI of a def use nabl-collect-one-resolved-def to resolve the Use to a Def, and then call nabl-uri on that. However, I could change nabl-uri to do this automatically, but it might be a bit weird since a Use can point to multiple Defs and nabl-uri should only return one URI.

I see your point. I was assuming old behaviour here, probably because of a nabl-uri rule for Use.

The underlying question here is how to access index information during compilation. For definitions, nabl-get-property does the job, for use-sites you suggest nabl-collect-resolved-def; nabl-get-property?

What do you think about nabl-get-property which works also on uses, when there is exactly one property value (even for possibly multiple Defs) and nabl-get-properties for all property values at a use site?

I think in that case nabl-uri should just resolve the Def for you, nabl-get-property/nabl-get-properties use nabl-uri internally so it will work on uses after that change. A nabl-uris could be added in case you want all the URIs.

I like the approach with nabl-uri and nabl-uris, which work on defs and uses, and nabl-get-property and nabl-get-properties which rely on these. Can you implement this, @Gabrïel?

Sure

Added in https://github.com/metaborg/runtime-libraries/commit/7808d31490dabc34873a9b4193e3c01ac2bd62c4

This stopped working in the current nightly. get-type and friends fail, because nabl-uris fails on names annotated with uses.

It didn’t stop working in nightly, the call to index-setup was passing the language name instead of the project-path, creating a new task engine and making any task insertion fail.