jackfirth
Dict ref nested and dict pick lenses
If lens-set version made sure to preserve the type of dict, then even if viewing didn't it'd still obey the lens laws, so it's not a deal breaker. I think it'd make more sense if it did preserve the type though.
Would a lens-join/dict function like (lens-join/dict make-dict k lns ... ...) make sense?
Probably not, since when you actually go to create the dict you have to pict a concrete implementation like hashes or assoc lists. It would make more sense to have a lens-join variant for each of the concrete types.
It wouldn't make sense to abstract over those concrete dict types with a combinator like that? I guess with isomorphism lenses that might be unnecessary though.
It makes sense to abstract over types when accessing, but not when constructing, because in order to actually create a dictionary from a set of items you have to pick an implementation. There's no equivalent of (hash 'a 1 'b 2) for a generic dict.
Exactly. That's why the user would have to supply a constructor if they wanted to make a lens-join/their-dict-type combinator.
Ah, I see, I totally misread your suggestion and didn't see the make-dict argument.That makes sense, at the very least we could implement it just to remove duplication.
Should the make-dict argument take multiple argument-pairs like hash does or take one association-list argument like make-hash does? Having it take one assoc-list arg would be easier to implement on both sides (easier to implement lens-join/dict and easier for all users to implement their own make-dict functions), but having it take multiple arg-pairs would be more consistent. What do you think?
What if it took only the make-dict argument, then returned a function that took the keys and lenses as varargs? That makes it easy to define your own dict lens joiner, but also keeps the api consistent. On the other hand, that makes the api a bit more complex.