Lambda the Ultimate

I appreciate the feedback.

My structures are more like objects which lack polymorphism since they have associated operations. I consider polymorphism as an overhead which should only be used if it brings some advantage.

Ian's paper seems to focus on efficiently retrieve fields at different levels of overloading. An alternative to the fallback mechanism, of course, is to copy the original values at lower levels in the hierarchy. This is supposing there are no updates to propagate, which I believe to be the case in dodo.

Likewise with namespaces/scope, a symbol is either present in the current namespace or else it defaults to its enclosing scope (which can default to its enclosing scope, etc.)
http://www.vpri.org/pdf/tr2011003_abmdb.pdf

Ah I missed that part. Yes, it could be useful for symbol lookup in a scope - but this may be resolvable at compile time and I am not sure the runtime would need a hash map at all.

In fact the paper mentions that the same symbol could be stored several times for different levels, what is the use of storing a shadowed variable? I must have missed something.

Yes, it could be useful for symbol lookup in a scope - but this may be resolvable at compile time and I am not sure the runtime would need a hash map at all.

From what I can tell, Ian prefers the bind-as-late-as-you-can approach. This is much less efficient for CPU-time, hence his assumption of a hardware implementation. A telling quote is this:

In the absence of hardware,
the approach presented in this paper could still be valuable
as a means to present and compare dynamic behaviours, or
as a concise notation for dynamic mechanisms to be com-
piled and run on stock architectures as part of the language
runtime support library.

As for your second point, I can't see what your referring to I'm afraid. There is mention of garbage-collection issues, including an unanswered question about spotting constant redirections (ie. references which will always get redirected to the same location)

I am referring to this:

Each additional key position (gained by increasing n by 1, for example) creates a new “dimension” or “taxonomic space” in which any number of new taxonomies can be created. These new taxonomies will all be orthogonal to (and completely independent from) those in other key positions (even if they share the same concrete keys).

If the dictionary entries are added and removed when entering and exiting a scope, this could be useful - a single hash map is needed.