Hi David.
partitionE reminds me of the list 'partition' function which has a pretty
different meaning. However we could very well have a partitionE consistent
with list partition. Or maybe find a type class that abstracts list events
and other things, that would support partition.
The list splitAt function is kind of like our current splitE, but again it
doesn't really match. And again, we could have a splitAtE that does match
splitAt on lists.
splitAtE :: t -> EventG t a -> (EventG t a, EventG t a)
And similarly for take and drop. If we throw in length, we have a Segment
instance. See
http://conal.net/blog/posts/sequences-streams-and-segments/
I think the splitE below is duplicate / cojoin.
Finally, I want to mention that I see the need for this sort of slicing up
of events and behaviors as a serious usability defect of the current
Reactive API. It's both tricky to get right and costly to get wrong. For
this reason, I am working on a redesign that simplifies and hides
shifting/slicing/aging of events and behaviors. Watch my blog for
developments.
- Conal
2008/12/2 David Sankel
Would partitionE be a better name for splitE? I'm thinking that splitE could be a more general function that doesn't chop off the right hand side of an event. My proposal, by example:
partitionE [(0,()), (5,())] [(2,()), (4,()), (6,()), (8,()), (10,())] => [ (0, ((), [(2,()), (4,())] )) , (5, ((), [(6,()), (8,()), (10,())])) ]
splitE [(0,()), (5,())] [(2,()), (4,()), (6,()), (8,()), (10,())] => [ (0, ((), [(2,()), (4,()), (6,()), (8,()), (10,())])) , (5, ((), [(6,()), (8,()), (10,())])) ]
Any objections?
David
-- David Sankel
_______________________________________________ Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive