[Haskell-cafe] Using GHC as an arrows preprocessor?
bugfact at gmail.com
Sun Apr 19 16:07:37 EDT 2009
On Sun, Apr 19, 2009 at 4:59 PM, Ross Paterson <ross at soi.city.ac.uk> wrote:
> On Sun, Apr 19, 2009 at 04:32:35PM +0200, Peter Verswyvelen wrote:
> > I'm making some custom arrows and I'm getting bugs when using the GHC
> > preprocessor, but not when using the old standalone preprocessor.
> > In order to debug this, it would be nice to use GHC as an arrows
> > (so converting the arrow notation into plain Haskell and outputting the
> > converted source code); is this possible?
> It isn't: the desugaring in GHC maps type-annotated Haskell into GHC's
> Core language.
> I'd be very interested in tracking down any behavioural differences between
> the standalone preprocessor and the GHC implementation. Are these
> bugs, or something else? Note that both of these translators assume that
> your combinators satisfy the arrow laws.
No it was a bug in my code, but it is much easier to track down this bug by
inspecting the generated Haskell code. Yes I could have tried to prove the
arrow laws but my code is rather complex, so I delayed the prove :-) It just
happened that the arrow preprocessor generated different and more compact
Haskell source code that did not reveal the bug I got with GHC's builtin
Regarding arrow laws, it would be nice to have an arrow processor that makes
use of extended arrow laws as described in the paper of Hai (Paul) Liu, Paul
Hudak (Causal Commutative
Some of their optimizations are very impressive!
Actually I learned arrows via Yampa, and I never realized that arrows are
*not* commutative, so I got the wrong picture of arrows (actually a more
beautiful picture...). E.g. - if I understand it correctly - f *** g does
not have to be equal to g *** f according to the standard arrows laws, but
FRP systems like Yampa actually do have this law (f *** g == g *** f).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe