[Question] Any plan to support `Lens.lens` again?

[sectore]

@paf31 It seems that with v1.0.x lenses (Lens.lens) are not supported anymore (https://github.com/paf31/purescript-derive-lenses/blob/02457e610789263326b936ebdfa72edbb6599094/src/Main.hs#L84-L90). It was a big help to have a tool with purescript-derive-lenses to generate lenses.

What is the reason to drop this feature? Any plan to bring this feature back?

[EDIT] Would be nice to use props of latest purescript-profunctor-lenses to access record field with lenses :sparkles:

[EDIT 2] I would love to help on this. However, the question is, how can I get the information about a record by parsing a corefun.json file? I've checked thran as an example and it seems there is a lot to do. Or is there any other way to get similar results for generating lenses as purescript-derive-lenses did with Haskell before?

[paf31]

I wanted to port this to PureScript, and remove the dependency on the compiler, so I switched to using the CoreFn output. Since record lenses can be supported generically using prop now, as you say, it seemed unnecessary to support them here as well. Did you have a different use case in mind?

[sectore]

@paf31 Agree, prop is really great feature! However, imagine you have a deep nested record with a lot of fields to access (e.g. state of an application). To get or set any value using lenses is might be a good decision. For this a lot code has to be written to create this lenses, even with prop. And a tool like purescript-derive-lenses to generate this lenses would just be helpful.

[paf31]

For this a lot code has to be written to create this lenses, even with prop

I assumed you could just use prop inline, wherever you would previously have used the derived lenses. Is that too slow, or too much code?

With the upcoming proxy literal syntax, it should be very lightweight: prop @"foo"

[sectore]

@paf31

prop @"foo" looks fantastic!

Is that too slow, or too much code?

It is not about performance, it is about writing code for lenses "by hand", which was generated by previous version of purescript-derive-lenses.

Here is an example of program-imperatively-using-purescript to generate lenses from Game.Data.purs:

• All of the following lenses are generated by previous purescript-derive-lenses v0.10.5.1 (psc 0.10.x): https://github.com/sectore/program-imperatively-using-purescript/blob/psc-0.10.x/src/Lenses.purs
• Unfortunately with latest purescript-derive-lenses all of the following lenses have to be written "by hand" https://github.com/sectore/program-imperatively-using-purescript/blob/master/src/Lenses.purs

you could just use prop inline

What do you mean with inline? Something like this ⬇️ ?

-- BEFORE (derived lenses)
bossHP :: Lens' Game Int
bossHP =
  L._Game <<< L.boss <<< L._GameUnit <<< L.health

-- AFTER (inline)
bossHP :: Lens' Game Int
bossHP =
  L._Game <<< prop (SProxy :: SProxy "boss") <<< L._GameUnit <<< prop (SProxy :: SProxy "health")

[paf31]

@sectore Yes, that's what I was thinking, although it becomes shorter with @ literals:

bossHP =
  L._Game <<< prop @"boss" <<< L._GameUnit <<< prop @"health"

Of course, I'll take a PR to add back property lenses if you still think they're more useful, but it always seemed a bit odd to look in data constructors for possible object properties, when really we could be using any property at all.