[PD-dev] may have figured out scope

[Jonathan Wilkes]

Ok, I may have figured out a trick to get some scoping capability
for "pd bound" symbol names, similar to the design Tim Blechmann
described in his Nova pdf[1] (but probably a much hackier implementation).

1) Make [declare] not complain when its initial args don't have a flag in front
of them, like [declare foo bar].  Also add a -global flag, (I'll explain later).
2) Possibly add a t_namelist to canvas's struct called "vars" or something
(though there might be other ways to do this) that collects these initial args
of [declare]
3) Add a convenience function called scope_symbol that takes a t_pd and
a t_symbol "s", and does the following: a) compare "s" to the symbols in
the vars namelist of the canvas that contains the object, b) if it's a match
then prepend the canvas name ".xblah" to "s" and return it, and c) if it
doesn't match go to the parent and repeat until you get to toplevel.

Now, at leisure revise code of objects that use pd_bind by putting scope_symbol
immediately beforehand.  For [receive], this is a single change.  For [send]
it's a bit trickier (I think you'd have to make the right inlet a proxy inlet in
order to get it to work best).

Anyway, once those two (or any other) objects are revised in this way, they
are backwards compatible with the way Pd currently makes everything
global, but the new behavior can be utilized simply by typing the symbol as
an initial argument to [declare] on the desired canvas.  When mixing
the old global behavior and the new, problems are unlikely to arise since the
most common way of sharing patches is as abstractions, and generally the
use of an abstraction doesn't require global variable interaction with the parent
patch.  In the rare case where conflicts do arise (and truly global variable needs
are rare IMO), [declare -global foo] would revive the old behavior regardless of
what's declared on the parents (i.e., an explicit declaration of global regardless of
the declarations on the parent).

This is the best compromise I can think of to a) obsolete $0, b) provide an easy
way for nested abstractions to communicate, and c) not break patches.

-Jonathan

[1] http://tim.klingt.org/publications/tim_blechmann_nova.pdf