leftToMaybe/rightToMaybe

[Edward Kmett]

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 at 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.)
>
>
>
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130809/c33bee13/attachment.htm>