- Haskell-Cafe - Haskell.org

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 02 Apr '11

02 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 02 Apr '11

02 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 02 Apr '11

02 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

SoC project: advice requested
by Gábor Lehel 01 Apr '11

01 Apr '11

Hi all, I would very much like to apply for a Summer of Code project this year; however, I'm having trouble nailing down a project which is both (a) of appropriate scope and (b) which interests and motivates me. There's also obviously the question of needing a mentor for the project. Regarding (b), I'm finding it hard to get really excited about hacking on Cabal or other infrastructure: I'd much rather like to add some kind of new, interesting, and useful capability to GHC itself. Naturally, this comes into a kind of tension with (a). I'd love to work on something type system related, but have the feeling that going from 'amateur Haskeller' to 'type theory and GHC expert' within the course of a single summer is likely going to be too much. (Feel free to correct me on this point, though!) The two projects I've been able to think of which seem like they *might* be appropriate are: integrating the standard 'deriving' mechanism with Template Haskell to support deriving custom classes; and adding native FFI support for passing C structs / tuples (arbitrary products?) of FFI-able types by value, as discussed in [1]. Would either of these be not-too-big / would anyone be willing to mentor them? Alternately, I'd be very happy to receive suggestions about other GHC-related work which would be considered appropriate. (Or, heck, any other compiler.) A related problem is that, having done only minimal GHC hacking so far, drawing up a detailed plan / design in advance as part of the proposal would be difficult. If this is considered necessary and there is someone willing to mentor the project I'd be happy to research the problem in advance of the submission deadline so I can submit a more detailed proposal. Alternately, if it's deemed acceptable to learn the ropes / come up to speed as part of the SoC itself that's fine by me as well. (Wasn't this sort of the point originally?) Background info: I've taken part in the SoC once before, back in 2006 (when I applied to KDE to work on Krita). I don't yet have any Hackage packages to my name, however I'm working on a C++-to-Haskell bindings generator for my bachelor's thesis (the primary target being Qt*) which is likely to spawn quite a few. (I've avoided making any noise about this because I didn't want to put the cart before the horse: the plan was (and still is) to announce something once there is something worth announcing, and it's not at that point quite yet.) Apologies for not writing this email a couple weeks earlier; I have a day job and next to the thesis it didn't leave much time to brainstorm and research. (The job isn't Haskell-related and doesn't even pay as well, so if I get accepted I'll have no compunctions scaling it back (even completely). And the deadline for the thesis is May 15th, which is convenient enough.) Thanks, ~g [1] http://www.mail-archive.com/haskell-cafe@haskell.org/msg61034.html * Yes, I know qtHaskell exists. I have some, how to say, 'differences of opinion' with regards to its API, and it's not open source anyways. -- Work is punishment for failing to procrastinate effectively.

3 6

Class constraints for associated type synonyms
by Jan-Willem Maessen 01 Apr '11

01 Apr '11

Hi all - I've been trying to construct a class declaration with an associated type synonym, but I'd like to constrain that type to belong to a particular class. Consider the following class: class Monoid m => Constructs c m | c -> m where construct :: m -> c This captures the idea that the collection c ought to be constructed using the monoid m (say if we're doing the construction using the Writer monad)--the functional dependency indicates the desire for the type c to injectively determine the choice of monoid m. For example: newtype ListBuilder a = Builder ([a] -> [a]) deriving (Monoid) instance Constructs [a] (ListBuilder a) where construct (Builder f) = f [] instance (Ord a) => Constructs (Set a) (Set a) where construct = id Now I'd like to be able to do the same thing using an associated type synonym, something like this: class Monoid (GeneratorOf a) => Generable a where type GeneratorOf a :: * -> * construct :: GeneratorOf a -> a Now, it seems I need FlexibleInstances to do this when I'm using an associated type synonym, but I don't need the flexibility when using a multiparameter type class. In both cases the instance constraint involves types that can be injectively inferred (if I have my terminology straight; work with me here) from a single type mentioned in the class head. In particular, I can imagine storing the dictionary for Monoid (GeneratorOf a) in the dictionary for Generable a, and thus allowing context reduction of (Monoid (GeneratorOf tyvar)) to (Generable tyvar). Meanwhile, I think there are things that are permitted by FlexibleInstances that I'd rather *not* have creeping into my programs. Is there a fundamental constraint I'm missing here that requires the full generality of FlexibleInstances? Do I need to use FlexibleInstances whenever I use associated types in my programs? -Jan-Willem Maessen

3 3