Re: [Haskell-cafe] 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 ozgurak...@gmail.com Hi, On 27 April 2013 10:07, Alberto G. Corona agocor...@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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 agocor...@gmail.com 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 byor...@seas.upenn.edu 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs
Hi, On 27 April 2013 10:07, Alberto G. Corona agocor...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 byor...@seas.upenn.edu 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs
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.tet...@gmail.com 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 ___ 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
