IRC channel logs
2025-01-24.log
back to list of logs
<dckc>timing attacks? not afaik. Having non-enumerable collections is handy for rights amplification, as I mentioned. <dpk>but you can get back to a rights-amplifiable (if that's a word) weak map with no iteration by adding a simple, opaque wrapper around a weak map that does support iteration <cwebber>and I think generally already that's what you want to do <cwebber>since you want to expose the sealer and unsealer and etc as separate capabilities <dpk>but you pay for it in performance with an extra memory indirection on every access, worse cache locality, etc. <dpk>sigh. Scheme wants to be an Algol but it’s stuck being half of Python <cwebber>facets are common across ocap systems <dpk>should you have to pay a performance cost for security, though, morally speaking? the answer is no, i think <dpk>you also shouldn’t have to pay a performance cost for dynamic type-safety, which is a much broader problem in Scheme and ultimately has the same cause <dpk>what i want is for any non-record disjoint type to be clonable to a distinct type that exposes the same basic interface <dpk>ML-style modules would be the way to do it, but R6RS decided to go with something much less interesting <dpk>and R7 small only confirmed that decision <dpk>so you could import e.g. the ‘vectors’ module multiple times with different parameterization, and it would generatively create multiple vector types <dpk>or, in this case, you import the weak maps module with your own parameterization, it generatively creates a new weak map type, and you then just don’t re-export the iteration procedures <dpk>just something more i’d do if i could redesign Scheme from scratch