sl-sh-dev/sl-sh

Unison inspired function hashing and its use in library code

Opened this issue · 0 comments

the unison programming language hashes everything including inputs and "because functional" you can often just serve cached return values for functions. I'm not as interested in the "only doing computation once" bit , but I think Making it such that identical functions have identical hashes is a very interesting idea. Anyway that's neat. But the idea that there's only ever one hash for like (fn (x) (+ 1 x)) is interesting from a dependency management perspective?

With SL db we could come up with a hashing function for SL sh code. And this hashing idea is interesting. Maybe? My whole goal with SL sh was to make it possible to write sane library code in a shell environment... could your dependency management be done in a key value store?

What if the deps for your language were this huge accretion of all the functions and the hashes they mapped too? Or in a more sensible like. Tree shaking sort of way your program is only the subset of hashes that your particular script uses.

Could we somehow smooth it out so you're not just going insane updating every single hash for every single function? Could you semver a library that internally does the hashing thing to hide that complexity? How would aliasing work so you're not using hashes in literal func calls?

If every single directory had some sort of lock file and an awesome tool to deal with updating the alias to hash mapping? Could we also get some of the benefits of unison regarding renaming functions being trivially easy?

Ultimately if a dependency is just a hash would that make library code simpler and secure?