Use the unqualified name unless there is ambiguity.
More precisely, if the context module is M:
- If the entity is not visible in M, then use the qualified name.
- If the entity is visible in M and there is another module in which an entity in the same namespace exists with the same name, and this other entity is defined and visible in M, then use a qualified name with a minimally qualified module name (e.g. Prelude.id, rather than Cal.Core.Prelude.id).
Note: a type class name and a type constructor name live in different namespaces so they will never be ambiguous by the criterion of this class even if they have the same names.
Note also that this is not quite the same rule that is used when resolving names in CAL source. For example, if you are working in module Foo and define a sin function there, then you can refer to Foo.sin as sin, since Foo's sin will mask Prelude.sin. This is because dependent modules should not break when new public functions are introduced. However, from the point of view of this naming policy, Foo.sin would be displayed fully qualified, since this appears to be less confusing from the point of view of UI clients.
@author Bo Ilic