Jacqueline Firth

That would work, but unhygienically relies on assumptions about lens names which I don't like. Maybe we need something similar to `struct-info` instances for lenses so we can do this...

Should `struct/lens` define that as well? Then the "leaf" structs don't need to be defined with struct/lens/nested, or even struct/lens (as someone could define it with `define-struct-lenses`). ``` racket (struct...

So a primitive like `(define-struct-nested-lenses player [pos position] [vel velocity])` could be what `struct/lens/nested` expands to ``` racket (struct/lens/nested player ([pos : position] [vel : velocity]) #:transparent) => (struct player...

This could now build off of #243 to handle the actual lens definitions. `struct/lens` and `struct/lens/nested` (thinking that `struct/nested-lens` might be a better name for consistency with `*-lens` and `*-nested-lens`...

Thought: I don't like that this adds another `struct/*` form. Maybe `struct/lens` should just support it on its own: ``` racket (struct/lens player ([posn position] health attack defense)) ``` If...

That could also work, but I don't think we need it yet. The nested lenses created by struct/lens would only add one layer at a time, so it wouldn't use...

I see what you mean. Unfortunately though it doesn't work quite as smoothly when a struct has multiple fields of the same type, for instance a game with two player...

This might work to solve the multiple fields of the same type issue: ``` racket (define-nested-lenses [game-orbs game-orbs-lens] [enemys orbs-enemys-lens] [(player1 player2) (orbs-player1-lens orbs-player2-lens) [pos orb-pos-lens] [time orb-time-lens] [shots orb-shots-lens]...

I like the idea of lens names giving you some information about type, like `#` or `#`, but I don't think we need to distinguish by identity. I'm most in...

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...