Re: Soliciting criticism of memoize function

[Norman Ramsey <nr@...>]

 > True. You don't need to encode nil as stored as a result in the  
 > memoize table but it means that anything with a nil result will  
 > produce nil over and over again.

Indeed so.

 > > I'm reluctant to add something like encode and decode, which do actual
 > > work, and moreover which have to be explained.
 > 
 > Relatively speaking, the encode and decode are probably cheaper than  
 > the checks being done with select. Remember that assert does not  
 > compile out.

I haven't looked closely at the Lua VM since the ... construct was
introduced, so I don't really know what the select is likely to cost.
I would hope the compiler would be clever about it, but I don't know.
The assert is the other call I referred to.

 > > This is an area where I really don't understand the issues.  It sounds
 > > like what you're saying is that it's bad to have string keys because
 > > strings are not likely to be reused, yet the associations will clutter
 > > up the table.   But we have weak keys, so the strings and values can
 > > be collected, no?  What am I missing here?  Are you thinking that
 > > having results alive will keep the string arguments alive and in the
 > > table unnecessarily?
 > 
 > Basically weak tables are always a bit tricky and semi-weak tables are  
 > doubly so. Essentially weakness means that some of the keys and values  
 > won't be marked via the table and hence may get collected, but that  
 > word "some" is important to understand.

Yes.  I don't understand.  I have never understood.  It's one place
where I think both the reference manual and PIL fall down, because the
explanation is with respect to a model that's not written down anywhere.
I have long wanted a formal semantics of some fragment of Lua, and the
semantics of garbage collection is right up there with things that
I would like to see formalized.


Norman