Max Bolingbroke wrote:

Agreed: I've implemented this too. I've also added fuzzy matching to package search:

""" $ stage2/ghc-inplace --make ../Test1.hs

../Test1.hs:3:7: Could not find module `Data.Lost': Use -v to see a list of the files searched for. Maybe you meant `Data.List'

$ stage2/ghc-inplace --make ../Test2.hs [1 of 1] Compiling Main ( ../Test2.hs, ../Test2.o )

../Test2.hs:7:14: Not in scope: `isSpace' Maybe you meant `Char.isSpace' """

In terms of making error messages more helpful, I don't find general typos are much of an issue, but this part would be really nice! I've always been annoyed that GHC just says "no" rather than offering suggestions (-v is rarely helpful), especially since it knows about what modules are installed et al. Granted it's still an easy class of bugs to fix, but this is a much friendlier way of fixing them. -- Live well, ~wren

2008/7/13 Isaac Dupree :

wren ng thornton wrote:

...

In terms of making error messages more helpful, I don't find general typos are much of an issue, but this part would be really nice! I've always been annoyed that GHC just says "no" rather than offering suggestions (-v is rarely helpful), especially since it knows about what modules are installed et al.

It sounds like it only searches for modules you've imported (after all they might've been brought into scope with an as-clause, and ghc has no business poking in un-imported modules), but perhaps since in GHCi all modules are in scope (under their original names -- in addition to any imports in an interpreted file), it (ghci) searches all modules then?

You're right: if there is no qualified import of Char then it won't suggest Char.isSpace. The reason for this is that doing so would require GHC to load all the interface files for all exposed modules on disk in order to search exported names, which doesn't sound like a great idea performance-wise. The same thing applies to GHCi.

If I want a "perhaps you meant to import" message, I want it to be a *complete* listing of modules available that export that symbol, both local ones and library ones, ideally :-) (certainly don't want a recommendation to import e.g. List without at least an equal recommendation of Data.List...)

I agree this feature would be cool, I'm just not sure the possible memory/performance problems associated with loading all interfaces of all exposed modules in all packages (it would be most helpful but even more of a performance problem to even scan non-exposed packages) would be worth it. Probably it could be made practical by building a sort of index, which is cached on disk.. Max

2008/7/13 Claus Reinke :

That is the approach the haskellmode plugins for Vim take: build an index of Haddocumented identifiers once per installation, build an index of import-available identifiers once per :make.

The latter turns out to be a performance issue for large libraries, such as Gtk2hs, so some users had to switch it off, updating less frequently, the former doesn't seem to cause any problems.

Interesting. GHC would probably want to do something a bit smarter than an index at /installation/ time as the package environment is dynamic: 1. Create the index upon the first error message that needs it 2. On all subsequent error messages, update the index by rescanning packages whose versions have changed or have been newly installed 3. Cache this index on disk in some quick-to-read binary format This wouldn't actually be too hard, but is probably more effort than I'm willing to put in for an experimental weekend project!

Then again, we don't do fuzzy matching, only completion of partial identifiers and suggesting possible qualified names and imports for unqualified ones.

Agreed: doing fuzzy matching on >every< available identifier from all packages would truly suck. I would propose just looking for exact matches in non-imported modules for identifiers that are not in scope.

Completion alone can result in many matches, I'd expect fuzzy matching to be worse, and while edit distance is a useful criterion for well-chosen examples, I'd have to agree with those who have their doubts about its use in this context (but then, those who don't need a feature shouldn't stand in the way of those who do;-).

Well, noone has actually said they think fuzzy matching would be useful yet, so I suspect this patch is dead on the vine :). I've filed a ticket with the code anyway (http://hackage.haskell.org/trac/ghc/ticket/2442) so at least it's available for others to look at.

Things have levelled off since then, but there are still cases were longish fuzzy messages are provided by GHC when brief harsh messages would be more to the point - which wouldn't be a problem if the longer friendlier messages at least provided all the details of the short unfriendly ones, which isn't always the case. See, eg, #1928, #2360, #956, #589, #451, ..

...

It is an ongoing process, and balance is as important as perceived friendlyness, and lots of "friendly" suggestions without concrete, specific and useful help may result in a very unfriendly effect (think telephone/email support..).

These are interesting comments and tickets: thanks! I don't know where this kind of unbound-name suggestion we've talked about here fits in the spectrum of useful<->overwhelming, but I would like to think it's more towards the left end. It's easy to see why opinions would differ though. Cheers, Max

Don't be discouraged; I think it would be useful. IMO, Haskellers tend to be pretty insensitive when it comes to usability.

For example, before the GHC devs were asked for that feature, I wonder whether anyone ever thought: "Hey, when ghc -Wall complains about having no type signature - why doesn't it print out the inferred type signature? That would be helpful and convenient."

I don't think it's because there's any sort of gung-ho elitism there, it's just not something anyone but the educators like the Helium folk really think about much.

I've been thinking about stuff like this as well. It happens to me as well that I spend minutes on finding an error till I notice that I've misspelled a word.. but this has been while programming PHP. In haskell this kind of error tends to take much less time IMHO. There is a "friendlier" shell (don't remember it's name) which takes another approach: Change color if the word is known.. In case of ghci the commandline could switch color to green before pressing enter to indicate there are no errors left.. Marc

On 2008 Jul 13, at 9:36, Max Bolingbroke wrote:

2008/7/13 Claus Reinke :

...

Then again, we don't do fuzzy matching, only completion of partial identifiers and suggesting possible qualified names and imports for unqualified ones.

Agreed: doing fuzzy matching on >every< available identifier from all packages would truly suck. I would propose just looking for exact matches in non-imported modules for identifiers that are not in scope.

I would fuzzy match on unqualified names in the current module (or directory), qualified names in the module in question, and if that doesn't exist (== have a .hi) then try fuzzy-matching the module name. If the unqualified fuzzy match doesn't work, look for exact matches in non-imported modules.

Well, noone has actually said they think fuzzy matching would be useful yet, so I suspect this patch is dead on the vine :). I've filed

Huh? Edit distance is a good way to handle typoes --- and, while some people have asserted that "we don't need that because I can see it already", most people *don't* see it right away. (I do tend to spot typoes quickly --- in prose. It's nowhere near as accurate for code, and even when it does work it isn't exact: I'll have a "something's wrong" about some spot in the code and still take an hour to spot the typo.) I'm also *really* good at typoes, which you won't see in email but will see regularly in #haskell. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 13 jul 2008, at 15:36, Max Bolingbroke wrote: [snip, patches towards friendlier error messages in GHC]

...

Then again, we don't do fuzzy matching, only completion of partial identifiers and suggesting possible qualified names and imports for unqualified ones.

Agreed: doing fuzzy matching on >every< available identifier from all packages would truly suck. I would propose just looking for exact matches in non-imported modules for identifiers that are not in scope.

The approach taken by Helium (which doesn't quite do full Haskell''98 yet) is to not just do fuzzy matching, but to figure out if the identifiers that were fuzzily matched also have the right type. For more info, read Bastiaan Heeren's PhD Thesis: Top Quality Type Error Messages. available at http://people.cs.uu.nl/bastiaan/phdthesis/

Well, noone has actually said they think fuzzy matching would be useful yet, so I suspect this patch is dead on the vine :). I've filed a ticket with the code anyway (http://hackage.haskell.org/trac/ghc/ticket/2442) so at least it's available for others to look at.

More help is very much useful. However, there are different use cases that imply different types of help and diffent types of searching. With kind regards, Arthur van Leeuwen. -- /\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching