Haskell compilation errors break the complexity encapsulation on DSLs

older
Packages in distro mentioned on...

Alberto G. Corona

23 Apr 2013 23 Apr '13

6:49 a.m.

Hi I ever was worried about the barrier that the complexity of the Haskell errors impose to users of DSLs. Many DSLs look so simple that even someone without knowledge of Haskell can make use of them for some domains. However when the program is compiled then al the monsters of the deep appear in the surface: polymorphisms, undefined instances, type errors reported in a line produced by a type assumption in another, etc. This is a problem for an industrial use of Haskell in the large scale. For obvious reasons. I would like to know 1) which techniques are used to minimize the problem 2) To suggest some kind of extension that would allow for example to add extra information to the error messages by the library developer.. For example, in http://hackage.haskell.org/packages/archive/control-monad-exception/0.10.3.1... There is a nice documentation about two kind of errors that are frequent when using that library: *A type error of the form: * * No instance for (UncaughtException MyException) arising from a use of `g' at examples/docatch.hs:21:32-35 Possible fix: add an instance declaration for (UncaughtException MyException) In the expression: g ()* *is the type checker saying: * *"hey, you are trying to run a computation which throws a MyExceptionwithout handling it, and I won't let you" * *Either handle it or declare MyException as an UncaughtExceptionhttp://hackage.haskell.org/packages/archive/control-monad-exception/0.10.3.1.... * The question: Is it possible to develop a GHC extension that attach (or prepend) such an explanation to the ghc error? Or any other alternative that carry out the same functionality. -- Alberto.

Attachments:

attachment.html (text/html — 2.3 KB)

Show replies by date

Brent Yorgey

23 Apr 23 Apr

12:06 p.m.

New subject: Haskell compilation errors break the complexity encapsulation on DSLs

On Tue, Apr 23, 2013 at 12:49:59PM +0200, Alberto G. Corona wrote:

...

Hi

I ever was worried about the barrier that the complexity of the Haskell errors impose to users of DSLs. Many DSLs look so simple that even someone without knowledge of Haskell can make use of them for some domains.

However when the program is compiled then al the monsters of the deep appear in the surface: polymorphisms, undefined instances, type errors reported in a line produced by a type assumption in another, etc. This is a problem for an industrial use of Haskell in the large scale. For obvious reasons.

Indeed. For example, in my experience this is a big problem for diagrams.

...

The question: Is it possible to develop a GHC extension that attach (or prepend) such an explanation to the ghc error?

Or any other alternative that carry out the same functionality.

Surely it is possible. I have wanted this too. I guess the majority of the work would just be in coming up with a good, general design which is useful but not too difficult to implement. If anyone wanted to undertake such a project I would be happy to contribute some ideas. -Brent

Alberto G. Corona

24 Apr 24 Apr

11:28 a.m.

New subject: Haskell compilation errors break the complexity encapsulation on DSLs

Maybe it is possible to do something In a google summer of code. Nothing as sophisticated as the Helium paper ("Scripting the Type Inference Process", but maybe a partial implementation of the techniques mentioned, so that the development can be enhanced in the future. Maybe some kind of library that permits postprocessing of GHC errors and/or the identification of points in the current type checker where some kind of rules can be defined by the programmer can be the first step. 2013/4/23 Brent Yorgey

...

On Tue, Apr 23, 2013 at 12:49:59PM +0200, Alberto G. Corona wrote:

...
Hi

I ever was worried about the barrier that the complexity of the Haskell errors impose to users of DSLs. Many DSLs look so simple that even someone without knowledge of Haskell can make use of them for some domains.

However when the program is compiled then al the monsters of the deep appear in the surface: polymorphisms, undefined instances, type errors reported in a line produced by a type assumption in another, etc. This is a problem for an industrial use of Haskell in the large scale. For obvious reasons.

Indeed. For example, in my experience this is a big problem for diagrams.

...
The question: Is it possible to develop a GHC extension that attach (or prepend) such an explanation to the ghc error?

Or any other alternative that carry out the same functionality.

Surely it is possible. I have wanted this too. I guess the majority of the work would just be in coming up with a good, general design which is useful but not too difficult to implement. If anyone wanted to undertake such a project I would be happy to contribute some ideas.

-Brent

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

-- Alberto.

Alberto G. Corona

27 Apr 27 Apr

5:07 a.m.

New subject: Haskell compilation errors break the complexity encapsulation on DSLs

I created a ticket for the feature request: Ticket #7870 Teachers, newbies and people working in Industry: Please push it! 2013/4/24 Alberto G. Corona

...

Maybe it is possible to do something In a google summer of code. Nothing as sophisticated as the Helium paper ("Scripting the Type Inference Process", but maybe a partial implementation of the techniques mentioned, so that the development can be enhanced in the future.

Maybe some kind of library that permits postprocessing of GHC errors and/or the identification of points in the current type checker where some kind of rules can be defined by the programmer can be the first step.

2013/4/23 Brent Yorgey

...
On Tue, Apr 23, 2013 at 12:49:59PM +0200, Alberto G. Corona wrote:

...
Hi

I ever was worried about the barrier that the complexity of the Haskell errors impose to users of DSLs. Many DSLs look so simple that even someone without knowledge of Haskell can make use of them for some domains.

However when the program is compiled then al the monsters of the deep appear in the surface: polymorphisms, undefined instances, type errors reported in a line produced by a type assumption in another, etc. This is a problem for an industrial use of Haskell in the large scale. For obvious reasons.

Indeed. For example, in my experience this is a big problem for diagrams.

...
The question: Is it possible to develop a GHC extension that attach (or prepend) such an explanation to the ghc error?

Or any other alternative that carry out the same functionality.

Surely it is possible. I have wanted this too. I guess the majority of the work would just be in coming up with a good, general design which is useful but not too difficult to implement. If anyone wanted to undertake such a project I would be happy to contribute some ideas.

-Brent

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

-- Alberto.

-- Alberto.

Ozgur Akgun

4:14 p.m.

New subject: Haskell compilation errors break the complexity encapsulation on DSLs

Hi, On 27 April 2013 10:07, Alberto G. Corona wrote:

...

I created a ticket for the feature request:

Ticket #7870

Teachers, newbies and people working in Industry: Please push it!

A link to the ticket may be helpful for the lazy. http://hackage.haskell.org/trac/ghc/ticket/7870 I quite like this idea, and I think this is one thing people use TH for now instead. (Using quasi-quotes, you can produce any compilation error you like...) It would be great if we didn't have to pull in the full power of TH (or QQ) for this. Cheers, Ozgur

Alberto G. Corona

30 Apr 30 Apr

8:13 a.m.

New subject: Haskell compilation errors break the complexity encapsulation on DSLs

I hope that the GHC people will give to this a high priority. Specially for the people of FP Complete for which this should be a first target. I know that Simon Peyton Jones gave up in "avoid success at all costs" and not it invest in the industry. Isn't? Alberto --------- frictionfreedemocracy.org 2013/4/27 Ozgur Akgun

...

Hi,

On 27 April 2013 10:07, Alberto G. Corona wrote:

...
I created a ticket for the feature request:

Ticket #7870

Teachers, newbies and people working in Industry: Please push it!

A link to the ticket may be helpful for the lazy.

http://hackage.haskell.org/trac/ghc/ticket/7870

I quite like this idea, and I think this is one thing people use TH for now instead. (Using quasi-quotes, you can produce any compilation error you like...) It would be great if we didn't have to pull in the full power of TH (or QQ) for this.

Cheers, Ozgur

-- Alberto.

4404

Age (days ago)

4411

Last active (days ago)

List overview

Download

5 comments

3 participants

participants (3)

Alberto G. Corona
Brent Yorgey
Ozgur Akgun