[PD-dev] may have figured out scope

[Hans-Christoph Steiner]

It seems that the way to handle this would be to replace $0 more directly:

1) keep symbols global by default
2) add technique for marking symbols as local, like [local foo]

By removing $0 you remove the part that makes it obvious that a given symbol is local.  That seems like a bad tradeoff to me.

.hc


On Nov 16, 2012, at 1:21 AM, Jonathan Wilkes wrote:

> 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
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev