Nenad Rakocevic

It should be enough to link the cache array to the function's context node pointer. Though the issue is where to store the cache array node for a given path...

> 1. We could organize refinements cache as smth like this: [...] That's an interesting idea, though treating words as character arrays is not convenient nor the most elegant option....

Here is a quick description of the spec block precalculated cache format: ``` /more/args [node!] ``` `args` is an array of key/value in a `block!` for encoding every argument and...

> And offsets are currently held in path cache, correct? No, the path is just where the `args` node is stored for a call with refinements. The offsets are in...

Depends on what you want to store. Currently, it needs to store typesets, argument names (for error reports), argument name type (for different type of fetching, lit-word!, get-word!,...). So for...

> There's still an issue to find the function inside the path e.g. obj1/obj2/obj3/my-fun, but we can't cache it, can we? obj1/2/3 may refer to anything, so we have to...

I have edited the cache description to correct the vectors description. Here is what I propose for solving this: - As the cache block is basically a copy of the...

@hiiamboris About your hashing proposition, do you have a good solution for building up something as close to a perfect hash as possible? If you do and it takes very...

How do you handle collisions in that hashtable?

> Can you explain btw why binding requires murmur3? Because that's the hashing algorithm we use for the symbol table and contexts binding. A few months ago, we extended all...