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