April 2011 - Haskell-Cafe

Re: [Haskell-cafe] [Haskell-beginners] how to modify show for a list of certain types
by Markus Läll 02 Apr '11

02 Apr '11

Check out "unlines"! On Sat, Apr 2, 2011 at 4:32 PM, Manfred Lotz <manfred.lotz(a)arcor.de> wrote: > Hi there, > I have a list of say type Record which I write to a file and > read back from the file if required. > > The list's content is a single line in the file it doesn't matter how > many records the list contains. > > I would like to modify show for type Record in a way that show does > work like the normal show but additionally adds a newline at the end of > the string. > > I'm a bit lost how to do that. Any idea? > > > -- > Manfred > > > > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners >

1 0

Multi agent system
by Yves Parès 02 Apr '11

02 Apr '11

Hello, For the purpose of a simple game, I'm looking for a simple way to get agents communicating with each other, with agents possibly running on different threads: Basically, an agent is Agent :: * -> *, since it is parameterized with the type of messages it can receive, and can make two basic operations: fetch, which gives it the messages in its mailbox and send, which sends a message a to an Agent a Given that haskell threads are lightweight, is it reasonable to lauch a thread per agent and then implement fetch and send through Chans? It will be simple to implement and to use, but if I have, say, two hundreds of really dumb (sorry, *reactive *^^) agents, like ants, I will have to launch as many threads. I could use a neater abstraction than IO to model agents (FRP is perfect for that), but I would loose the benefits of concurrent programming (or I won't be able to keep things simple).

2 1

Fwd: using IO monad in Iteratee
by Dmitry Olshansky 02 Apr '11

02 Apr '11

---------- Forwarded message ---------- From: Dmitry Olshansky <olshanskydr(a)gmail.com> Date: 2011/4/2 Subject: Re: [Haskell-cafe] using IO monad in Iteratee To: wren ng thornton <wren(a)freegeek.org> Well, in my case I can use probably withBinaryFile fn (\h-> run $ enumHandle h ...) 2011/4/2 wren ng thornton <wren(a)freegeek.org> > On 4/1/11 3:59 PM, Dmitry Olshansky wrote: > >> But enumFile use IO monad instead of MonadIO class. >> [...] >> >> Is it possible to change enumFile to using MonadIO class? >> > > Unless its changed significantly since I looked at it last (which it may > well have), it's not possible. The problem is that what we'd really need is > lowerIO :: m a -> IO a for the m in question; liftIO goes the wrong way. Of > course, getting a lowerIO with the right semantics will be tricky for most > monads. > > -- > Live well, > ~wren > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Asynchronous Arrows need Type Specialization - Help!
by David Barbour 01 Apr '11

01 Apr '11

I was giving Control.Arrow a try for a reactive programming system. The arrows are agents that communicate by sending and returning time-varying state. Different agents may live in different 'vats' (event-driven threads) to roughly model distributed computing. For the most part, the state varies asynchronously - i.e. a file updates at a different rate than the mouse position. Anyhow, I ran into a problem: The (***) and (&&&) operations, as specified in Control.Arrow, are inherently synchronization points. Ideally one could do something like: (a1 *** a2) >>> first a3 and the output from a1 would be piped directly as input to a3, without touching a2. However, arrows also allow: (a1 *** a2) >>> arr f And, in this case, the current state of a1 and a2 must be combined into a stream of pairs so that f may be mapped over the stream. Obtaining both streams at a single place (a single vat) and time is a synchronizing operation. The synchronization operations are severely undermining the intended scalability and performance of this agent abstraction. Now, I believe I could make it work if I could somehow specialize the arrow type with aparametric structure... A (b,b') (c,c') = A b c = But I've not been able to make the Haskell type system happy with this. Type families allow some specialization, but they don't allow ambiguity or defaults. Given the 'arr' function, I must be able to instantiate an A involving any type at all. Today I explored an alternative version of Control.Arrow, using an opaque product type specialized to the arrow, but I still bumped into the issue of specializing the arrow type for this. I don't see how GADTs would help. I've been stuck on this for a couple weeks now. Ideas would be appreciated.

4 3

Re: [Haskell-cafe] Asynchronous Arrows need Type Specialization - Help!
by Paul L 01 Apr '11

01 Apr '11

Thanks for the elaboration. I now have a much better understanding. FIrst of all, I agree that the system model as you laid out do not fit into the arrows abstraction with respect to the set of arrow laws. Then the choice is whether to shape the arrows to fit your model, or shape your model to fit arrows. You chose the former. But one thing I want to be clear is that the arrows abstraction didn't impose the kind of strictness to your model, your system design did. If you would like to consider the second approach, I have a few suggestions: 1. Enable a lazy evaluation strategy over a distributed system. This can be done by passing place holders between agents, and only fill them (either by sending over data or request-by-demand) when value is fully computed. There could be other alternatives, but I'm not familiar with the set of literatures in this particular area. Maybe somebody else could give pointers. 2. Statically schedule data availability and delivery from producer to consumer. I'm not sure what kind of application you try to model, but this would limit the scope to dataflow that can be statically analyzed before program runs. On the other hand, the limitation also bring benefits because we can be smart about whether to move data or to move computation. To do this properly requires a solution to the pure function problem. For the pure function example you gave: > let f = \ (fileState, queryResult) -> combineResponses in > (a1 *** a2) >>> arr f Didn't you just mention that you want to tag along the time stamp to the values? So fileState is really a lifted value over a plain file state, and so is queryResult. This means the combineResponse function is also a lifted function. In the actual implementation of such lifting (perhaps over multiple type classes), the calculation of the time stamp can be made precise. Only difficulty I see here is that we may need to lift time stamped values over tuples. A single Int value wouldn't suffice as the type for time stamp because it has to take the max of time stamps of the tuple elements (what is exactly what you are criticizing). It may require some type level magic, but I am quite positive that difficulties can be overcome. Regards, Paul Liu On Fri, Apr 1, 2011 at 6:00 PM, David Barbour <dmbarbour(a)gmail.com> wrote: > On Fri, Apr 1, 2011 at 2:57 PM, Paul L <ninegua(a)gmail.com> wrote: >> I now understand where you are coming from, but I don't quite get your >> motivation to develop new classes for arrows. Tupling is Haskell is of >> course very lazy, it does not evaluate any of its element. > > Assume three machines: Alice, Bob, and Charlie. Bob owns resource a1, > and Charlie owns resource a3. Bob and Charlie do not know about one > another. Alice runs 'a1 >>> a3' with some initial inputs. For an > 'efficient' implementation, I need the output from a1 to propagate > directly as input to a3, directly from Bob to Charlie - do not pass > Alice, do not waste precious bandwidth and latency. > > Now extend the example just a bit: > > (a1 *** a2) >>> first a3 > > Naively, Alice might take the outputs from a1 and a2 and build a tuple > (r1,r2), then promptly split the tuple back up and send r1 to Charlie. > But this wastes a lot of time and bandwidth and CPU bringing r1 and r2 > together onto Alice's machine. It doesn't matter that Alice never > looks at r1 herself... the fact that she even 'touches' the r1 > variable is killing performance and requires physical synchronization. > In short, laziness doesn't help here. What does help is optimizing > the above into ((a1 >>> a3) *** a2). > > I could go into even more reasons. (I.e. I'm actually using streams, > not simple values, so tupling and untupling is closer to zipping and > unzipping.) But I think the above argument is sufficient by itself. > > My model is designed for efficient, scalable, open, distributed > programming. I currently model distributed machines each as a thread > with an event-loop. But this is a proof-of-concept implementation: I'm > unwilling to 'cheat' by using any techniques that could not > efficiently and securely be implemented for a real open distributed > system. > >> >> As for the spatial and logical concepts, don't you think they are >> over-specifying what is really necessary for your system model? > > I do not believe I've overspecified. > > But I've also avoided explaining the full model. That sort of > explanation really requires a conference paper with a lot of > motivating examples, and it was not my intent to use Haskell-cafe as a > forum. > >> >> So I guess what I'm having trouble with is your arr f example. If f is >> sufficiently lazy, it does not evaluate the elements in its input >> tuple at all. Most pure functions we use to wire up arrows are like >> this: arr fst, arr snd, arr swap, arr (\x -> (x, x)), etc. > > For simple data plumbing that never needs to touch the input, I > currently suggest specialized arrows: > aconst :: c -> a b c > > afst :: a (b,c) b > asnd :: a (b,c) c > adup :: a b (b,b) > aswap :: a (b,c) (c,b) > > aleft :: a b (Either b c) > aright :: a c (Either b c) > amerge :: a (Either b b) b > amirror :: a (Either b c) (Either c b) > > Potentially, RULES pragmas could also convert from 'arr fst' to a > particular implementation of 'afst', though I'd not recommend RULES at > the typeclass level after having been hurt by those in Control.Arrow. > >> >> I also don't quite follow your example of passing a time stamp >> together with value. > > Logically, a 'future' is just a time-stamp paired with a value. > > let f = \ (fileState, queryResult) -> combineResponses in > (a1 *** a2) >>> arr f > > Here, 'arr f' is opaque to my implementation. I cannot look inside 'f' > and decide whether or not it needs both fileState and queryResult, or > just one of them, or none (const). So I must somehow wait for both > fileState and queryResult to be available before I can evaluate > combineResponses. How long do I wait? Well, until the last response is > available. > > In the reactive context, you don't really have futures, but you still > have latency before resource state becomes available, and must wait to > combine results. > >> >> If you are getting unwanted results, it is perhaps due to wrong >> computation, rather than the composition to a pure functions. >> Maybe you want to give a specific example of "f". > > Regards, > > David > -- Regards, Paul Liu

1 0

Missing MaybeT MonadFix instance
by Job Vranish 01 Apr '11

01 Apr '11

Is there a particular reason that the transformers<http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Co…>version of the MaybeT monad does not have a MonadFix instance? It seems like the following instance would be suitable: instance (MonadFix m) => MonadFix (MaybeT m) where mfix f = MaybeT $ mfix $ \a -> runMaybeT $ f $ case a of Just a -> a Nothing -> error "mfix MaybeT: Nothing" I don't think it's possible to hit the error case: In order to terminate f cannot be strict so it must return a value without evaluating its input. If f returns a Nothing, then you have your return value and you're done. If f returns a Just, then we don't hit the error case. - Job

1 0

is ppc64 arch registerised
by Jiri Skala 01 Apr '11

01 Apr '11

Hi all, I've read on this page http://hackage.haskell.org/trac/ghc/wiki/Platforms the ppc64 arch is registerised. I succeeded to build ghc-7.0.2 on ppc64 (Fedora) with GhcUnregisterised=YES. Switching off this option currently leads to failure. I'd like to know: - is the info about registerised ppc64 arch still valid? - could you provide me tips how to build it registerised? Thanks Skalnik

3 2

ArrowLoop and streamprocessors
by Mathijs Kwik 01 Apr '11

01 Apr '11

Hi all, I'm playing around a bit with arrows (more specifically, something like a CPS style streamprocessor as described in "Generalising Monads to Arrows" by John Hughes). A part of my program takes inputs/signals from 2 sources. The sources don't produce output at the same rate, and this part is able to handle inputs independently. So I figured I need Either A B ~> O for this part. handleA :: A ~> O handleB :: B ~> O someBox :: Either A B ~> O someBox = handleA ||| handleB So far so good. Now, further downstream (someBox >>> otherBox) there is. otherBox :: O ~> Either C B Let's say C are "normal" outputs, and B are control signals that need to get wired back to someBox. Control signals are rare, so maybe there's 1000 C outputs and only 1 B output in a certain timeframe. Also note that in this CPS style streamprocessing, there's no 1-on-1 relation between input and output, so on 1 input (O), otherBox might produce 2 outputs (2 times C), or 4 outputs (3 times C and 1 time B). To "wire back" B's to someBox, I'm pretty sure I need to use ArrowLoop. But (loop :: a (b, d) (c, d) -> a b c) uses tuples, which means the processing will only continue when both inputs are available. So if I turn someBox into (A, B) ~> O and otherBox into O ~> (C, B), the processing will instantly halt, waiting for a B to arrive after the A comes in. I know about the 'delay' trick that usually works for loops, where an output value is just inserted before the actual outputs, but that won't help in my case, because otherBox doesn't produce B's at the same rate that someBox receives A's, so by inserting a dummy B, someBox will only "run" once. Also, there's no relation between the number of A inputs someBox receives and the number of inputs for otherBox, so I also can't have otherBox just insert "noop" signals after every "run". So loop really doesn't seem to help here, but I couldn't find another way either to feed outputs back into the system. What I need is: Either A B ~> Either C B -> A ~> C Does such a thing exist? Thanks, Mathijs PS: I remember reading about (unfortunately didn't get the examples working) Reactive (FRP), which has the concept of Events and Behaviors I think Yampa has something like it too. A Behavior has a value at all times, which was updated by Events. That sounds a bit like it might solve my problem, since I need something that contains "Latest Control Signal was X" that updates when B's are produced, but that doesn't have to be put "on the wire" as a stream of events (because I can't determine how many events to put to match incoming A's. However, I hope there is another solution because I found Reactive and Yampa quite hard to grasp.

5 7

Encoding-aware System.Directory functions
by Michael Snoyman 01 Apr '11

01 Apr '11

Hi all, I think this is a well-known issue: it seems that there is no character decoding performed on the values returned from the functions in System.Directory (getDirectoryContents specifically). I could manually do something like (utf8Decode . S8.pack), but that presumes that the character encoding on the system in question is UTF8. So two questions: * Is there a package out there that handles all the gory details for me automatically, and simply returns a properly decoded String (or Text)? * If not, is there a standard way to determine the character encoding used by the filesystem, short of hard-coding in character encodings used by the major ones? For those curious: this is in regards to a bug in wai-app-static[1]. Thanks, Michael [1] http://hackage.haskell.org/package/wai-app-static

11 16

Computational Physics in Haskell
by Azeem -ul-Hasan 01 Apr '11

01 Apr '11

I started learning Haskell a little while ago. Although I am a novice I am still in love with it. I am physics major and primarily interested in Theoretical Physics and would like to use Haskell in this area. So, I just know to what has been done in this area, are there any libraries for simulating physical process in Haskell etc. Azeem Ul Hasan School of Science and Engineering, Lahore University of Management Sciences, Lahore, Pakistan

5 6