Annotations cannot be referred to using their fully qualified name?

[tedinski]

In #59, we discovered that annotation parameters cannot be referred to using their full name, only their short name.

I suspect this is exclusive to the function application syntax, i.e. fun(arg, anno=val). I think the access syntax (var.anno) works fine, though that should be tested too.

I haven't investigated the problem yet.

(When this bug is fixed, we should fix the hack in #59 as well.)

[tedinski]

Stream of consciousness incoming. Root cause of this bug is here:

https://github.com/melt-umn/silver/blob/develop/grammars/silver/definition/env/NamedSignature.sv#L67

evidently, after using full names for the annotation everywhere else, we suddenly only use a shortname when we convert to a type. This isn't right.

But of course, the lookup code is then expecting only shortnames. So that part needs fixing too. But this is surprisingly tricky!

The trouble is:

1. We don't want to resolve to a fullname by looking up the annotation name, because in the future we might want "named parameters" that aren't annotations.
2. There might be name collisions.

So e.g. we might have a list of occurrences like ["core:location", "example:a", "other:a", "a"]. So if we explicitly write core:location that behavior should be obvious. But we should also successfully find location. But with a with have two problems: if that last element wasn't there, it'd be ambiguous. With it there, there's no way to actually supply just a because the lookup logic should also match the others and report ambiguity? However, perhaps this is fine because we could raise an error when declaring a function with overlapping names?

But that raises the question: if we're raising errors for duplicates, why not about annotations, too? Perhaps the solution to this problem is to decide "actually, we just use short names for annotations/named args."

In which case, probably only shortnames should appear in the NamedSignature too? So SOMETHING ought to change here...