Closed byorgey closed 10 years ago
So I played around with code today trying to implement this, but it turns to be not as easy as I thought. It looks like GHC API does not distinguish between different kinds of errors and ultimately to implement this I'd have to parse the error messages. What about the previous idea you had (I haven't implemented it, argh!) - having a checkbox that says "bring to scope/import default set of modules"? It is checked by default and if user wants to use an identifier reserved by something from the standard set of libraries (diagrams, diagrams-svg, diagrams-contrib) then she would have to untick the box. Is it a reasonable replacement feature?
Yeah, parsing error messages doesn't sound like much fun. I think having a checkbox for a standard set of imports is a reasonable replacement. It would go a long way towards making it more easily usable out-of-the-box for new users.
Okay I've managed to implement this
The UI is a little bit ugly for my taste I want to replace the bootstrap tooltip by something else
Which modules do you think should be included by default?
Cool, looks good (other than the tooltip which I agree is a bit ugly, but it's not very important). As for what should be imported, off the top of my head: Diagrams.Prelude
, Diagrams.Backend.SVG
, Data.List
, Data.Maybe
, Data.Char
. No need to go too crazy. Normally I would say Data.Monoid
too but Diagrams.Prelude
already re-exports that. =)
Ha, that is almost exactly the list of the default modules I came up with :)
The necessary changes has been pushed and the site is updated
This feature suggestion is borne out of my experience making diagrams on the pastebin site, which often goes something like this: (1) write down diagrams code (2) hit "submit" (3) look at error messages (4) add missing import or LANGUAGE pragma (5) go back to (2), repeat several times.
This is frustrating, and I think some automation could go a long way towards making the process much more pleasant for new users. Here is how I imagine it could work:
FlexibleContexts
. If some code fails to type-check and one of the error messages says something like "perhaps you want to enable pragma XYZ", and pragma XYZ is on our list, that LANGUAGE pragma is automatically added to the top of the file, and the file is re-checked recursively.Diagrams.Prelude
,Diagrams.Backend.SVG
, etc.), with a pre-built mapping from identifiers to the module which exports them. If some code fails to type check with an error of the formnot in scope: foo
, andfoo
is a known identifier which is exported by moduleA.B.C
on our list (and no others), we automatically addimport A.B.C
to the top, and the file is re-checked recursively.At first I was thinking that we should not make any changes at all unless the changes allowed the file to typecheck successfully, but now I think we should go ahead and add pragmas and imports no matter what. The reason is that if a user's file has many errors we can automatically fix and only one that they have to fix themselves, we still ought to go ahead and fix what we can fix, making the user's task much easier---they only have to focus on the one thing they must fix themselves.