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 preprocessor (so converting the arrow notation into plain Haskell and outputting the converted source code); is this possible? I also noticed that GHC's builtin preprocessor generates far more intermediate combinators than the old preprocessor. The benchmark in this paper http://www.cs.yale.edu/homes/hl293/download/NEPLS-talk.pdf seems to confirm this. Is this a known issue? Thanks, Peter
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 preprocessor (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 strictness bugs, or something else? Note that both of these translators assume that your combinators satisfy the arrow laws.
I also noticed that GHC's builtin preprocessor generates far more intermediate combinators than the old preprocessor. The benchmark in this paper seems to confirm this. Is this a known issue?
I've heard of this, but not seen a simple clear test case.
On Sun, Apr 19, 2009 at 4:59 PM, Ross Paterson
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
On Sun, Apr 19, 2009 at 04:32:35PM +0200, Peter Verswyvelen wrote: preprocessor
(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 strictness 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 arrow translator. 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 Arrowshttp://www.cs.yale.edu/homes/hl293/download/NEPLS-talk.pdf). 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).
participants (2)
-
Peter Verswyvelen -
Ross Paterson