No lens support

[Gurkenglas]

record uses lenses because, as he notes, they already solve the modification part of the record problem. Why don't you?

[jkarni]

That's a good question. I mention the idea briefly in the second-to-last paragraph of the blog post I just wrote about this. The primary reason is that I still don't know how to deal neatly with deletion if we were to use lenses. Deleting could be modifying with const Void. But we'd have to add another step to the normalization - in addition to sorting the list and removing duplicates, remove Voids. And I think that'd make things a little ugly and inconsistent, but in all honestly, I haven't investigated this fully.

The secondary reason is that this seemed slightly easier to code, and the approaches aren't (EDIT: was originally 'are') mutually exclusive, so I thought I'd do this first. Happy to add lens support, though. Maybe this issue should be the place for discussing adding it.

[Gurkenglas]

You mean a lens Modifiable field val val' old new => Key field -> Lens old new val val, where val ~ () means that the field is being added and val' ~ () means that the field is being removed? Void is the type with no inhabitants. (Perhaps then you could even get rid of Key field and let hashtag-tokens stand directly for the lenses?)

[jkarni]

Basically! Whether Void or () is largely irrelevant to me (for val'), since users should never see either one! That said, we probably want a type that's isomorphic to either, but our own and not exported, so users don't accidentally witness weird behavior.

[Gurkenglas]

If it's Void, how would you ever delete a value? You'd need to apply over the lens some a -> Void, which has no inhabitants.

[jkarni]

which has no inhabitants.

Except bottom :). But if that sounds bad - sure, then (). As I said, I think if it ends up mattering it's because we screwed up.

[Gurkenglas]

Why not tell the user that all the fields already implicitly exist with a value of type ()? It's basically equivalent to non. (In fact maybe you can even use non in your source?)

[jkarni]

Why not tell the user that all the fields already implicitly exist with a value of type ()?

That's an option, but then you still have to make sure that e.g. show behaves the same for deleted vs. never-created values. And in addition to show, ==, which is even worse because you'd like to compare values of different type!

As for non - it looks very promising, thanks for the link!

[Gurkenglas]

And then we add https://hackage.haskell.org/package/indexed-extras-0.2/docs/Control-Monad-Indexed-State.html and define a variant on %= which has type IxMonadState m => ASetter s t a b -> (a -> b) -> m s t () and possibly magically make the # tokens be the lenses and suddenly the jane example looks like

execBook :: IxStateT Identity (Book '[]) t () -> t
execBook = snd . runIdentity . flip runIxStateT emptyBook

jane :: Book '[ "name" :=> String, "age" :=> Int ]
jane = execBook $ do
  #name .= "Jane"
  #age .= 30

and then you can throw other state actions behind that into the same do block.

[jkarni]

That is beautiful :)

[jsdw]

This looks amazing - I'd second the notion that having lenses work out of the box with it would be awesome!