Comments (7)
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.
Related Issues (20)
- struct->vector isomorphism HOT 5
- lens-zoom examples shouldn't use isomoprhism lenses
- Add digit->char isomorphism
- There should be a test for the cond-lens error case.
- There should be a test for the string-split-lens case where the input violates the lens laws HOT 2
- struct->struct lens? HOT 1
- Rethink unstable collection? HOT 2
- Test `lens-compose` / `compose` relationship HOT 1
- using append* n times vs. flattening a nested list of a given depth HOT 9
- Matrix lenses? HOT 2
- Disarm and re-arm syntax objects within srcloc-lens setters HOT 1
- Modulo lens HOT 3
- Struct inheritence and lenses HOT 32
- How should we name lenses for improper syntax lists? HOT 6
- separate tests into `lens-test` repository HOT 13
- Add prisms or other functionality that tests a lens's applicability HOT 4
- lens-join/* functions produce non-lenses when views overlap HOT 2
- Docs: Is the "last set wins" law right (strong enough)? HOT 3
- Waffle.io has closed HOT 1
- Add seemingly missing (list-filtered-lens) function. HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lens.