[PD] [qlist] and locality

[Alexandre Torres Porres]

not confusing, thanks


2014-04-03 19:54 GMT-03:00 Roman Haefeli <reduzent at gmail.com>:

> 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
> >
> >
> >
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140403/671509d9/attachment.htm>