Hello! In process of adapting 'netwire-5.0.0' to my needs I discovered following strange thing. Let us consider following simple program: {-# LANGUAGE Arrows #-} import FRP.Netwire import Data.Monoid -- I almost sure this is correct, since it is copied -- from "Programming with Arrows", J. Hughes mapA :: (ArrowChoice a) => a b c -> a [b] [c] mapA f = proc input -> case input of [] -> returnA -< [] z:zs -> do y_ <- f -< z ys_ <- mapA f -< zs returnA -< y_:ys_ mconcatA :: (ArrowChoice a, Monoid m) => a b m -> a [b] m mconcatA f = mapA f >>> arr mconcat -- Note the commented line. wire :: (Monad m, HasTime t s) => Wire s () m a Double wire = pure (Sum 1.0) -- >>> arr (: []) >>> mconcatA returnA >>> arr getSum >>> integral 10 main = testWire (countSession_ 1) wire Problem is that, compiled with ghc-8.0.1 this program hangs if I uncomment second line in body of ``wire`` function[1], which is wierd, since assuming monoid and arrow laws, I believe -- (Arrow a, Monoid e) => a e e arr (: []) >>> mconcatA returnA = returnA Is it false? Any suggestions? .. [1] with that line commented program works and prints sequence of numbers, with every next over previous. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. |
Hi,
> -- I almost sure this is correct, since it is copied > -- from "Programming with Arrows", J. Hughes > mapA :: (ArrowChoice a) => a b c -> a [b] [c] > mapA f = proc input -> > case input of > [] -> returnA -< [] > z:zs -> do y_ <- f -< z > ys_ <- mapA f -< zs > returnA -< y_:ys_ Yes, this is correct. However, the ArrowChoice instance in Netwire has always been questionable. The correct (and much more efficient) way to implement mapA is as a primitive combinator much like the parallel switches in Yampa. The Netwire implementation and API has been more focussed on providing features over reasonable semantics, and that eventually led me to abandon it in favour of a more minimalistic library that is easier to reason about (wires). Please consider Netwire deprecated and I recommend you don't use it for new applications, if possible. I'm still open to reviewing and merging code contributions to support legacy applications, but other than that I would much prefer to just let it become a piece of AFRP history. =) If you must use AFRP, I recommend either my new library called wires, or the progenitor of all, Yampa. However, unless you have a strong reason to use arrowized FRP I would recommend that you go with one of the first-class FRP libraries. I currently recommend either: * reactive-banana: very simple and easy to learn API, plus the author runs a blog with lots of information on FRP. This is the library I recommend to FRP beginners. Or * reflex: my personal favourite, more focussed on practical concerns and efficiency, a more versatile API that easily integrates with applications with a "main loop", such as real-time games. The trade-off is far less documentation and a more complicated API. Sorry for not directly addressing your question, but I hope I convinced you to just switch to a different library. =) Greets ertes _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. signature.asc (497 bytes) Download Attachment |
Free forum by Nabble | Edit this page |