Export (<&>)

[akhra]

I was surprised to not find this, then immediately more-surprised to discover that it only hit base in 4.11. Previous to that it primarily lived in Control.Lens, which is obviously a dependency we don't want.

I'm not completely sure what the ins and outs are of conditionally providing a local implementation for older base (or if we want CPP at all). If it can be done cleanly, I think it's worth adding. It's not something I reach for frequently, but once in a while it can be nice on a <- do line.

[snoyberg]

One way I see to achieve this is exporting the one from base with 4.11 or newer, and otherwise defining our own locally. That would have the downside of conditionally having name collisions with lens. The other is only exporting it with base 4.11 or newer, which will result in an inconsistent interface (something I'd like to avoid). I'm weakly -1 on providing this as a result, as neither option seems that good.

[akhra]

Hmm. So, as motivation, this is real production code:

main = do
  cfg <- getConfig
  logOptions <- logOptionsHandle stderr True
    <&> setLogUseColor (cfg ^. logging . color)
      . setLogUseLoc   (cfg ^. logging . debug)
      . setLogMinLevel (cfg ^. logging . debug & bool LevelInfo LevelDebug)
  withLogFunc logOptions $ main' cfg

I think I'm +0.75 on the conditional re-export. Ultimately your call tho.

[akhra]

That last line wasn't 100% clear... I'm entirely agreed on not having an inconsistent interface, leaning strongly toward conditional name collision with lens. In my particular case I'm already importing lens for (.~) so it's not a burden either way, but in general I think (<&>) is worth providing, particularly since (&) is already there.

[snoyberg]

Alright, I'm fine with the conditional name collision, it'll definitely come up again in the future. Want to send a PR?

[akhra]

Sure! I'll take care of it tomorrow (I'm on Pacific time and bad at going to bed).

[snoyberg]

Fixed by #120