`transformers` vs `arrows` packages

I just found the arrows package and it seems amazing. Why transformers is so much more commonly used over arrows?

Do you mean the arrows package (with an s)?

If so, I’d say it is because arrows are not very useful.

  • If you need fully dynamic programs you have to use ArrowApply anyway at which point you might as well use monads which are simpler.
  • If you do want static analysis you can get very far with applicatives (to be fair, I haven’t worked this out completely yet).
  • And if you really want to statically analyze the data-flow graph, you should not arrows anyway. Instead, you should use symmetric monoidal categories.
6 Likes

Thanks fixed arrow → arrows

This seems like a good explanation your second point Profunctors, Arrows, & Static Analysis

Meaning code like this isn’t possible using just applicatives:

getFriendsUsernames :: Id -> DB [Username]
getFriendsUsernames user = do
  ids <- getFriends user
  traverse getUsername ids

It is possible in pretty much the same way as they do with their free profunctors (and in the same way as I did with FRP in the link I included in my previous comment):

data DB a b where
  GetUsernames :: DB (Set Id) -> DB (Map Id Username)
  GetFriends :: DB Id -> DB (Set Id)
  Pure :: a -> DB a
  Ap :: DB (a -> b) -> DB a -> DB b

getFriendsUsernames :: Id -> DB [Username]
getFriendsUsernames user = 
  Ap (Pure toList) (GetFriends (GetUsernames (Pure user)))

I think there may be a drawback of using applicatives like this instead of arrows/profunctors. In particular, I think arrows could support sharing better. But I haven’t seen a concrete example of that yet.

Edit: Actually, it seems the traverse' function may be a problem for applicatives, because the signature would have to include a higher order function: Traverse' :: Traversable f => (DB a -> DB b) -> DB (f a) -> DB (f b), but then you wouldn’t be able to inspect that function that we’re traversing with. Although, it still remains to be shown that this is actually a problem.

I really hope the linear-smc library matures, because at the moment it’s almost completely undocumented. But every time I’ve tried to do “boxes and wires” with arrows, I’ve hit the problem that my target language doesn’t support arr.

In 2024 the Arrow typeclass is little more than a historical curiosity.

I’m more concerned with the fact that a critical component of our ecosystem, by the same author, has a bus factor of 1. ross's transformers :: hub.darcs.net

I have had no responses to pulls nor issues for transformers. Seems like github.com/haskell should take it over.

very few tickets have had any sort of interaction from the author, which is regrettable. One could view transformers as essentially “done”, but still some maintenance is needed from time to time.