[PD] [qlist] and locality

[Roman Haefeli]

On Don, 2014-04-03 at 18:32 -0300, Alexandre Torres Porres wrote:
> > Wow, you keep beating that horse after its dead
> > for quite a while by now
> 
> 
> > I don't think this debate is going lead anywhere
> 
> 
> please, cope with my lack of knowledge in computer science/languages
> jargons.

I'm sorry. I sure will (though I don't feel I have in any way less of a
lack of knowledge). Actually, I don't have any computer science
background myself. 

> All I'm doing is asking to learn more about it and get what you guys
> mean. I'm not debating, since I'm even stating I couldn't do it when I
> say I probably won't be able to grasp all the details and will just
> take the word for it...




> So relax, you keep misjudging before reading more carefully. I'm not
> looking for a debate, and I'm also saying I'm cool with Pd's
> workaround myself, so there's no personal frustration. As I said, I'm
> not even thinking about me as my concerns come from luring people into
> using Pd, while I'm already sold for it.
> 
> 
> Anyway, having said that, I'd appreciate if anyone could help me
> understand Pd's structure and developing issues. 

I think I can't answer that.

> For instance, I don't think I understand what "inconsistencies" mean
> in this context.

I try to explain some more. The confusion probably comes from the fact,
that a similar looking syntax is used for two relatively different
things in Pd. A $1 in an object box is substituted by the first argument
I give to the parent abstraction. If I create [myabs 0.3] and myabs
contains an [f $1], the value of $1 actually is '0.3'. If I have a
message box [bla $1( in the same abstraction [myabs], we actually don't
know yet what the value of this $1 is. Only when we send message to [bla
$1( we know what the value of $1.

[1.7(
|
[bla $1(

When I click the [1.7( message box, we know that the $1 in [bla $1( is
going to be substituted by 1.7. So far, so good.

We now have encountered two different $1s in the same abstraction. Once
it got substituted by 0.3 and once by 1.7, although both are written $1.
Confusing, isn't it?

I know that is nothing new to you at all as you most likely have used
dollar variables in both ways already. What I am trying to say is that a
$1 in a message box [bla $1( is a different animal from a $1 in an
object box [f $1]. Pd could have been designed to make this distinction
more explicit. It could have used # variables for message boxes and $
variables for object boxes. Then we would be able to do both with
message boxes, namely expanding to a parent's argument AND expanding to
an element of the incoming message, depending on whether we use the # or
the $ syntax.

[1.7(
|
[bla #1(

In our hypothetical Pd, #1 would be substituted by '1.7' as soon as we
click the [1.7( message box (as does $1 in the real Pd). Clicking on
[1.7( would output 'bla 1.7'.

[1.7(
|
[bla $1(

In our hypothetical Pd, $1 would hold the value of the first argument
given to the parent abstraction [myabs 0.3], in our example '0.3'.
Clicking the [1.7( message box would output a message 'bla 0.3'.
However, there is no such thing in the real Pd (yet).

In the real Pd, the $1 in the message box works totally differently from
the $1 in the object box. The canvas local-ID unique to each instance of
a .pd file (abstraction or patch) can be considered as an argument to
that abstraction or patch. Thus it can easily be accessed by $0 in
object boxes. 

When you propose that $0s in message boxes are substituted by the
canvas-local ID, then you want the function of the dollar variables to
be different depending on what number follows the dollar sign. You want
$0 to access an argument given to the parent, but $1 to be substituted
by the first element of the incoming message. That is where the
inconsistency happens: Why should the function be different based on the
value I put after the dollar sign?

In our hypothetical Pd, this would be a non-issue. You wouldn't expect a
#0 in message box to get substituted by the canvas-local ID. You would
use $0 for that. In the real Pd, we unfortunately don't have direct
access to the arguments of the parent from message boxes. When you ask
"Why can't a $0 in a message box be substituted by the canvas-local ID",
then you also should ask "Why isn't a $1 in message box substituted by
the first argument given to the parent?" The answer is that this is the
way Pd is designed. 

I'd prefer our hypothetical Pd, if it would exist. However, switching
from today's Pd to our hypothetical Pd would surely break compatibility,
which makes its introduction a bit less likely. Finally, I don't see any
other concise solution than our hypothetical Pd for the
$0-in-message-boxes problem.

I hope I didn't cause even more confusion.

Roman

 


> 2014-04-03 17:03 GMT-03:00 Roman Haefeli <reduzent at gmail.com>:
>         On Don, 2014-04-03 at 16:13 -0300, Alexandre Torres Porres
>         wrote:
>         > thanks for explaining it all
>         >
>         >
>         > > imagine trying to design something like that
>         > > which is also backwards compatible with the
>         > > crude namespacing tools that already exist in Pd.
>         > >  It's not possible
>         >
>         >
>         > ok, here's where I'm a bit confuse. You're not saying it'd
>         be
>         > impossible to make messages inherit the $0 value, are you?
>         
>         
>         Wow, you keep beating that horse after its dead for quite a
>         while by
>         now. It is _not_at_all_ about technical difficulties (probably
>         it is
>         indeed difficult, I don't really know). It's about breaking
>         consistency.
>         Expanding arguments of the parent is different from expanding
>         to
>         elements of incoming messages.
>         
>         While I understand your frustration to some degree, I don't
>         think this
>         debate is going lead anywhere, simply because of that fact
>         that I don't
>         believe any dev will deliberately introduce inconsistencies
>         just for the
>         sake of convenience. And yes, I understand the convenience of
>         $0
>         expanding to the canvas-local ID and yes, it would probably
>         make
>         patching simpler. I am very much with you in this respect.
>         
>         Roman
>         
>         
>         
>         
>         _______________________________________________
>         Pd-list at iem.at mailing list
>         UNSUBSCRIBE and account-management ->
>         http://lists.puredata.info/listinfo/pd-list
>         
> 
>