Hey @samth, I’m getting the following package dependency when building typed racket:

raco setup: found undeclared dependency:
raco setup:   mode: build (of documentation)
raco setup:   for package: "typed-racket-doc"
raco setup:   on package: "web-server-doc"
raco setup:   from document: "ts-reference"
raco setup:   to document: "web-server"

Do you think this is right, or maybe my build is wrong?

I get the same error.

Is there (or is there a reason I’m missing why there shouldn’t be) a lens for hashes that uses a default value? Like a hash-ref-lens/default ?

@samdphillips I don’t remember, but I’m guessing there isn’t one because such a lens can violate the lens laws. If you get-then-set, you could change what the original hash was.

(it’s been a long time since I worked on the lens package)

Ok I figured it was related to the lens laws, but wasn’t sure which one potentially.

Whichever one is (lens-set l v (lens-view l v)) == v, assuming I remembered the argument order correctly

Gotcha

There’s no way for a ref-with-default to satisfy that, since it can’t tell the difference between a hash with no value and a hash with a value equal to the default

Honestly it’s still a really useful feature so I want some way for optics to deal with that kind of thing. Will have to wait for the next time I work in that area.

I noticed it wasn’t there one of the last times I used lenses, but need it today. I’m pretty much using lenses to query “big” json documents.

Fortunately lenses are simple enough to write a usable (for me) ref with default

I think another good strategy you could use is to normalize your json docs. So before doing any queries with lenses, first traverse the doc and fill in default values.

is the lens-y code you’re writing open source btw? I’d like to add a link to it to my list of use cases

If there was a hash-ref/maybe and hash-set/maybe with signatures: hash-ref/maybe : [Hashof K V] K -> [Maybe V] hash-set/maybe : [Hashof K V] K [Maybe V] -> [Hashof K V] Where “set”-ing to None is like hash-remove, would a hash-ref-lens/maybe follow the lens laws?

Not yet. Right now I’m just writing some hacky automation around a web api. So for the most part I’m just writing lenses for the parts I need.

@alexknauth I was wondering that myself. I guess if None was disjoint from V it seems plausible?

@alexknauth It would follow the laws, but it wouldn’t make the code using that lens any simpler. Such a lens would require the user explicitly treat “present and equal to the default” differently from “absent”, which isn’t what Sam’s case wants to do.

@samdphillips I think the Maybe type in alex’s example is always a wrapper, so it’s more like (or/c none? (some/c V))

Oh yeah. I was thinking of TR (U v #f)

except in vanilla Racket

I’m pretty sure that the dependency should just be added, and the dependency mismatch will block snapshot builds if not fixed, so I’ve pushed the addition (and I trust that someone will revert if that wasn’t the right idea)

And actually I’ve given it more than 1 minute to think on it would still be complicated.

What I want to do to address this kind of problem is define some notion of normal forms and normalizers, and then allow optics to be either “exact” (which is what lenses are like now) or “inexact” (which are like lenses that almost follow the laws, but they might normalize data when they’re used)

there’s a lot of really useful kinds of data conversion / querying / traversal logic that doesn’t promise to leave the source unchanged, it just promises to put it into some normal form and data that’s already in normal form is always left unchanged

As purely ergonomics example, if I was doing this in python I would do something like: json_doc.get('A', {}).get('B', {}).get('C', some_suitable_missing_value)

Right and that’s a very reasonable, convenient, and practical interface

Makes sense. Thanks.

If you adjust your definition of “equality” to treat the absence of a value equivalent to the presence of the default value, then such a lens can be lawful