On Thu, 30 Dec 2004, Miller Puckette wrote:
Right, I'm rofgetting, the "pd $0-x" ends up naming the canvas "pd-$0-x" which is hard to generate as a symbol. My problem with "namecanvas" is that one can free or rename the patch (or just free the namecanvas object itself in the patch) and crash Pd. I still haven't found a clean alternative... so for now, I'll have to keep the mis-designed "namecanvas" object around for the forseeable future.
Hey, why not have _local_ variable-tables ? That would be a real cool feature, especially as it would eliminate symbol-table pollution by temporary names when instantiating the same abstraction many many times, especially dynamically. Each patcher would have some kind of variable-table which would be destroyed as the same time as the patcher, just like an object's state is destroyed at the same time as the object, and just like a C function's state is destroyed when that function returns.
The basic idea is to separate the registering of symbols (usually called "gensym" or "intern") from the setting/getting of values of variables. The reason why those two different things were conflated together was to save memory space, since those two tables typically had the same keys.
Historically, many systems have been implementing local variables in terms of a single global symbol-table, but for many reasons, few systems do it like that nowadays. The only remaining such examples I can think of are:
1. PureData 2. MAX 3. EmacsLisp
Most of the other Lisps and Lisp-inspired languages switched to having true local-variables during the 1970's. The only 1990's languages that were designed with an old-skool 1960's Lisp symbol-table are either:
1. Student homework in Compiler Theory courses (but only IF the prof doesn't forbid students from doing it)
2. That visual language called PureData.
Understood?
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju