- It has been suggested (I forget by whom, sorry) that sometimes this approach grabs info at the wrong level of abstraction, even for a plugin. As a case in point, I'll think about my `units` package, which implements a domain-specific type system for dimensional analysis. (I know this will be close to Adam's heart!) The errors generated by tiny misuses of this package are disastrous. But, figuring out what went wrong from an error message would still be hard, even as a plugin. Instead, it would be much better if extra checks were put in place during typechecking; if these checks fail, then the errors are easier to diagnose. I'm thinking, in particular of what's done in Helium, as presented at Haskell Implementors' Workshop 2014: http://foswiki.cs.uu.nl/foswiki/pub/Hage/ResearchTalks/hiw-helium.pdf I'm not familiar at all with Idris's approach here, but it would be interesting to compare and contrast the two to see what we can learn from others' experience.

On Feb 6, 2015, at 5:17 AM, Simon Peyton Jones <simonpj@microsoft.com> wrote:

I think this is very similar to what Idris supports for reflecting on errors: http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf

Aha! Yes, thank you for jogging my memory. I had a good conversation with David Christiansen about this at ICFP, about this very topic, and whether we could steal Idris’s clever ideas and put them in GHC.

· He subsequently wrote a blog post
· Incidentally, in case it’s not clear this thread on Haskell Café goes back to Nov 14. The first message in the series had more useful links

David’s idea is would have much broader scope than just TcErrors. Much of the infrastructure is in place already, since error message are SDocs (an abstract type, private to GHC), not strings.

Design work needed. Start a wiki page. Articulate a vision. Discuss alternatives.

Simon

From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Alejandro Serrano Mena
Sent: 06 February 2015 08:24
To: Adam Gundry
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Domain specific error messages

I think this is very similar to what Idris supports for reflecting on errors: http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf

2015-02-06 8:53 GMT+01:00 Adam Gundry <adam@well-typed.com>:
[Re-sending to haskell-cafe since I used the wrong From address...]

This is something that has been on my mind for a while, particularly
following discussions at the last ICFP and prompted by the work on
typechecker plugins in GHC [1]. I think I see a way to proceed, though I
don't know whether I will have time to implement it for a while. I'd be
interested to hear about other approaches.

Suppose we define an ADT representation of all the typechecker error
messages, e.g. something roughly like

data TcError = CustomError String
| CouldNotUnify Type Type
| NoClassInstance ...

In GHC all the relevant messages are generated in the
typechecker/TcErrors module, so this shouldn't be too hard to arrange.
Now we can extend plugins with the ability to supply a function

tcPluginAdjustErrors :: [TcError] -> TcPluginM [TcError]

and run the plugged-in function between generating and reporting the
errors. Thus a library defining a DSL could also provide a plugin to
supply more informative error messages.

This is a fairly quick-and-dirty approach, because the plugin would be
quite tightly coupled to GHC, even though it could be written and
distributed separately. But it might be one way of making progress. (It
also occurs to me that such an ADT might allow GHC to define a
machine-readable serialisable format for its error messages, to allow
post-processing by external programs.)

Adam

[1] https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker

On 05/02/15 09:54, Corentin Dupont wrote:
> Hi all,
> I have been very interested by this discussion when Alberto started it.
> As there been any progress?
> The problem is very acute in the Nomyx game I'm developing
> (www.nomyx.com <http://www.nomyx.com>).
> The game is based on a DSL, it's working well, but at the moment only
> expert Haskell developers can play...
> I think cryptic error messages is part of the problem.
> How to improve that?
> For example, a common error message is the following:
>
> Won't Compile
> <interactive>:5:28:
> Couldn't match type ‘'NoEffect’ with ‘'Effect’
> Expected type: Exp Effect ()
> Actual type: Exp NoEffect ()
> In the expression: e_1
> In the expression: (let e_1 = do { ... } in e_1) :: Exp Effect ()
>
> It's not so helpful and exposing Nomyx internals.
> A better error message would be to hint that the player forgot a "liftEffect" instruction.
>
> The only quick-and-dirty solution I see is to pattern-match for it and display an additional hint line...

--
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe