|Portability||non-portable (GHC extensions)|
New version using GADTs.
- Specialize def. of repeatedly. Could have an impact on invaders.
- New defs for accs using SFAcc
- Make sure opt worked: e.g.
repeatedly >>> count >>> arr (fmap sqr)
- Introduce SFAccHld.
- See if possible to unify AccHld wity Acc??? They are so close.
- Introduce SScan. BUT KEEP IN MIND: Most if not all opts would
have been possible without GADTs???
- Look into pairs. At least pairing of SScan ought to be interesting.
- Would be nice if we could get rid of first & second with impunity
thanks to Id optimizations. That's a clear win, with or without
an explicit pair combinator.
- delayEventCat is a bit complicated ...
- What if one used rules to optimize
- (arr :: SF a ()) to (constant ())
- (arr :: SF a a) to identity
But inspection of invader source code seem to indicate that
these are not very common cases at all.
- It would be nice if it was possible to come up with opt. rules
that are invariant of how signal function expressions are
parenthesized. Right now, we have e.g.
arr f >>> (constant c >>> sf)
being optimized to
cpAuxA1 f (cpAuxC1 c sf)
whereas it clearly should be possible to optimize to just
cpAuxC1 c sf
What if we didn't use SF' but
SFComp :: tfun> -> SF' a b -> SF' b c - SF' a c
- The transition function would still be optimized in (pretty much)
the current way, but it would still be possible to look inside
composed signal functions for lost optimization opts.
Seems to me this could be done without too much extra effort/no dupl.
E.g. new cpAux, the general case:
cpAux sf1 sf2 = SFComp tf sf1 sf2
tf dt a = (cpAux sf1' sf2', c)
(sf1', b) = (sfTF' sf1) dt a
(sf2', c) = (sfTF' sf2) dt b
- The ONLY change was changing the constructor from SF' to SFComp and
adding sf1 and sf2 to the constructor app.!
- An optimized case:
cpAuxC1 b sf1 sf2 = SFComp tf sf1 sf2
So cpAuxC1 gets an extra arg, and we change the constructor.
But how to exploit without writing 1000s of rules???
Maybe define predicates on SFComp to see if the first or second
sf are interesting, and if so, make reassociate and make a
recursive call? E.g. we're in the arr case, and the first sf is another
arr, so we'd like to combine the two.
- It would also be intersting, then, to know when to STOP playing this
game, due to the overhead involved.
- Why don't we have a SWITCH constructor that indicates that the
structure will change, and thus that it is worthwile to keep
looking for opt. opportunities, whereas a plain SF' would
indicate that things NEVER are going to change, and thus we can just
as well give up?
|(#) :: (a -> b) -> (b -> c) -> a -> c||Source|
|swap :: (a, b) -> (b, a)||Source|
|sscan :: (b -> a -> b) -> b -> SF a b||Source|
|par :: Functor col => (forall sf. a -> col sf -> col (b, sf)) -> col (SF b c) -> SF a (col c)||Source|
|pSwitch :: Functor col => (forall sf. a -> col sf -> col (b, sf)) -> col (SF b c) -> SF (a, col c) (Event d) -> (col (SF b c) -> d -> SF a (col c)) -> SF a (col c)||Source|
|dpSwitch :: Functor col => (forall sf. a -> col sf -> col (b, sf)) -> col (SF b c) -> SF (a, col c) (Event d) -> (col (SF b c) -> d -> SF a (col c)) -> SF a (col c)||Source|
|rpSwitch :: Functor col => (forall sf. a -> col sf -> col (b, sf)) -> col (SF b c) -> SF (a, Event (col (SF b c) -> col (SF b c))) (col c)||Source|
|drpSwitch :: Functor col => (forall sf. a -> col sf -> col (b, sf)) -> col (SF b c) -> SF (a, Event (col (SF b c) -> col (SF b c))) (col c)||Source|
|Produced by Haddock version 2.3.0|