You could write a more complicated check within memo that examined whether the arguments had been passed before. This would probably slow down lookup though and not give much of a net gain.
The problem which prevents this from working nicely with nil is that hash tables in Arc do not distinguish between the value nil and a key simply not being there. The workaround is to use a default value (generally a symbol returned by (uniq)) to guarantee uniqueness for the case when the key does not exist.
Actually I know why it happens and how to fix that. The question was more like "is it a bug or a feature?" I remember that PG suggested (but forgot where I read that) to store cons' in a table when you need to distinguish nil and absence of an element but why doesn't he use that technique (or any other) himself?
I think the simple answer is that he hasn't needed that feature. 'memo and 'defmemo are used in 5 places in news.arc and it doesn't look like any of those uses would benefit from allowing nil as a value.
If someone created an application that benefited from that feature then perhaps there would be reason to redefine 'memo.
This seems to be an important part of the Arc philosophy: add a feature only when its absolutely needed.
Only now I realized that you treat memo as some kind of the way to improve performance (do you?). What I used memo for is to make sure that function won't be called twice:
When I use lazy sequences (of symbols read from input port for example) based on these definitions I can't be sure that readc somewhere inside will never be called twice if I call force for an element of this sequence twice.
So I treat this as a bug. Or maybe I'm just wrong about what memo is for at all. Am I?
