Skip to content

Add (and use) lenses for the Verifier, Reader, Share, and URIExtension

Jean-Paul Calderone requested to merge lens-for-caps into main

This improves some code working on values deeply nested in other structures. For example, one case of applyShareBitFlips was:

applyShareBitFlips (FingerprintBitFlips flips) = second flipFingerprint
  where
    flipFingerprint cap@(Reader{verifier = v@(Verifier{fingerprint})}) = cap{verifier = v{fingerprint = xor flips fingerprint}}

but with lenses can be

applyShareBitFlips (FingerprintBitFlips flips) = over (_2 . verifier . fingerprint) (xor flips)

Both do the same thing - reach into the tuple's reader's verifier's fingerprint and apply xor flips, then build a new tuple with a new reader with a new verifier with the new fingerprint and all other fields preserved. The lens version just does so more succinctly.

This uses TemplateHaskell to make the lenses. There's lore about TemplateHaskell spoiling compile times and I more or less believe it but tahoe-chk seems to be a small enough code base that it doesn't really matter.

On master, the average full build time on my system is 14.4 seconds and the average incremental build time (for a change that touches each type that now has a lens) is 9.0 seconds. On this branch, those times become 15.3 and 9.3. I didn't do the math but the difference looks statistically significant to me, but on the order of less than a second - doesn't seem worth fretting over right now.

Merge request reports