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
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).
- 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@iem.at http://lists.puredata.info/listinfo/pd-dev
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Monday, November 19, 2012 2:35 PM Subject: Re: [PD-dev] may have figured out scope
It seems that the way to handle this would be to replace $0 more directly:
- keep symbols global by default
That's what I said below.
- add technique for marking symbols as local, like [local foo]
What does [local foo] do different than [declare foo]? I assume with your approach you miss out on the feature of Tim's design that let's you declare foo for the parent and have the child communicate with it (something you can only do currently by passing $0 as an abstraction arg which is ugly and cumbersome). (Otherwise it would sound like exactly the same design I proposed.)
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.
I'm not removing $0-- as I said my solution is backwards compatible. Replace canvas name ".xblah" with "$0" in what I wrote and it works exactly the same.
One more question that applies to any system of scoping-- how do you apply it to the message box? I forgot about that aspect when I wrote the OP.
-Jonathan
.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).
- 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).
- 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@iem.at http://lists.puredata.info/listinfo/pd-dev
On 11/19/2012 09:28 PM, Jonathan Wilkes wrote:
----- Original Message ----- What does [local foo] do different than [declare foo]? I assume with your
i would mainly object to [declare foo] because it seems to impose a hierarchy between the things you can [declare] and pushing global/local namespaces to the top, without any good reason. i'd thus go for something like [declare -localvar foo].
I'm not removing $0-- as I said my solution is backwards compatible. Replace canvas name ".xblah" with "$0" in what I wrote and it works exactly the same.
you are talking a lot about "canvas", which in my understanding means, that you could have a variable that is local to a subpatch. currently $0 is local only to an abstraction and is shared between subpatches. is there a specific reason for this or is it just a slip of words?
One more question that applies to any system of scoping-- how do you apply it to the message box? I forgot about that aspect when I wrote the OP.
for me "message local" applies to local for a specific message (that is: [1, 2( | [$0-$1( could evaluate to "2352-1" and "4321-2".
i see little use to that, which is probably the reason why $0 doesn't expand at all in messages. i also don't know exactly what the problem is you are envisioning. something like that? <abstraction> [declare -localvar read] [; filereader read /tmp/bla.txt( [r filereader] | [textfile] </abstraction> and having two <abstraction/>s in your patch and clicking on the msgbox in one of them resulting in "[textfile]: no method for local 'read'" in the other???
fgasdr IOhannes
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-dev@iem.at Cc: Sent: Monday, November 19, 2012 5:32 PM Subject: Re: [PD-dev] may have figured out scope
On 11/19/2012 09:28 PM, Jonathan Wilkes wrote:
----- Original Message ----- What does [local foo] do different than [declare foo]? I assume with your
i would mainly object to [declare foo] because it seems to impose a hierarchy between the things you can [declare] and pushing global/local namespaces to the top, without any good reason. i'd thus go for something like [declare -localvar foo].
I don't care for the "-flag value" syntax. So if Hans is suggesting [local foo] to avoid that problem (or because he thinks its cleaner to have a new class for this) then I prefer [local foo] to adding another flag to [declare].
I'm not removing $0-- as I said my solution is backwards compatible.
Replace
canvas name ".xblah" with "$0" in what I wrote and it
works exactly the same.
you are talking a lot about "canvas", which in my understanding means, that you could have a variable that is local to a subpatch. currently $0 is local only to an abstraction and is shared between subpatches. is there a specific reason for this or is it just a slip of words?
No, there is a difference there in terms of subpatches, I just forgot about that case. I'm not sure exactly how Tim's method works, and whether you could declare inside a subpatch (which would be handy, actually). I'll go back and re-read it.
One more question that applies to any system of scoping-- how do you apply
it
to the message box? I forgot about that aspect when I wrote the OP.
for me "message local" applies to local for a specific message (that is: [1, 2( | [$0-$1( could evaluate to "2352-1" and "4321-2".
i see little use to that, which is probably the reason why $0 doesn't expand at all in messages. i also don't know exactly what the problem is you are envisioning. something like that?
<abstraction> [declare -localvar read] [; filereader read /tmp/bla.txt( [r filereader] | [textfile] </abstraction> and having two <abstraction/>s in your patch and clicking on the msgbox in one of them resulting in "[textfile]: no method for local 'read'" in the other???
I'm talking about scoping the symbols that pd binds to "things".
[; foo bar(
So I'm referring to "foo". The remaining use for the [; foo] syntax that I see is sending to a bunch of different send-names in one go-- for example, when initializing a bunch of values in a patch with [loadbang]--[; foo 1; bar 2; etc.(
-Jonathan
fgasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Hans-Christoph Steiner -
IOhannes m zmölnig -
Jonathan Wilkes