feat: port diff implementation from gen.jl (4/n)

[sritchie]

This PR ports more of the diff.jl implementation over from Gen.jl: https://github.com/probcomp/Gen.jl/blob/master/src/diff.jl

This is not complete, but gives us a base that supports the dynamic language and lets us start moving toward proper support for argdiffs on the interfaces that need it.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (868346a) 71.88% compared to head (9d900a8) 72.15%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #56      +/-   ##
==========================================
+ Coverage   71.88%   72.15%   +0.26%     
==========================================
  Files          20       20              
  Lines         996     1009      +13     
  Branches       24       25       +1     
==========================================
+ Hits          716      728      +12     
  Misses        256      256              
- Partials       24       25       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[littleredcomputer]

Does this interface need to be total, in the sense that every object in the universe should support get-diff and strip-diff?

[sritchie]

My thought was that if it was, we could gradually add support for this and gracefully fall back for cases we hadn't added yet. Here is the corresponding Gen.jl code: https://github.com/probcomp/Gen.jl/blob/master/src/diff.jl

[littleredcomputer]

I can see your point. Looking here, it seems to me that the Julia code lets the arguments carry the Diff nature in their types, but then uses a macro to enable such things to silently enter unary and binary operations. I could see it either way.

The PR is fine of course, but I'm curious as to how you will implement the generic operations so that they can transport the "joint difference" of the arguments to the result. I'd still argue for testing the arguments with satisfies? rather than adding the default case, or if you're going to use multifns à la Emmy then you could add defmethods for all the possibilities of diffed and undiffed arguments. An interesting case!

[littleredcomputer]

LG, but consider the question of whether

• (extend-type Object ...)
• (defmethod get-diff :default ...) or
• (satisfies? IDiff)
  would be best for Gen, since I sometimes fret about which approach is best. in CLJS, the extend-type approach adds the implementation to a map of types to implementations which has to be consulted when the function is called, so I think it's the least attractive of the implementations, unless that is consistent with the spirit of Gen

[sritchie]

@littleredcomputer , @zane pointed out that satisfies? is actually quite slow, so I think the default impl might be the way to go here. I'm going to keep this as-is, and then we can do a pass and potentially try and remove all satisfies? calls if and when it matters.

[littleredcomputer]

@littleredcomputer , @zane pointed out that satisfies? is actually quite slow, so I think the default impl might be the way to go here. I'm going to keep this as-is, and then we can do a pass and potentially try and remove all satisfies? calls if and when it matters.

Perhaps, but I wonder how Clojure can conclude that the default implementation is applicable faster than satisfies? could say no. Might be worth it (to me) to understand that better.