unisonweb
Variables that look like qualified names are confusing
Currently, due to the way names are resolved, it's possible to end up with variables whose names look qualified. For instance, the following is a valid definition (of the identity function):
id base.Text = base.Text
This works because we just parse the qualified-looking names as variables, and try to replace them with actual qualified references after the fact. But if there is no replacement, or perhaps always if the name occurs in a binding position, you just get a variable whose name is the entire . separated string.
Today I saw this trip someone up trying to do a type case. The definition was just accepted as valid, but gave an error message about redundant cases, because they ended up with two catch-all cases. It seems like you could also get into this situation if you misspell a qualified constructor name. Maybe the pattern checker would report something, but it might be confusing why you're getting the error you are.
So, perhaps we should do a post-pass to check for variables with names like these after name resolution, to disallow them and give a nicer error message. It seems unlikely that people want to actually use names like these.
Note: I think this is more of a problem with bound variables. Free occurrences of variables with qualified names like these probably get reported normally with an, "I don't know what this is," message. But variable bindings with names like theses are probably not what people actually want, and don't cause a comparable, "I don't know what constructor this is," error if they fail to resolve to something.
If we disallow . in bound variable names, then we will get round-trip failures. We could print existing . in variable names as _ and then not get a RT failure? However, we can wait for a complaint before worrying about the printer.
Note that in general, variables pre-substitution will have . in them, e.g. Optional.None.