On Fri, 2013-01-25 at 19:30 -0800, Jonathan Wilkes wrote:
So inside [blah] let's say I have this:
[r foo] | [print I_don_t_want_bob_to_trigger_this]
I share my [blah] abstraction with Bob, who creates a [blah] instance in the same patch where he has
[Click here to start my thing( | [s foo]
I suppose I don't know what "lexical hygiene" means. But I think you have to have a way to explicitly state that "binding symbol foo applies to >this< canvas and all of its children, but not to any parents". Do you have a way to do that without using the $0 kludge?
PD's behavior and the $0 kludge falls out of the design where there is a single namespace for s/r targets. It's a programming language where there are only global variables. This makes some things easy (communicating with other patches) and some things hard (keeping things private, duplicating code blocks without copies stomping on each other).
My design started from the presumption that all variables (names) are local to a scope. Each patch has its own "global" scope (which is the default for new names), and can have named scopes within it. This sort-of follows a model of "lexical scoping" that you see in languages like Lisp and Scheme where you can explicitly wrap a block of code in an environment where variables just local to that scope are declared. In MFP, a layer (subpatch) or group of layers can share a scope just among themselves, or can use the patch's global scope.
Again, this makes some things easy (cut and paste of subpatches without stepping on each other, management of names without $0-prefixes, knowing that your abstraction won't interfere with someone else's) and some things hard (broadcasting to every instance of a patch/abstraction, listening in on message traffic internal to somebody else's abstraction).
Back to your example: it wouldn't work as-is in MFP. The [s] would have to qualify the "foo" name, since it doesn't exist in the scope of the [s]. Let's say I make a [blah] in the patch with the [s] and I name it "blah_1". The [s foo] would need to be [s blah_1.foo] for it to get where you intend it to go. If you made 2 [blah] instances, "blah_1" and "blah_2", you would have to send to the one that you wanted the message to go to.
There are also use cases for "binding symbol foo applies to all instances of
this< abstraction", and possibly "all instances of abstractions from >this<
libdir" (though the latter may be overkill).
Yes, these are real use cases. I'm still trying to work out which ones are highest-value; you can't do either of these things in MFP right now.
Thanks, Bill Gribble
-Jonathan
At the same time, references to names that can't be resolved in the local scope do bubble up, so you can have more global names if you need them.
Thanks, Bill Gribble
On Jan 25, 2013, at 21:27, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com;
"pd-list@iem.at" pd-list@iem.at
Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
From: Bill Gribble grib@billgribble.com I am working on a pd-clone intended to explore a lot of the
topics in
this
thread. It's not fully baked yet -- the biggest working
patch is
a biquad
filter designer with pole-zero and freq response plotting --
but
I'm
particularly excited about the approach to namespacing and
scope
management,
which works a lot like hc describes. Patches have a set of
scopes
which can be
mapped onto subpatches (represented as layers, not separate
windows).
Name
resolution in send/receive elements works like you would want
it to.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that object, the
tree
of patches and scopes is crawled upward from the site of the lookup.
For
example, the (equivalent of) [s "foo"] first looks in the
scope of the
[s], then the patch-global scope of the containing patch, then in the application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"] would try to
find an
object named "foo", then find "bar" in its
patch-global
scope (or an object named "bar" within a scope named "foo" in
the current
patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r foo] inside
[blah] and
all of [blah]'s children to talk to each other. Then I want to share
my abstraction
with Bob who needn't worry about the send/receive names I used inside
[blah]
because they are guaranteed not to conflict with anything he does outside
the
scope of the [blah] abstraction (e.g., creating a [s foo] on the same
canvas where
a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble