let-lens shouldn't take an arbitrary expression whose tail call is a lens application

[jackfirth]

Instead it should take a lens expression and a target expression.

[AlexKnauth]

Why not?

I understand that you want to get rid of any possible perceived confusion or ambiguity for whether it returns 1 value or 2, but it seems to me that #14 is a much better way to avoid confusion about that.

[jackfirth]

This is in addition to #14, not instead of. This allows more flexibility in the implementation of how lenses are used to extract views and contexts from values. Fixing #14 would probably involve adding a lens-apply function or some sort that gives the view and context given a lens and target.

[AlexKnauth]

But once the potential confusion is removed by #14 , why not allow an arbitrary expression there?

By the way, another example of a use of an arbitrary expression in let-lens is this, using a my dotmethod meta-language:

#lang dotmethod racket

require lenses/applicable

dotmethod list? lst.ref(i)
  ((list-lens i) lst)

define lst1 '(a b c d)

let-lens [val ctxt] lst1.ref(2)
  values
    val          ; 'c
    ctxt("hole") ; '(a b "hole" d)

[jackfirth]

I don't want arbitrary expressions to be interpreted as lens calls, I only want lenses with targets to be interpreted as lens calls. If you were using non-applicable lenses after #14, it wouldn't make sense to say lenses can act as a functions only inside let-lens and aren't functions anywhere else, when instead I just treat them as arguments to let-lens.

[AlexKnauth]

Ok I see what you're saying now. I still think it would be useful, but it's not necessary, and you're right, it doesn't let you check that.