Would it make sense to add a lens structure with a prop:procedure that allows it to be used as the getter? about lens HOT 7 CLOSED

Currently lenses are just functions that returns a setter as well as a value. The prop:procedure approach requires making lenses structs instead which wrap their two components, which means all the lens composition and convenience functions need to unwrap the lens into its pieces to work with it. I'm not really sure which approach is better. Maybe it would make sense to consider these kinds of lenses "applicable lenses" and have some sort of lens->applicable-lens function?

(define applicable-first-lens (lens->applicable-lens first-lens))
(applicable-first-lens '(1 2 3)) ; -> 1

But now there's two kinds of lenses the library and users have to worry about, and keeping them straight would add complexity.

from lens.

In my pull request the lenses that are still functions still work as lenses, and the "applicable-lens" is a struct which holds the same function that the lens would have been without the struct. So yes these applicable-lenses will have to be unwrapped, but into one piece, not two. Sorry I didn't make that clear here. So (make-lens/struct getter setter) would be defined as (lens->applicable-lens (make-lens/proc getter setter)), where make-lens/proc is what is currently called make-lens, and lens->applicable-lens simply wraps the one value in the lens struct, so lens functions doesn't have to convert a getter-setter pair into a lens function and back again; that's taken care of just once by the existing make-lens/proc function, and after that lens functions don't have to worry about that.

In my pull request the lens functions return "applicable-lenses," but I could change that back if you want.

from lens.

Are the lens composition/viewing/transforming/etc. functions now expected to work with both lens procs and lens structs? This would effectively double the number of possible inputs and test cases lens manipulating functions would need to handle. Unless perhaps the library requires you to only use the lens structs and considers lens procs an implementation detail.

from lens.

Yes, but it doesn't add much complexity at all.
It means there's a function get-lens-proc which turns either a lens struct into a lens proc or leaves a lens proc how it is.

(define (get-lens-proc lns)
  (match lns
    [(lens proc) proc]
    [(? procedure?  proc) proc]))

And since all the other lens functions go through let-lens, let-lens has to be modified to use get-lens-proc:

(define-syntax-rule (let-lens (view setter) (lens . args) body ...)
  (let-values ([(view setter) ((get-lens-proc lens) . args)])
     body ...))

And of course I had to modify lens/c to accept both kinds of lenses.
And those changes are basically it, in the sense that that's what I needed to do to "double the number of possible inputs" for lens-manipulating functions.

The rest of the pull request is modifying the functions that return lenses to return applicable lenses, and of course tests and documentation.

from lens.

See #4

from lens.

Would you like me to split the pull request into two commits, one for allowing applicable lenses, and another for making lens functions return applicable lenses?

from lens.

Closed by #5

from lens.