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].

Reply via email to