That looks neat. Making me fall in love with Haskell again which I want to avoid as I can’t use it at work ;)

You could add a monoid instance which would be useful (for one example) if the animation produces a matrix transform then you could combine two animations that produce transforms. For example a rotation and a move. I’m sure there are other good monoid animations. Strings would be a simple example I guess.

This is almost exactly how reanimate generates animations with Haskell: https://github.com/Lemmih/reanimate

Animations are frames over time and can be composed using 'seqA' and 'parA' combinators.

One thing I realized that seq'ing too many things might be bad for performance. As I understand it,

   foldr1 (\x y -> ((x `par` delay 1) `seq` y)) $ map pure [1..]

Would require more and more comparisons over time. Is there some sort of codensity like trick that you can do? Or is this something the user of the library would worry about if it came to that. Or just have a redundant API.

pedantic stuff:

typo here:

  seq (f, Maybe df) (g, dg) t

s/Maybe/Just/

and `par` should be

  par :: Anim a -> Anim b -> Anim (a, b)
  par (f, df) (g, dg) = (\t -> (f t, g t), max <$> df <*> dg)

---

i'm not sure about `par` - if my understanding of Anim is right, it'll take the shorter animation over its specified duration. what if it was something like:

  par a@(_, da) b@(_, db) = (ab, max <$> da <*> db)
    where ab t = (a `at` t, b `at` t)
  
  
  at :: Anim a -> Duration -> a
  at (f, Nothing) t = f t
  -- freeze when t exceeds dur, i.e. the animation is done
  at (f, Just dur) t = f (min dur t)

might be less elegant but i'd expect the combinator to respect an animation's duration.

or is that not what the duration represents? i.e. is this correct:

  stretch :: Float -> Anim a -> Anim a
  stretch factor (f, dur) = (\t -> f (t / factor), (factor *) <$> dur)

Thanks. I should have just clarified that I wanted to communicate the idea. I didn't expect to get it right first try.

Maybe I'll try and make a small library of it if there isn't already. I've never posted something on Hackage.

Replying to your edit:

As I was writing it my headspace was that the duration was for seq to know when to switch. I wasn't really thinking about stopping the animation too.

(I also notices that my seq is wrong. The subsequent animation should start at the beginning, so it should be `g (t - df)`, not `g t`

I believe you are correct. Your implementation is more at the heart of what I wanted to show. . The main point I wanted to get across was the interface itself.

it's a nice idea, i was just in a nitpicky mood :)

I am literally too dumb to know what you typed... and then all of the following comments.

It is like you are speaking in Martian or something.

Haskell is effectively impenetrable to me.

I dunno, I prefer to call it too practical. Lets just do terrestrial programming.

Something like this?

  @keyframes ball{
    0%{  left:50px; top:100px;width:0px;  height:0px  }
    10%{ left:50px; top:90px; width:20px; height:20px }
    20%{ left:50px; top:90px; width:20px; height:20px }
    30%{ left:300px;top:50px; width:100px;height:100px}
    50%{ left:300px;top:50px; width:100px;height:100px}
    60%{ left:200px;top:50px; width:100px;height:100px}
    90%{ left:250px;top:100px;width:0px;  height:0px  }
    100%{left:50px; top:100px;width:0px;  height:0px  }
  }

https://jsfiddle.net/gaby_de_wilde/eoj875qr/

I thought so too, but Haskell was an object of adoration and envy for me long enough for me to become hooked.

If Martians visited Earth, surely you'd want to learn their language. :)