The fact that they suppress unused identifier warnings is a more of burden on me the implementor of lens more than on users of lens as the only names we generate with _'s in them are for prisms.
And we exploit the fact that unused names that start with _'s don't give warnings, so that users who don't export the non-lens-based field accessors from their functions don't get complained at by the compiler.
The adoption of _Constructor for prisms though it can lead to unexported prisms has the benefit of being unobtrusive and taking up namespace that literally nobody was using in the entire ecosystem, letting us avoid qualified import hell. Not everyone is so sanguine about qualifying every import in their program. ;)
The convention was very uncomfortable for me at first, too, for the same reason it makes you unhappy, but all of alternatives take up names other people are using, collide between lenses and prisms, and are more verbose.
-Edward
On Fri, Aug 9, 2013 at 12:00 PM, Henning Thielemann
<schlepptop@henning-thielemann.de> wrote:
Am 09.08.2013 17:31, schrieb Dan Doel:
Here's another smart-ass remark, then: use lens and bifunctors. They
have great abstractions for these.
mapEither and mapPair are just two specializations of bimap. It also
has first and second which generalize mapFst, etc. And by the way,
everyone here (I think) has missed that you can also traverse these
things, but bifunctors also has that covered, with bitraverse.
The individual parts are applications of lenses, too. over _1 and over
_2 are mapFst and mapSnd. _1 and _2 function as traverseFst and
traverseSnd.
These generalizations seem to be more natural to me than Control.Arrow.
(However, identifiers with leading underscore are a bad idea, since they suppress "unused identifier" warnings in GHC. But I think I complained about that before.)