[PD-dev] may have figured out scope

[Jonathan Wilkes]

----- Original Message -----

> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: "pd-dev at iem.at" <pd-dev at 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:
> 
> 1) keep symbols global by default

That's what I said below.

> 2) 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).
>> 
>>  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
>