Thanks for breaking this discussion out with a fresh subject line, or otherwise I would not have seen it. As an active GHC developer and budding academic, I thought I could share my views on this subject: Please please please let's do this! (This = come up with a way for better error messages in EDSLs.) I've never heard anyone say the lack of customizable error messages is an insignificant or unimportant problem. Nor am I familiar with any efforts to redirect or stymie such work. However, I completely agree that nothing is getting done. The problem I see here is a false underlying assumption: "If the community wants to do X, then X will get done." This assumption, on the surface, seems reasonable enough. However, it seems to apply most in a resource-rich community. For better or worse, Haskell/GHC today is not particularly resource-rich, in the resource that counts: developer-hours. As far as I know, there is precisely one person whose day job is to work on GHC (Austin Seipp). The rest of the work is "volunteer". I put "volunteer" in quotes because the rest of us get compensated in various ways for our contributions. My personal compensation (along with the happiness of contributing to an open-source project) is that working on GHC makes my research more relevant and more interesting. Because I work on GHC and can claim to have released my research, I estimate that it's more likely that my papers get accepted for publication. This creates a nice incentive for me to work on GHC. And I'm happy to do so -- it's also plenty of fun. But, there is very little incentive for me, personally, right now, to dive into the worthy cause of error message customization, because that topic is only loosely related to my primary research thrust, which is dependent types. I imagine that a similar incentive structure exists for other GHC contributors. And so, we wait for someone to come along and fix the problem. Going back to the original, false assumption: yes, I believe that the community wants error message customization, but currently no appropriately-motivated individual wants it and has the time to spend making it happen. So, to those of you who really want this feature: design and implement it! And, to those of you working for businesses that would benefit from this feature: incentivize (that is, pay) someone to design and implement it! I, for one, would welcome either development with open arms. Richard On Nov 23, 2014, at 1:01 PM, Alberto G. Corona wrote:

I Sean. I saw your message in the gmail spam shortly after sending my response. Knowing how the gmail spam detection works based on other's behaviours, maybe someone don´t like to read it ;))

If that is the case, less they would like to read my response in the mentioned thread:

Hi Sean,

I knew [1] in a discussion here about the same topic.

https://www.haskell.org/pipermail/haskell-cafe/2013-April/107799.html

As a consequence of that I created the ticket. I expected that the end of the research was some results applied to a major haskell compiler, specially GHC to really solve the problem. I know that this was the intention of the authors And they said so in the discussion.

But given the evident lack of interest of the Haskell community from the day one, specially the ones supposedly interested in the success of Haskell on industry and given the natural tendency of academic research to waste valuable efforts when there is no clear incentives by the industry, I suspect that the work will stay as such: research.

I suspect that the authors are as disappointed as me. It is so evident that this is THE problem of Haskell, the main barrier that precludes entering by storm in the industry in the form of hundred of EDSLs, and is so evident the lack of interest of anyone in the Haskell community that I can`t say more. That is why I mention this tangentially in this corner of the discussion group. This way many people can read this and pretend that they have not.

I know that computer science and science are driven by the same forces that drive everything else in human affairs. Academics well being is not challenged by niche and marginal industries that may drain some postdocs, but fear that the heavy IT industry would pollute their bucolic green pastures, well watered by state subsidies.

In the other side, I understand that niche industries are not interested in solving this issue, since they have their own haskell experts. But the reason why Microsoft or, in a lesser extent, FP complete does not push to solve the issue is beyond my understanding.

2014-11-23 0:01 GMT+01:00 Sean Seefried : If the list doesn't mind I'm reposting my reply to Alberto G. Corona in under the thread "Monads: external questions" as a new message since the topic has changed enough.

-------------

Hi Alberto,

I've been interested in domain specific error messages for years and I agree with you that it is one of the major things holding back the utility of DSLs to novice programmers. This is a shame since one of the touted benefits of DSLs is that they *can* be used by novices with a minimum of training, which is simply not true in the presence of error messages that require detailed knowledge of Haskell to understand.

I'd caution against saying that there is a lack of interest in that ticket you linked to. It's still a research level problem despite the fact that some great work has been done on it already. Incidentally, the author of "Scripting the Type Inference Process" went on to do an entire PhD on the topic entitled "Top Quality Type Error Messages"[2]. I recently wrote him an email and he told me that the constraint-based type inference framework that he used in the thesis, TOP, is available on Hackage [3].

Recently I noticed that this problem is already being worked on in Idris. See "Reflect on your Mistakes!" [4] and some code on GitHub [5].

Perhaps we can get people interested in this feature again?

Cheers,

Sean [1] http://www.open.ou.nl/bhr/heeren-scripting.pdf [2] http://www.open.ou.nl/bhr/TopQuality.pdf [3] https://hackage.haskell.org/package/Top [4] http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf [5] https://gist.github.com/david-christiansen/8349698

On Sun Nov 23 2014 at 3:57:10 AM Alberto G. Corona wrote: Michael:

You are right, but these are minor problems I think, compared with the huge potential advantages.

I can not believe it when a slow immature language like Ruby could take over web development just for one library, Rails and some buzzwords, when a faster, safer language can do it millions of times better. Haskell can revolutionize all the industry simply selling it not as one more language, but as THE meta-language for building EDSLs for each domain problem. some EDSLs so close to the domain problem that can be used by non-programmers.

That lack of vision and effort in the side of the haskell community hurts me. And the lack of interest in this ticket

https://ghc.haskell.org/trac/ghc/ticket/7870

Is a clear display of this lack of interest. it is like the Aristocracy of the Haskell Wondwerland fears to be hijacked by hordes of mediocre DSL villains from the industry, so it is necessary to keep the walls high

Haskell is a language dominated by academics that has no interest in the success of Haskell. On the contrary.

2014-10-29 15:13 GMT+01:00 Michael Jones : When I took a Lambda Calculus class years ago in Silicon Valley, 90% of the students groaned and complained. They just wanted to learn Java and make money. Having a background in OO design and experience with Eiffel, I was intrigued and stuck with it, building some tools with ML, and later Haskell.

In the workplace it was near impossible to avoid the .Net culture, and most of my code has been C#. But the factors that mattered were:

- Continuity with past languages and tools - Availability of programmers - Third party libraries - Inter langage operability - Reuse of legacy code

etc

Best I can tell, there is no way to avoid the business context. I suggest that if you have freedom, you need to be multilingual. Many systems could benefit from applying the proper tool to the corresponding problem.

But I will say this, becoming proficient at Haskell really improved my designs by providing an alternative conceptual framework. But, it had a very substantial learning curve. All I can say is trust that even if your core language is procedural, you will be better at that for learning a functional language.

To make Haskell a first class citizen in the IT shops, I think focus would have to shift more to the business context and needs. And certainly more focus in the universities that are still dominated by procedural languages. Once that is drilled into ones head, it affects the way one thinks.

To give an example, I have these problems:

- Update to GHC 7.8.3 from 7.6 caused run time behavior changes breaking USB application - Sandboxes are not completely isolated from the core library and often builds break - Most new grads don’t even know what a functional language is - Documentation gets out of sync with releases (where documentation means Wiki and web) - FFI is difficult to use and debug - Lack of books, user groups, etc

Mike

On Oct 29, 2014, at 3:48 AM, Alberto G. Corona wrote:

...

I know that I'm using a different language when talking about monads. The language of the IT industry.

Many haskellers use the language for toy programming. Others are professional academics. The few that use the language for commercial purposes are too busy developing practical applications rather than thinking deep about how to apply the haskell concepts to their problems. As a result many of such problems remains essentially unsolved. These busy developers try to transcode solutions from other languages that lack the deep and expressiveness of Haskell.

This lack of interest in one side and the lack of time in the other is disappointing. The symptoms are everywhere. Particularly, I find it in the lack of support and interests for this ticket:

https://ghc.haskell.org/trac/ghc/ticket/7870

I though that there was definitively a shift from "avoid success at all costs" a few years ago, for a commitment for the success, but still there are many minds to change, especially the brilliant ones.

2014-10-26 2:02 GMT+01:00 Alberto G. Corona :

2014-10-26 1:23 GMT+02:00 Jeffrey Brown : As opposed to the internal logic of monads, how they work, I hope to start a discussion about their external logic: how and why to use monads.

design ------ How do monads change the way one * thinks about a problem? * structures data? * refactors? * tests? Should I always be giving the monads a lot of cognitive bandwidth, because they reorder the way everything should be, or is it an investment with a high initial cognitive cost but requiring little maintenance thereafter?

what is their common framework? ------------------------------- Monads let data reach farther than it otherwise would. Subjectively, they feel like a controlled way of violating encapsulation.

Are there other, deeper or more specific, commonalities that explain why monads are a good way to implement exceptions, output, state, and perhaps other services?

I made monads for execution state recovery, web navigation.. workflows, long running transactions, backtracking, traceback and event chaining in web browser applications.

I´m confident that the perspectives for monads to solve real IT problems are very promising. And when I mean monad I mean all the associated stuff : applicative, alternative etc.

I´m confident that there will be a cloud monad (for chaining jobs and work distribution) an orchestration monad for orchestration of web services etc.

There are problems that are intrinsically procedural among them, almost all problems in IT. instead of using ad-hoc data/control structures like events, handlers, configurations, routes, exceptions, logs, transaction compensations, promises ....the list goes on and on , the monad is the common control structure that can subsume all of them inside his programmable semicolon

So, once the monad is set up, the user of the monad code the solution for the domain problem in a clean EDSL with absolutely no plumbing, at the level of the problem. so anyone that know the problem can understand the code.

Is the monad instance, and the applicative etc the ones that subsume under the hood the special data/control structure necessary for the domain problem.

Often if your code is general enough, it can be used in any monad. So you benefit from this. I think that in th future there will be a lot of surprises about the shareability of code between monads when the IT industry start to use them seriously. I think that we are just at the beginning.

I hope that some others of your questions are also answered here

-- Alberto.

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

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

Richard - did you think about some way of funding Haskell development? I think a lot of people are talking about low people-hours spend on GHC, but nobody ever told that a good solution here will be funding of its development. We've got so many options here - dotations, companies, vc's, community funding (maybe even kickstarter). You know, this would help MUCH Haskell and overall - everyone from this community. But in general - people are not working this way, that if somebody will tell - this is a good idea, everybody woudl do it. I'm writing exactly to you, because you are somebody very close to GHC and we all see, you "want" to do something good. Why not get funding for Haskell and GHC? I would love to help, really - as much as I can. But if everyone agree, we have to do something with it, as fast as possbile, othercase, Haskell will slowly die - taking in consideration how much moneyu is put in Scala, Go etc. These languages are getting better everyday - and of course, they've got another asusmptions than the best programming language I've been suing in my life, they have got many man-hours more spend on development than we do. What do you think? All the best, Wojciech Sun Nov 23 2014 at 8:42:29 PM użytkownik Artyom napisał:

On 11/23/2014 09:01 PM, Alberto G. Corona wrote:

It is so evident that this is THE problem of Haskell

Unfortunately, it’s not evident. Note that I’m /not/ saying it’s not “the” problem of Haskell; merely that

*

I consider myself to be somewhat intelligent

*

and – without having put much thought into this question – I don’t find it evident at all that the incomprehensibility of error messages arising when using DSLs is “probably the biggest barrier for the acceptance of Haskell on Industry”

Therefore, unless you’re sure for some reason that I’m an outlier and the majority of programmers /do/ find it evident but prefer to pretend they don’t (for pragmatic, evil, or other reasons), I would suggest writing an article attempting to persuade the community that it’s indeed a major problem – or, better yet, the problem which has the biggest utility/complexity-of-implementation ratio. I remember that what got me into Haskell was simply a handful of “mind-blowing” examples – an easily readable parser in a few lines of code, the elegance of |map| versus a |for| loop, things like that. A post with side-by-side comparisons of real-world GHC error messages arising when working with various DSLs (parsec, attoparsec, blaze, binary, diagrams, etc.) vs. mockups of improved error messages, alongside with a section describing the current research done in this direction and outlining general ideas/concepts, would probably do the trick.

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

On 24-11-2014 06:27, Alejandro Serrano Mena wrote:

At Utrecht University we are currently tackling this problem, in the form of the DOMain Specific Type Error Diagnosis (DOMSTED) Project [1]. So at least we have one person (me) working full-time on it, plus my supervisor Jurriaan Hage, which had already worked in a similar project for Haskell 98 which produced the Helium [2] compiler. We are slowly building step towards a nice way to create domain specific error messages, and we expect to have some nice results soon :) Of course, if you have any ideas on how to improve error messages, feel free to contact me :)

It would be nice if you could ping relevant issues (such as [1]) stating that you're researching on this topic. Cheers, [1] https://ghc.haskell.org/trac/ghc/ticket/7870 -- Felipe.

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). 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... On Mon, Nov 24, 2014 at 10:47 PM, Alberto G. Corona wrote:

That is fantastic news. Very nice to know that the project is alive and with aims to produce tangible results.

As Felipe said, please ping your advances there. To add some estimated dates would be fantastic.

2014-11-24 17:37 GMT+01:00 Felipe Lessa :

...

On 24-11-2014 06:27, Alejandro Serrano Mena wrote:

...

At Utrecht University we are currently tackling this problem, in the form of the DOMain Specific Type Error Diagnosis (DOMSTED) Project [1]. So at least we have one person (me) working full-time on it, plus my supervisor Jurriaan Hage, which had already worked in a similar project for Haskell 98 which produced the Helium [2] compiler. We are slowly building step towards a nice way to create domain specific error messages, and we expect to have some nice results soon :) Of course, if you have any ideas on how to improve error messages, feel free to contact me :)

It would be nice if you could ping relevant issues (such as [1]) stating that you're researching on this topic.

Cheers,

[1] https://ghc.haskell.org/trac/ghc/ticket/7870

-- Felipe.

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

-- Alberto.

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

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 :

[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

Two scattered thoughts on this issue: - I don't think snagging all of the errors from TcErrors is quite enough. For example, the errors generated in TcHsType might also be relevant, and maybe those in TcTyClsDecls. But, getting TcErrors would be 80% of the way, I think. - 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. In any case, I would very excited for forward progress to be made here! Richard On Feb 6, 2015, at 5:17 AM, Simon Peyton Jones 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 :

[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

On Fri, Feb 6, 2015 at 12:22 PM, Daniel Trstenjak < daniel.trstenjak@gmail.com> wrote:

Hi Richard,

...

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.

Yes, it also feels a bit too heuristically and if GHC changes, extensions get added or just activated, then the type errors might change and the heuristics break.

...

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.

Yes, this seems like a more stable approach.

Maybe a sort pre-compilation of the DSL, to catch the most common errors?

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

I think it would be a great improvement. However I'm wondering about the initial goal, that was making DSLs: the creator of a DSL is an Haskell expert (more or less), but not a GHC expert. So I'm wondering if the knowledge of TcError and all should be required... How would that work in general? I suppose the creator of a library would: - provide a nice DSL to interface with, - also provide instructions to the compiler for how to handle errors. Should this be done through a language pragma? Then the user of the DSL would simply create his program, compile and get the nice error messages. How to be sure that the modified error messages remain local to the DSL or to the library, and does not pollute all the rest of the compilation? On Fri, Feb 6, 2015 at 11:17 AM, Simon Peyton Jones 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 http://www.davidchristiansen.dk/2014/09/06/pretty-printing-idris/

· Incidentally, in case it’s not clear this thread on Haskell Café https://www.haskell.org/pipermail/haskell-cafe/2014-November/117054.html 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 :

[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

Yes, the centralisation of many type errors to TcErrors is a huge win. It would be massive task to turn *all* of GHC's errors into a data type, but the ones in TcErrors ought not to be too hard. Simon | -----Original Message----- | From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf | Of Adam Gundry | Sent: 06 February 2015 07:53 | To: Haskell Cafe | Subject: Re: [Haskell-cafe] Domain specific error messages | | [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