-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
let-lens shouldn't take an arbitrary expression whose tail call is a lens application #26
Comments
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. |
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 #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) |
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. |
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. |
Instead it should take a lens expression and a target expression.
The text was updated successfully, but these errors were encountered: