New version using GADTs.

ToDo:

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

Random ideas:

• 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. work. E.g. new cpAux, the general case:

      cpAux sf1 sf2 = SFComp tf sf1 sf2
          where
              tf dt a = (cpAux sf1' sf2', c)
                  where
                      (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?