A dumb question: Where does the naming convention for _1pLens come from?

no real convention here, I'm happy to change the name. I originally wanted _1Lens to be named __1 but that method already exist.
_1pLens being the polymorphic version of _1Lens.
Or should we use ___1 and ___2 for the lenses? not sure what would be the name for polymorphic version then...

for reference, the Monocle library use first and second for the lenses on scala tuple:
https://github.com/julien-truffaut/Monocle/blob/master/core/src/main/scala/monocle/std/Tuple2.scala

I prefer lensTraversal to _traversal for this method. I don't like relying on using underscore to indicate the returned value is a lens. Take _head vs lensHead for example.

However, take note that I am a beginner user of lens.

This would mean the P2._1Lens would be renamed to lens_1. The polymorphic version could be lensp_1 or plens_1.

Your thoughts?

Lens is one kind of optics, Traversal is another, so lensTraversal would be confusing. so for _traversal I see only List.listTraversal or simply List.traversal as alternative naming.
Maybe @tonymorris could suggest a good naming convention for optics instances in functionaljava... :)

Ok, I was using lens as the package as a whole, like the Haskell lens package (e.g. Control.Lens.Iso).

For others learning about this information, there is lots of useful info on the Github lens library page, https://github.com/ekmett/lens.

I'm concerned about putting optic instances in the same classes. The reason is that it will cause cyclic references between packages/classes (e.g. PLens depends on List and List depends on PLens). In Monocle there is no such problem: optic instances are located in monocle.std package. What if we use the same strategy and create fj.data.optic.std package?

Also, what do you think about creating a new artifact functionaljava-lens with all fj.data.optic stuff in it?

That is a valid concern. However there is already many cyclic packages references in fj (eg. Monoid<->Stream). Scalaz solve cyclic references by putting all in a single package. For those reasons I considered all of fj to be a single 'package'.
I can move optic instances into their own package/artifact, the downside I can see is that it will be harder to find them. pro is that it will address @mperry concern about having a clear distinction for optics 'factory methods'.

Monoid and Stream are central entities in functional programming, while lenses are not (IMO). Lenses are great, but I think optic methods in "standard" classes will confuse people that are new to functional programming.
Regarding Scalaz: putting everything into a single package led to a huge jar (10 MB) which is not good at all. I would like not to repeat this mistake in functionaljava.
Anyway, this is just my personal point view, so I would like to hear other opinions.

Lenses (optics) are way more important to functional programming, in a practical regard.

I'd like to see them in their own package, but don't see the need for a separate artifact.

Another reason is that instances for List regarding things like Equal, Show, etc. are in those classes, rather than List.

@mperry so... do you suggest to put optics instances in Prism, Lens, Ptraversal and the like...? I think this could be practical...
if they are isolated in their own package, those 'orphan' optics that will be harder to find which will lower their practicality.