Turns out this was because I need to reconstruct the values and my await'
typesig was wrong.
-- | Map a function over every 'SigPacket' of a 'Signal' flowing downstream.
> {-# INLINABLE mpackets #-}
> mpackets :: Monad m => Pipe p p' m r -> Pipe (Signal p e c) (Signal p' e
> c) m r
> mpackets p = await' >~ for p (yield . SigPacket)
> where
> await' = await >>= \x -> case x of
> SigPacket y -> return y
> SigEvent e -> yield (SigEvent e) >> await'
> SigCommand c -> yield (SigCommand c) >> await'
On Thursday, July 10, 2014 10:17:07 PM UTC+10, Kyle Van Berendonck wrote:
>
> I'm not sure at all why this doesn't compile:
> http://lpaste.net/107265
>
> It looks exactly the same as left/right from Pipes.Extras, and it makes
> complete sense in my head, but the compiler thinks p is never transformed
> into p' in the Pipe p p'.
>
> On Wednesday, July 9, 2014 11:53:27 PM UTC+10, Gabriel Gonzalez wrote:
>>
>> You're welcome!
>>
>> On 7/9/14, 1:40 AM, Kyle Van Berendonck wrote:
>>
>> Thanks, and sorry for delayed reply.
>>
>> I hadn't thought of doing it like how +++ does it, by just chaining the
>> pipes.
>>
>> On Wednesday, July 9, 2014 3:20:12 AM UTC+10, Gabriel Gonzalez wrote:
>>>
>>> You can do this using `Pipes.Extras.(+++)`:
>>>
>>> p1 :: Pipe a d m r
>>> p2 :: Pipe b e m r
>>> p3 :: Pipe c f m r
>>>
>>> (p1 +++ p2) +++ p3 :: Pipe (Either (Either a b) c) (Either (Either d
>>> e) f) m r
>>>
>>> Then all you have to do is just stick `Pipes.Prelude.map` upstream of
>>> that to convert a `Signal` to a nested `Either`, and then also stick a
>>> `Pipes.Prelude.map` downstream of that to unify your handlers. I think it
>>> would look like this, but I haven't type-checked this yet:
>>>
>>> dispatcher :: Mode p p' e c m -> Pipe (Signal e c p) p' m ()
>>> dispatcher mode =
>>> Pipes.Prelude.map toEither
>>> >-> ((handlePacket mode +++ handleEvent mode) +++ handleCommand
>>> mode)
>>> >-> Pipes.Prelude.map fromEither
>>> where
>>> toEither s = case s of
>>> SigPacket p -> Left (Left p)
>>> SigEvent e -> Left (Right e)
>>> SigCommand c -> Right c
>>>
>>> fromEither e = case e of
>>> Left (Left p')) -> p'
>>> Left (Right p')) -> p'
>>> Right p' -> p'
>>>
>>> That will preserve the individual state of each handler.
>>>
>>> On 7/8/14, 8:09 AM, Kyle Van Berendonck wrote:
>>>
>>> I have a sum type which looks like this:
>>>
>>> data Signal e c p = SigEvent e | SigCommand c | SigPacket p
>>>
>>>
>>> I would like the user to be able to provide functions:
>>>
>>> type Handler p p' m = Pipe p p' m ()
>>>> data Mode p p' e c m = Mode
>>>> { handlePacket :: Handler p p' m
>>>> , handleEvent :: Handler e p' m
>>>> , handleCommand :: Handler c p' m }
>>>
>>>
>>> and have my single input pipe (dispatcher :: Pipe (Signal e c p) p' m
>>> ()) fork between the three handlers, while preserving the state of each.
>>> ie, one handling commands may use `await` but the next packet could be an
>>> event, so it would stay in await until a command arrives. One handler pipe
>>> quitting/finishing should result in all quitting.
>>>
>>> I would not like intermediate containers or forking threads to be part
>>> of the solution, since it will be a tight loop.
>>>
>>> Ideally, I need something like `next` which can be called in the other
>>> direction. Ideas?
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Haskell Pipes" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Haskell Pipes" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].