Should lenses have names for printing?

[AlexKnauth]

Should lenses be able to have names for printing?
Would it make any sense to turn make-lens into a macro so that it can infer names? (this won't break backwards compatibility by the way if it expands to the procedure)
Would it make any sense to (when not given a name) give lenses random lens1234 names so that they can be distinguished by printing?
A lens-rename procedure?
A (make-lens getter setter #:name name) keyword argument?

[jackfirth]

I like the idea of lens names giving you some information about type, like #<lens:list-ref> or #<lens:composed>, but I don't think we need to distinguish by identity. I'm most in favor of a lens-rename procedure approach. Make something like lens-add-type-name? So this happens:

> (lens-add-type-name "list-ref" lens-expr)
#<lens:list-ref>

I'm not sure if we should expose this however. Maybe for now just use it in all our internal functions?

[AlexKnauth]

I was thinking of (lens-rename lens symbol) and to be consistent with (procedure-rename proc symbol). Why not expose it though?

[AlexKnauth]

I meant "why not", not "why now"

[jackfirth]

Yes that makes more sense to use a symbol.

Thinking about it, I haven't got a good reason not to expose it and it makes sense to do so. Nevermind about that point.

[AlexKnauth]

Would it make sense to allow names to be any arbitrary value, to be formatted with "#<lens:~a>"? So for instance, #<lens:(list-ref-lens 4)>? Contracts allow names to be arbitrary display-able values.

[jackfirth]

Possibly. What are some good ways to name lenses we make? #<lens:(list-ref-lens 4)> looks kind of strange to me.

[AlexKnauth]

Would it look better with a space instead of a colon?

[jackfirth]

Yes. Is it really a good idea to do this though? What if the values used in constructing the lens aren't printable?

[AlexKnauth]

What do you mean? Do you think someone will do

(struct thing ()
  #:methods gen:custom-write
  [(define (write-proc a b c) (error "not printable"))])
(lens-rename some-lens (thing))

? And expect it to work?

[jackfirth]

I'm less worried about something like that, and more worried that something like hash-ref-lens would construct a really ugly-printing lens. Additionally, printing the type makes a ton of sense and is very consistent with things like procedure-rename, but printing the values used to construct it is more for data than for objects. Procedures created with compose don't print the procedures they were made with.

[AlexKnauth]

I'm not saying the name couldn't be a symbol, just that it doesn't have to be. I was looking at contracts and how they print and deal with names.

[AlexKnauth]

Wait why would hash-ref-lens print as ugly? It would be #<lens (hash-ref-lens 'a)>, and it would be more complex for more complex keys, but hash keys aren't normally that complex, and when they are, you can just rename it to a less useful name if you want.

[jackfirth]

Wouldn't it be #<lens:hash-ref-lens a>? Anyway, what if it only printed the value if it was some simple atomic piece of data, like a number or symbol? So (hash-ref-lens 'a) would print #<lens:hash-ref-lens a> but (hash-ref-lens some-procedure) would print #<lens:hash-ref-lens> instead of #<lens:hash-ref-lens #<procedure:some-module-path.rkt>>

[AlexKnauth]

No:

> (printf "#<lens ~a>" '(hash-ref-lens 'a))
#<lens (hash-ref-lens 'a)>
> (printf "#<lens ~a>" `(hash-ref-lens ,add1))
#<lens (hash-ref-lens #<procedure:add1>)>

[AlexKnauth]

About composed lenses, I am planning on using 'composed for the name, not the whole thing with an s-expression and the arguments. That's what I do in #214 , so that it prints as #<lens composed>.