CODEWITHSUNDEEP
haskellhaskell-lensarrow-abstraction
sevo
sevo

Reputation: 4609

Lens or arrows for updating a tree structures?

I ran into an example (from 2010) of using arrows for XML manipulation

Are there advantages to arrow abstraction over more recent lens for use-case demonstrated there?

Upvotes: 2

Views: 264

Answers (1)

hao
hao

Reputation: 10228

Lenses and arrows are theoretical cousins, both attempts to create compositional, functional values that could act as both getters and setters. But, and this is a subjective opinion, I think that if you're on the fence you should use lens. It comes down to library support. Lens is

  • More actively maintained, with commits landing almost every day

  • Basically the same user interface (use . to smash lenses together to form new lenses vs. use . to smash arrows together)

  • Possible to lift arrows into lenses (sort of; more of a demonstration than anything)

  • Possible to lens into XML with xml-lenses

  • Filled with other goodies (like traversals and folds and isomorphisms) and helpers (think: lensing into generics, uniplate, MonadReader/MonadState)

  • Currently more popular in the Haskell community, with e.g. more people knowledgable and answering questions on Stack Overflow

One downside: lens is a big ol' package with gnarly types.

Upvotes: 3

Related Questions