[Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs

[Alberto G. Corona]

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/doc/html/Control-Monad-Exception.html

 

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 MyException without handling it, and I won't let you"

Either handle it or declare MyException as an UncaughtException.

 

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.

[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
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Stephen Tetley]

Helium - Utrecht University's simplified Haskell - had scriptable
"Type inference directives" so the creator of an EDSL was able to
augment the type checker to provide better error messages, see:

Scripting the Type Inference Process
Bastiaan Heeren Jurriaan Hage S. Doaitse Swierstra

[Alberto G. Corona]

Stephen

The paper is very interesting. We need something like that:

 

... As a result, the beginning programmer is likely to be discouraged from pro-gramming in a functional language, and may see the rejection of programs as a nuisance instead of a blessing. The experienced user might not look at the messages at all.

 

The problem is exacerbated in the case of combinator languages. Combinator languages are a means of defining domain specific lan-guages embedded within an existing programming language, using the abstraction facilities present in the latter. However, since the domain specific extensions are mapped to constructs present in the underlying language, all type errors are reported in terms of the host language, and not in terms of concepts from the combinator library. In addition, the developer of a combinator library may be aware of various mistakes which users of the library can make, something which he can explain in the documentation for the library, but which he cannot make part of the library itself.

In the meantime maybe we can have a simpler solution like a postprocessing of errors in some way

2013/4/23 Stephen Tetley <stephen...@gmail.com>

--
Alberto.

[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 <byo...@seas.upenn.edu>

--
Alberto.

[Alberto G. Corona]

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 <agoc...@gmail.com>

--
Alberto.

[Ozgur Akgun]

Hi,

On 27 April 2013 10:07, Alberto G. Corona <agoc...@gmail.com> 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]

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 <ozgur...@gmail.com>

--
Alberto.