| 1) Hugs's error messages don't qualify names, so they become
| very difficult to read when you use this convention.
| ...
| ... #1 is the least important in theory, since it's fixable and
| implementation-dependent, but turned out for me to be the most
| important in practice; Hugs' atrocious behavior on this score has
| caused me to disregard my own better judgement here for serious
| projects.
Despite the way that many people use it, and even with all the
changes that have been made to it, Hugs simply wasn't designed
for "serious projects". It was intended for small projects,
and as a tool for education and research. Using qualified names
in error messages can make things unnecessarily harder to read
in such contexts like that. As an expert user working on large
projects, your perspective is different. But I don't think the
design choices are as clear cut as you suggest.
Hugs is also quite old; it's core goes back nearly ten years!
With a more "modern" interface, we might solve the interface
dilemma by arranging for fully qualified names, types, etc. to
pop up in a "tooltip" when the user mouses over an identifier
in an error message. Perhaps other people can suggest more
modest proposals for making intelligent choice of qualifying
prefixes that would fit in more directly with the existing
framework.
A final comment: don't forget that you have full access to the
source code for Hugs, and hence the opportunity not just to
identify weaknesses, but also to fix them, and to share the
results so that everyone benefits! The same goes for all of
our Haskell systems, not just Hugs. There just aren't enough
developers to get the job done on their own. I'm convinced
that the only way we will ever have truly excellent tools is
by working on them together as a community.
All the best,
Mark
