Procedure names / trace keys

[jar398]

I have in my notes a to-do item 'Create issue for procedure names' which must have come up in conversation a couple of weeks ago. I think the question is: Python-metaprob and clojure-metaprob take two very different approaches to choosing the keys under which the return value of a procedure call is stored in the traces. Key choice matters quite a bit because it determines correspondence between traces and therefore the behavior of MH and presumably other inference computations. False positives and false negatives could both easily be problems: having return values correspond when they shouldn't, or fail to correspond when they should.

Python-metaprob got the return value key by asking the procedure what its 'name' is. The name was sometimes actually the entire source code for the procedure (but not including the environment), so calls to different procedures resulting from the same lambda-expression lined up even if they were called by different names. For clojure-metaprob the key currently comes from the name that the procedure has in the caller's source code, so e.g. in (foo x) the key is foo but in (block (define bar foo) (bar x)) the key is bar even though it's the identical procedure.

The clojure-metaprob solution was a 'quick hack' for expedience that became necessary when we decided that arbitrary clojure functions could act as metaprob procedures. I couldn't figure out how to get clojure's name for the function, so this other approach was adopted.

I think some problem was found with this approach but I don't remember what; thus this issue.

It would be nice to have some approach to key choice that is principled, i.e. not a hack. I don't know what that would be - the problem seems unfortunately underconstrained.

[zane]

Another way to phrase this is perhaps, "Document and standardize default racing behavior"?