- Haskell-Cafe - Haskell.org

State Machine Composition
by Daniel Waterworth 24 Dec '11

24 Dec '11

I made this simple state machine combinator library today. I think it works as a simple example of a good use for GADTs. https://gist.github.com/1507107 Daniel

3 4

Re: [Haskell-cafe] The Riddle of the Buddhist Monk
by Patrick Browne 23 Dec '11

23 Dec '11

3 4

How to define Storable instance for data constructor with storable vectors
by Sanket Agrawal 21 Dec '11

21 Dec '11

I am trying to write a union data structure which can store vectors - a simplified definition of data structure is below: --------------------- -- V is Data.Vector.Storable data Elems = I {-# UNPACK #-} !GHC.Int.Int32 | S {-# UNPACK #-} !GHC.Int.Int32 {-# UNPACK #-} !(Ptr CChar) | T {-# UNPACK #-} !(V.Vector Elems) --------------------- What I can't figure out is how to store Vector elements when defining Storable instance for Elems type - the main stumbling block is that my approach requires defining a Storable instance of ForeignPtr. Snippets of code below: --------------------- instance Storable Elems where sizeOf _ = ... alignment _ = ... {-# INLINE poke #-} poke p x = case x of ... T x -> do poke (castPtr p :: Ptr Word8) 3 -- store a tag for data constructor T. We will check it when doing peek let (fp,_,n) = V.unsafeToForeignPtr x poke (castPtr p1) n poke (castPtr (p1 `plusPtr` 8)) fp where p1 = (castPtr p :: Ptr Word8) `plusPtr` 1 -- get pointer to start of the element. First byte is type of element {-# INLINE peek #-} peek p = do let p1 = (castPtr p::Ptr Word8) `plusPtr` 1 -- get pointer to start of the element. First byte is type of element t <- peek (castPtr p::Ptr Word8) case t of .... -- handle all data constructors except T here _ -> do x <- peek (castPtr p1 :: Ptr Int) y <- peek (castPtr (p1 `plusPtr` 8) :: Ptr (ForeignPtr Elems)) return (T (V.unsafeFromForeignPtr y 0 x)) -- return vector elements --------------------- If I use above approach, I will need to define Storable instance of ForeignPtr for Elems data type. Is it possible to define peek/poke operations for storing vectors, using something other than ForeignPtr? I prefer using ForeignPtr because it has finalizer associated with it. I guess it might be possible to store Ptr through withForeignPtr, but then how do you convert back from the Ptr to Vector in peek? If storing the ForeignPtr is a cleaner approach, how would Storable definition for ForeignPtr look like? GHC code for ForeignPtr seems to export only ForeignPtr constructor. I am aware above code is not portable (e.g., assumption that Int is 8 bytes). That is not really an issue because I am writing code for a very specific platform. If there is a library defined somewhere which has already dealt with similar issue, I will very much appreciate pointers.

1 0

Alternative versus Monoid
by Gregory Crosswhite 21 Dec '11

21 Dec '11

Hey everyone, First, thank you all for this great discussion! I unfortunately have been home due to health concerns which gets really boring after a while, so being able to participate in such a fun intellectual exercise like has really been making my day. :-D Sorry that this has resulted in such a flood of commentary on the list! Antoine Latter has pointed out to me that (using my own words here) essentially entire parser libraries are built around the assumption that many and some are sensibly defined the way that they are, and that as a result much of their functionality simply doesn't make sense for Maybe and []. So maybe the best approach to take really is to remove the instance for Maybe and [] from Alternative. After all, some and many simply are not well-behaved for them, and if you are using Alternative you are expecting them to be well-behaved. Now, on the other hand, one might argue: but Maybe and [] have well-defined functions for empty and <|>, so since some and many are defined in terms of these operations, shouldn't that make Maybe and [] natural instances of Alternative anyway? And *this* is where Haskell separates its way from other languages. In others language we may very well just say, "Well, good point, why not make them instances of Alternative, and simply not worry about the fact that some and many don't behave well --- just don't use them like that!" But in Haskell we don't do things this way. When we make something be an instance of a typeclass, we want that to *mean* something. In the case of Alternative, we want, among other things, for it to mean that our type has sensible meanings for some and many --- and if Maybe and [] simply do not meet this criteria, then THEN THEY DESERVE TO BE CAST OUT! I know, I know, I can hear you all shouting: This is blasphemy! This is madness! Madness? This... IS HASKELL! But on a more serious note, it turns out that we *already* have a typeclass that does everything that Alternative does but without the "some" and "many" baggage: it's called "Monoid"! So we can already get all of the features that we need (and most likely have been using anyway) by using the Monoid instances for Maybe and [] and just forgetting about the existence of Alternative entirely. So at the end of the day... what is the point of even making Maybe and [] instances of Alternative? Cheers, Greg

10 23

Re: [Haskell-cafe] Alternative versus Monoid
by Matthew Farkas-Dyck 21 Dec '11

21 Dec '11

On 21/12/2011, Bas van Dijk <v.dijk.bas(a)gmail.com> wrote: > On 16 December 2011 16:26, Yves Parès <limestrael(a)gmail.com> wrote: >> "1) What about the First type? Do we {-# DEPRECATE #-} it?" >> >> Personnaly, I'm in favor of following the same logic than Int: >> Int itself is not a monoid. You have to be specific: it's either Sum or >> Mult. >> >> It should be the same for Maybe: we remove its instance of Monoid, and we >> only use First and Last. > > The reason you need to be specific with Int is that it's not clear > which semantics (sum or product) you want. The semantics of Maybe are > clear: it's failure-and-prioritized-choice. > > Changing the order of the arguments of mappend should be the job of Dual. > > If we really want to drop the Monoid instance for Maybe and keep First > and Last and also want to be consistent we should also drop the Monoid > instances of [a], a->b, Endo a and of all the tuples. And instead > define Monoid instance for First [a], Last [a], First (a->b), Last > (a->b), etc. I don't think this is what we want. > > Regards, > > Bas > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Fair point. I concede. If Monoid were necessarily inner-type-gnostic then we'd also have to drop instance Monoid [a]. Cheers, Matthew Farkas-Dyck

1 0

"mapping" an Enumerator
by Kannan Goundan 21 Dec '11

21 Dec '11

I'm using the Data.Enumerator library. I'm trying to write a "map" function that converts an Enumerator of one type to another. Something like: mapEnum :: Monad m => (a -> b) -> Enumerator a m r -> Enumerator b m r Any hints? (My exact use case is that I have a ByteString enumerator and I need to pass it to something that requires a Blaze.Builder enumerator.)

4 6

[Alternative] change some/many semantics
by Gregory Crosswhite 21 Dec '11

21 Dec '11

Hey everyone, This is even more out there than my previous posts, but the following just occurred to me: is it absolutely necessary that some/many have produced the entire list of results before returning? Couldn't we change their semantics so that the list of results is computed and/or extracted lazily? For example, if this were the case, then we would have that (some (Just 1)) returns an infinite list rather than running in an infinite loop (even without defining a special case "some" implementation), which is exactly what my intuition would expect. Of course, this is not a simple change at all because it would have to be done in such a way as to respect the ordering of actions --- that is, we can't have each action executed only when the corresponding element of the list demanded is forced, or else actions would undesirably interleave. For example, in a parser when we use "many v" we expect everything matching v to be consumed by the time "many v" returns, but if instead "many v" only consumed as much of the input as we demanded from its result list then we might see a chunk of input matching v in another part of our parser despite having assumed we'd gotten rid of it, which would cause our parser to be broken. Nonetheless, if there were some way that we could use magic fairy dust to have the results returned by some and many be lazily generated lists, then this might solve many of the problems that come up with them performing infinite loops in cases where it seems like they shouldn't. :-) Cheers, Greg

6 19

Interruptible threads with IO loops
by Fedor Gogolev 21 Dec '11

21 Dec '11

Hello. I'm trying to get some threads that I can stop and get last values that was computed (and that values are IO values, in fact). Here is my first approach: module Main where import Control.Concurrent (MVar, threadDelay, forkIO, newMVar, putMVar, readMVar) tick :: Int -> IO Int tick v = return $ v + 1 loop :: MVar Bool -> a -> (a -> IO a) -> IO a loop var init loopfun = do next <- loopfun init shouldStop <- readMVar var case shouldStop of True -> return next False -> loop var next loopfun runLoop :: Int -> IO () runLoop timeout = do var <- newMVar False forkIO $ threadDelay timeout >> putMVar var True value <- loop var 0 tick print value main :: IO () main = runLoop 30000000 The problem is that it looks a little messy and what's worse it leaks memory. So I'm wondering if there is a better approach to do so or some fix to memory leak.

6 7

Mitigating state-threading through an application loop
by Michael Serra 21 Dec '11

21 Dec '11

Hello Haskellers, I'm implementing a simple tree-manipulating (for sports tournaments) application prototype, with SDL for graphics and simple user interaction. For reference, I've posted the code on hpaste. <http://hpaste.org/55506> My question is about code organization: everything was simple and elegant until I started writing the program's display/event loop. Every function in this section has to be passed the same parameters - the application window to draw on, the font to display text with, the tree representing the current application state, etc. The font is an especially egregious example of the problem, because it's only used by one function but to get there it must be threaded through all of them (looking at the hpaste, you will see I don't want to call openFont on every invocation of drawTexts; what's needed is to call it once in main and have the resulting value available to drawTxt. So my question: how can I mitigate the ugliness of this state-threading? I understand this is one purpose for monads; am I supposed to implement a monad transformer for this? I think it would be great if I could define a type AppState as a tuple of the various things I need to thread, and specify some kind of automatic as-pattern, so that every function taking this AppState parameter would implicitly have its components bound to certain preset names. I've never seen anyone do this however. What is the right solution?

4 3

ANNOUNCE: partial-lens 0.0.1
by roconnor＠theorem.ca 21 Dec '11

21 Dec '11

Do you miss null references from your old imperative programming days? Wish that the worlds best imperative language had null references? Now your wishes have come true with the new partial-lens package! partial-lens augment edwardk's data-lens package with partial lens. Partial lenses are like regular lenses but have the possibility of not referencing anything. In other words, null references are possible. One notable different with null references from this package is that you can set them without getting a run-time error. Instead setting a null reference is a no-op; however it is possible to determine if setting failed from the return value of the assignment operation. Actually I don't have any applications for partial lenses myself, so if you find this library useful, please let me know. I wrote this mostly because we know what partial lenses are in theory (they are the coalgebras of the (Identity :+: Store b) comonad) but I wanted to see what a real library would look like. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

2 3