On Wed, Sep 25, 2013 at 4:23 PM, David Barbour <[email protected]> wrote:
> If we're just naming values, I'd like to avoid the complexity and just > share the value directly. Rather than having "foo" function vs. "bar" > function, we'll just have a block of anonymous code. If we have a large > sound file that gets a lot of references, perhaps in that case explicitly > using a content-distribution and caching model would be appropriate, though > it might be better to borrow from Tahoe-LAFS for security reasons. > The notion is to have a consistent way to map between "a" large sound file and "the" large sound file. From one perspective it's just a large number, and it's nice if two copies of that number are never treated as different things. > For identity, I prefer to formally treat uniqueness as a semantic feature, > not a syntactic one. > I entirely agree! Hence the proposal of a function hash(foo) that produces a unique value for any given foo, where foo is an integer of arbitrary size (aka data). We may then compare the hashes as though they are the values, while saving time. > Regarding your 'foo' vs. 'bar' equivalence argument, I believe hashing is > not associative. Ultimately, `foo bar baz` might have the same > expansion-to-bytecode as `nitwit blubber oddment tweak` due to different > factorings, but I think it will have a different hash, unless you > completely expand and rebuild the 'deep' hashes each time. Of course, we > might want to do that anyway, i.e. for optimization across words. > > Hashing is not associative per se but it may be made to behave associatively through various tweaks: http://en.wikipedia.org/wiki/Merkle_tree
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
