That kind of problem is very common in EDSLs. The problem is that a EDSL tries to hide complexity, but the error messages expose this complexity to the userw. So in real terms, it is not possible to make use of a EDSL in full without knowing in detail the internals. Tha´ts too bad, specially in industry, where the specialization between middleware/system/architecture programming and application programming is common. Any advance on this would be very necessary. it could be some kind of magic type trickery or some naming conventions. It sould be very appreciated. Another option to exprore would be to permit custom error messages, where the long messages using the context of the haskell type system can be postprocessed to generate a simpler message with a clear meaning in the context of the EDSL. For me, this is a limitation for haskell to enter in the industry seriously. 2012/10/25 Felipe Almeida Lessa <felipe.lessa@gmail.com>:
On Wed, Oct 24, 2012 at 10:32 PM, Erik de Castro Lopo <mle+hs@mega-nerd.com> wrote:
Hi all (and in particular Filipe),
Hey! =)
I'm looking at Esqueleto and I'm finding that in certain circumstances it can throw out some rather horrid error messages. Consider the correct code fragment taken from the Esqueleto docs:
select $ from $ \(b, p) -> do where_ (b ^. BlogPostAuthorId ==. p ^. PersonId) return (b, p)
The error occurs if the programmer uses the wrong identifer in the where_ clause. For instance, if PersonId is used instead of BlogPostAuthorId then I get about 100 lines of error message, the majority of which is totally incomprehensible.
What are those messages?
Is there anything that can be done inside Esqueleto to make these error messages better?
Nothing straightforward, AFAIK. Sadly, the horridness of the error messages is directly proportional to the amount of type hackery in the code.
Cheers, =)
-- Felipe.
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
-- Alberto.