This leads to an interesting point - '$0' might recently have become more important than it was before because of the multiple-libpd-instances features in 0.46 - any libpd patch wanting to support multiple instances will need some $0-ish disambiguation.
The recursion problem (that Ico asked about) is this... if a message box has to set the "cuttent" canvas to itself, so that its messages can access $0, and if its message leads to another message box in another canvas, that second message box can't just bash the value of "current canvas" but rather would have to save the previous one (and restore it when done) so that, when control returns to the first message box, any further messages it wishes to send get its own $0 and not the bashed one.
A deeper question bothers me: what about $1, etc, too? What if we're in an abstraction and want to 'speak' to $0 in our calling patch? THe usual way of doing that is for the calling patch to instantiate the abstraction with $0 as an argument. Then the abstraction itself can access it as, say, $1. But that makes me think we need a way for the message box to be able to access $1 as well as $0.
It seems like this should either be something syntactic in messages themselves (that could have deep repercussions as that is at the very heart of everything), or else, perhaps, some kind of "properties" kludge, or perhaps (hopefully) there's a better way I haven't thought of.
Related: it would be nice if message boxs sprouted inlets for $ args ala Max. Even better if it could sprout multiple outlets so that one could send to multiple destinations without the need to use names at all. Even better if it could do tests and loops... oops, now we're writing a computer language. Should there be a 'generalized' message box that doesn't use binbuf_eval at all but rather gets a more spohisticated interpreter?
Yet another possible direction: the new "text" object could be given a way to access the contents of message boxes, so that people could write their own semantics any way they please.
Or externs could get some kind of pathway so that one could send message box strings to lua, etc.
Hmm, time for another Pd convention :)
M
On Wed, Sep 10, 2014 at 10:23:06AM -0700, Phil Stone wrote:
I can add nothing of substance to this argument, but agree fully with Ivica. In many years, I have yet to hear a convincing argument why $0 cannot be recognized as the unique canvas identifier inside a message box. On the plus side, it would eliminate a great deal of cruft hanging off of message boxes used to kludge $0 into messages, something which occurs constantly, at least in my patches.
Phil Stone UC Davis
On 9/10/14, 10:08 AM, Ivica Bukvic wrote:
What about for instance arrays that should maintain scope inside a specific abstraction so that you can have multiple independent abstractions? $0 is very useful IMHO and is also necessary to stay due to backwards compatibility concerns. Therefore, I think the discussion should be limited to a simple yes or no for $0 substitution inside a message as it does not introduce a myriad of other questions.
Having message recognize it as such (the code already seeks to resolve dollarzero but fails because the canvas was not set as current which should be a simple addition of a couple of lines of code) makes sense even if the only benefit is not having to do [$0] or what you are suggesting, namely [zerofy-me]. It is also worth noting that there is no reason why the two could not coexist.
Yet, as it stands right now, $0, contrary to what has been already said in both threads on this topic, is an anomaly inside a message box and behaves like nothing else anywhere else in the code and as such this should be a no-brainer fix, just like having a trigger with static values, like [t 0 f 1] for opening a gate, passing a value, and then immediately closing it. This is what pd-l2ork does (and so does Max). So, rather than putting redundant messages with static values below the [t b] outlet, one object solves it all. To me this is the same situation where message can do it all, and if that makes my patching quicker, I am all for it.
On Sep 10, 2014 12:48 PM, "Jonathan Wilkes" <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
Two things:
- the lack of "$0" in messages is only a symptom of a bigger
problem with scope of binding symbols in Pd. I'd rather see new objects (or wrapper objects) that handle scope in a sensible manner which doesn't require typing "$0-" at all. There's already no need for $0 in your preset_hub/node design. Why not extend the hub/node idea and get rid of the need for $0 completely?
[hub]/[node] = [send]/[receive] [hub~]/[node~] = [throw~]/[catch~] etc.
- On a more superficial note, isn't the problem that Pd doesn't
store stray "\n" characters in message boxes? The only time I can think of when one would have a real desire for $0 in a message box is when initializing a bunch of receivers:
[; $0-foo 1; $0-bar 2; $0-flub 3;(
But if the box stored "\n" you could get the same clean format with commas: [foo 1, bar 2, flub 3( | [zerofy-me] <- add a "$0-" to the selector | | [send]
No ugly zeros, no leading semi-colon, everybody wins!
-Jonathan
On Wednesday, September 10, 2014 2:27 AM, Ivica Bukvic <ico@vt.edu mailto:ico@vt.edu> wrote:
On Sep 10, 2014 1:17 AM, "Chris McCormick" <chris@mccormick.cx mailto:chris@mccormick.cx> wrote:
Hi Ivica,
On 10/09/14 04:19, Ivica Ico Bukvic wrote:
Yet, I wonder why message shouldn't be able to pre-parse $0
into a valid
dollarzero (canvas instance), when there will never be a
message one
Thoughts?
There has been a lot of discussion regarding this over the years
which
might be good to read to get an idea on the different philosophical/language design issues:
http://comments.gmane.org/gmane.comp.multimedia.puredata.general/56365 Thanks, Chris, for bringing this to my attention. Since one of Miller's core ideas behind pd is absolute backwards compatibility, most of alternatives suggested in that thread would cause unacceptable breakage with backwards compatibility or a really kludge workaround for the support of legacy patches. It seems to me Phil really has a point I completely agree with. FWIW, I am looking to implement this in pd-l2ork and as soon as I get a better idea about the recursion Miller mentioned and how to circumvent it, it should find its way into pd-l2ork's source. Best, Ico
Cheers,
Chris.
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Phil Stone Programmer - Application Development Team Information Technology UC Davis School of Veterinary Medicine 530-752-5282 (o)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/10/2014 08:21 PM, Miller Puckette wrote:
The recursion problem (that Ico asked about) is this... if a message box has to set the "cuttent" canvas to itself, so that its messages can access $0, and if its message leads to another message box in another canvas, that second message box can't just bash the value of "current canvas" but rather would have to save the previous one (and restore it when done) so that, when control returns to the first message box, any further messages it wishes to send get its own $0 and not the bashed one.
i have heard rumours about an abomination named "stack".
A deeper question bothers me: what about $1, etc, too? What if we're in an abstraction and want to 'speak' to $0 in our calling patch? THe usual way of doing that is for the calling patch to instantiate the abstraction with $0 as an argument. Then the abstraction itself can access it as, say, $1. But that makes me think we need a way for the message box to be able to access $1 as well as $0.
this is not a problem of the msgbox, but about locality. $0 is currently the only way to implement such a thing - albeit in a crude way. your example clearly shows that $0 is a not very elegant for these kind of problems. (whether in msgboxes or normal objboxes)
Should there be a 'generalized' message box that doesn't use binbuf_eval at all but rather gets a more spohisticated interpreter?
FTM msgbox?
Yet another possible direction: the new "text" object could be given a way to access the contents of message boxes, so that people could write their own semantics any way they please.
but [text] still has the limitations of the binbux: e.g. no whitespace is preserved, semicolons and commas are special...
Hmm, time for another Pd convention :)
now that is a conclusion!
gfmsr IOhannes
i have heard rumours about an abomination named "stack".
THe very thought sends shivers down my spine.
[snip]
Should there be a 'generalized' message box that doesn't use binbuf_eval at all but rather gets a more spohisticated interpreter?
FTM msgbox?
Hmm, thanks for pointing me to that. It doesn't do everything we're hoping for here but goes some way.
Here's a (mad) thought. What if messages boxes could send messages to "1", "2", etc., which would sprout outlets? Something like this:
; 1 2 3; 2 3 4
would send the message "2 3" to the first outlet and then "3 4" to the second one.
I don't see a good way to implement this yet. But it might take care of the majority of situations in which people now have to do $0 tricks, and if so, it might be worth some ugliness in the implementation.
cheers M
On 9/10/2014 2:21 PM, Miller Puckette wrote:
This leads to an interesting point - '$0' might recently have become more important than it was before because of the multiple-libpd-instances features in 0.46 - any libpd patch wanting to support multiple instances will need some $0-ish disambiguation.
The recursion problem (that Ico asked about) is this... if a message box has to set the "cuttent" canvas to itself, so that its messages can access $0, and if its message leads to another message box in another canvas, that second message box can't just bash the value of "current canvas" but rather would have to save the previous one (and restore it when done) so that, when control returns to the first message box, any further messages it wishes to send get its own $0 and not the bashed one.
Thanks for the clarification, Miller. I am unfortunately not sure if I fully understand how this constitutes a recursion. If the first message has a $0 and you do setcurrent, and unset it immediately after the message has been parsed, the canvas will not be set for the second message. In addition, if the second message treats whatever $0 value first one sent as its $1 argument, then there is no problem regardless which canvas is set because the second message will be treating it as a non-$0 argument. It seems to me this is more of a pd user error than the semantics error but I may be very well missing something.
I guess the question I am not sure of is if inside a message_list (for instance) one does:
canvas_setcurrent binbuf_eval canvas_unsetcurrent
Do the objects/traversal that the results of binbuf_eval are forwarded to get evaluated before the unsetcurrent is invoked or is unsetcurrent processed before the rest of the traversal is computed? If former, why is this not affecting objects like [f $0] (or is it)?
A deeper question bothers me: what about $1, etc, too? What if we're in an abstraction and want to 'speak' to $0 in our calling patch? THe usual way of doing that is for the calling patch to instantiate the abstraction with $0 as an argument. Then the abstraction itself can access it as, say, $1. But that makes me think we need a way for the message box to be able to access $1 as well as $0.
It seems like this should either be something syntactic in messages themselves (that could have deep repercussions as that is at the very heart of everything), or else, perhaps, some kind of "properties" kludge, or perhaps (hopefully) there's a better way I haven't thought of.
This sounds like an interesting development but I am not sure if it negates the immediate benefit of parsing $0 inside a message.
Related: it would be nice if message boxs sprouted inlets for $ args ala Max. Even better if it could sprout multiple outlets so that one could send to multiple destinations without the need to use names at all. Even better if it could do tests and loops... oops, now we're writing a computer language. Should there be a 'generalized' message box that doesn't use binbuf_eval at all but rather gets a more spohisticated interpreter?
Yet another possible direction: the new "text" object could be given a way to access the contents of message boxes, so that people could write their own semantics any way they please.
Or externs could get some kind of pathway so that one could send message box strings to lua, etc.
Hmm, time for another Pd convention :)
M
On Wed, Sep 10, 2014 at 10:23:06AM -0700, Phil Stone wrote:
I can add nothing of substance to this argument, but agree fully with Ivica. In many years, I have yet to hear a convincing argument why $0 cannot be recognized as the unique canvas identifier inside a message box. On the plus side, it would eliminate a great deal of cruft hanging off of message boxes used to kludge $0 into messages, something which occurs constantly, at least in my patches.
Phil Stone UC Davis
On 9/10/14, 10:08 AM, Ivica Bukvic wrote:
What about for instance arrays that should maintain scope inside a specific abstraction so that you can have multiple independent abstractions? $0 is very useful IMHO and is also necessary to stay due to backwards compatibility concerns. Therefore, I think the discussion should be limited to a simple yes or no for $0 substitution inside a message as it does not introduce a myriad of other questions.
Having message recognize it as such (the code already seeks to resolve dollarzero but fails because the canvas was not set as current which should be a simple addition of a couple of lines of code) makes sense even if the only benefit is not having to do [$0] or what you are suggesting, namely [zerofy-me]. It is also worth noting that there is no reason why the two could not coexist.
Yet, as it stands right now, $0, contrary to what has been already said in both threads on this topic, is an anomaly inside a message box and behaves like nothing else anywhere else in the code and as such this should be a no-brainer fix, just like having a trigger with static values, like [t 0 f 1] for opening a gate, passing a value, and then immediately closing it. This is what pd-l2ork does (and so does Max). So, rather than putting redundant messages with static values below the [t b] outlet, one object solves it all. To me this is the same situation where message can do it all, and if that makes my patching quicker, I am all for it.
On Sep 10, 2014 12:48 PM, "Jonathan Wilkes" <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
Two things: 1) the lack of "$0" in messages is only a symptom of a bigger problem with scope of binding symbols in Pd. I'd rather see new objects (or wrapper objects) that handle scope in a sensible manner which doesn't require typing "$0-" at all. There's already no need for $0 in your preset_hub/node design. Why not extend the hub/node idea and get rid of the need for $0 completely? [hub]/[node] = [send]/[receive] [hub~]/[node~] = [throw~]/[catch~] etc. 2) On a more superficial note, isn't the problem that Pd doesn't store stray "\n" characters in message boxes? The only time I can think of when one would have a real desire for $0 in a message box is when initializing a bunch of receivers: [; $0-foo 1; $0-bar 2; $0-flub 3;( But if the box stored "\n" you could get the same clean format with commas: [foo 1, bar 2, flub 3( | [zerofy-me] <- add a "$0-" to the selector | | [send] No ugly zeros, no leading semi-colon, everybody wins! -Jonathan On Wednesday, September 10, 2014 2:27 AM, Ivica Bukvic <ico@vt.edu <mailto:ico@vt.edu>> wrote: On Sep 10, 2014 1:17 AM, "Chris McCormick" <chris@mccormick.cx <mailto:chris@mccormick.cx>> wrote: > > Hi Ivica, > > On 10/09/14 04:19, Ivica Ico Bukvic wrote: > > Yet, I wonder why message shouldn't be able to pre-parse $0 into a valid > > dollarzero (canvas instance), when there will never be a message one > > > > Thoughts? > > There has been a lot of discussion regarding this over the years which > might be good to read to get an idea on the different > philosophical/language design issues: > > <http://comments.gmane.org/gmane.comp.multimedia.puredata.general/56365> Thanks, Chris, for bringing this to my attention. Since one of Miller's core ideas behind pd is absolute backwards compatibility, most of alternatives suggested in that thread would cause unacceptable breakage with backwards compatibility or a really kludge workaround for the support of legacy patches. It seems to me Phil really has a point I completely agree with. FWIW, I am looking to implement this in pd-l2ork and as soon as I get a better idea about the recursion Miller mentioned and how to circumvent it, it should find its way into pd-l2ork's source. Best, Ico > > Cheers, > > Chris. > > -- > http://mccormick.cx/ _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list-- Phil Stone Programmer - Application Development Team Information Technology UC Davis School of Veterinary Medicine 530-752-5282 (o)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fre, 2014-09-12 at 00:30 -0400, Ivica Ico Bukvic wrote:
On 9/10/2014 2:21 PM, Miller Puckette wrote:
A deeper question bothers me: what about $1, etc, too? What if we're in an abstraction and want to 'speak' to $0 in our calling patch? THe usual way of doing that is for the calling patch to instantiate the abstraction with $0 as an argument. Then the abstraction itself can access it as, say, $1. But that makes me think we need a way for the message box to be able to access $1 as well as $0.
It seems like this should either be something syntactic in messages themselves (that could have deep repercussions as that is at the very heart of everything), or else, perhaps, some kind of "properties" kludge, or perhaps (hopefully) there's a better way I haven't thought of.
This sounds like an interesting development but I am not sure if it negates the immediate benefit of parsing $0 inside a message.
Chiming late here and I also might don't grasp the whole extent of the current discussion, so please excuse me when I repeat things.
While the topic arises every now and then, I fail to understand how people seem to naturally want $0 in message boxes. It's not that I don't see how it would come in handy. It certainly would have saved me a lot of patching. However, dollar variables in object arguments are totally different animals from dollar variables in message boxes. While in objects they access arguments given to the parent, they are used in message boxes to access a specific element of the incoming message. Why should a $0 in a message box access the unique identifier of the parent, but all other dollar variables an element of the incoming message? Wanting $0 (as proposed!) in message boxes is actually wanting totally different functionality depending on the variable name. Why are people only complaining about a missing $0, but not about a missing $3? If I want to access the third argument given to the parent in a message box, I need to use the same kludge ([list append $3]-[$1( ) I have to use in order to access $0. What is the difference? Ah yes, $3 already has a meaning in message boxes, while $0 doesn't. Ok, $0 hasn't been assigned a meaning yet, so let's give it a totally odd meaning. (excuse the snarky tone).
In (my) ideal Pd world, message boxes would be able to access both, the arguments given to the parent and the elements of the incoming message. Since they are different things, I'd propose two different variable prefixes, $ for arguments of the parent and # (or whatsoever) for elements of the incoming list. Then we wouldn't only have $0 in message boxes, but $3 from my example above would work as well. #0 would give you the selector of the incoming message (that is also something that currently cannot be accessed directly).
Of course, this would _totally_ break backwards compatibility. Also I don't know what technical implications such an implementation would come with. Rationale trumps handiness, so personally I rather opt for breaking backwards compatibility than for a kludge that still wouldn't make sense in a hundred years when people would ask themselves: "What does $0 mean in a message box? Ah yes, it is special ... "
Personally, I even prefer the status quo to the proposed use of $0. It is cumbersome, admittedly, but I'd rather miss a feature than using a feature that fully breaks the logic of the whole.
Roman
p.s. I may sound as I'd care a lot about the future of $0 in message boxes. Actually, I do not so much. I certainly could live with the proposed use of $0 in msg boxes. I'd consider it a kludge, nevertheless.
To address your initial query about why may naturally want $0 in msg boxes, in no particular order: * the syntax for variables is the same in object and message boxes. So when a user learns that $0 in an object box expands to a unique id, and $0 in msg expands to 0, their minds may naturally wander freely between the two separate contexts for the same combination of characters '$0'. Some users reasonably wonder why msg expansion to "0", which is all but useless, might not be replaced by something useful like obj box $0. The reasoning might not have the same impetus if, say, message box variables were something different like #1, \1, or `one. In any of those cases, when the topic would arise users would probably ask about accessing dollar variables as a whole in the way you describe. * $0 is almost always used for locality, whereas $1-$n are only sometimes used for locality. Additionally, the user is _much_ more likely to do math with one of the values from $1-$n (add, multiply, etc.); they are likely never to do that with $0. $0 and $0- prefix almost always mean "make this local", so users naturally want a way to say "make this local" inside a message box. (They may also want to do math inside a message box, but that's way more complicated to do and do right than just fetching a single id, so users are less likely to vehemently push for that.) * $0 itself has no natural or logical relationship to the sequence $1-$n because. For example, $4 is the fourth atom in an array of atoms. $3 is the atom immediately before $4, $5 is immediately after $4, and so forth. But $0 is not the atom immediately preceding $1. It is an inconsistency, users know this, and so they probably have a hard time seeing why adding an additional inconsistency to the msg box context is a problem.
* related to above-- for consistency $0 in an obj or msg ought to expand to the selector. Since it already doesn't do this in obj boxes, users probably don't care that it doesn't (and won't) do this in a msg box
-Jonathan
On Saturday, September 13, 2014 4:15 PM, Roman Haefeli reduzent@gmail.com wrote:
On Fre, 2014-09-12 at 00:30 -0400, Ivica Ico Bukvic wrote:
On 9/10/2014 2:21 PM, Miller Puckette wrote:
A deeper question bothers me: what about $1, etc, too? What if we're in an abstraction and want to 'speak' to $0 in our calling patch? THe usual way of doing that is for the calling patch to instantiate the abstraction with $0 as an argument. Then the abstraction itself can access it as, say, $1. But that makes me think we need a way for the message box to be able to access $1 as well as $0.
It seems like this should either be something syntactic in messages themselves (that could have deep repercussions as that is at the very heart of everything), or else, perhaps, some kind of "properties" kludge, or perhaps (hopefully) there's a better way I haven't thought of.
This sounds like an interesting development but I am not sure if it negates the immediate benefit of parsing $0 inside a message.
Chiming late here and I also might don't grasp the whole extent of the current discussion, so please excuse me when I repeat things.
While the topic arises every now and then, I fail to understand how people seem to naturally want $0 in message boxes. It's not that I don't see how it would come in handy. It certainly would have saved me a lot of patching. However, dollar variables in object arguments are totally different animals from dollar variables in message boxes. While in objects they access arguments given to the parent, they are used in message boxes to access a specific element of the incoming message. Why should a $0 in a message box access the unique identifier of the parent, but all other dollar variables an element of the incoming message? Wanting $0 (as proposed!) in message boxes is actually wanting totally different functionality depending on the variable name. Why are people only complaining about a missing $0, but not about a missing $3? If I want to access the third argument given to the parent in a message box, I need to use the same kludge ([list append $3]-[$1( ) I have to use in order to access $0. What is the difference? Ah yes, $3 already has a meaning in message boxes, while $0 doesn't. Ok, $0 hasn't been assigned a meaning yet, so let's give it a totally odd meaning. (excuse the snarky tone).
In (my) ideal Pd world, message boxes would be able to access both, the arguments given to the parent and the elements of the incoming message. Since they are different things, I'd propose two different variable prefixes, $ for arguments of the parent and # (or whatsoever) for elements of the incoming list. Then we wouldn't only have $0 in message boxes, but $3 from my example above would work as well. #0 would give you the selector of the incoming message (that is also something that currently cannot be accessed directly).
Of course, this would _totally_ break backwards compatibility. Also I don't know what technical implications such an implementation would come with. Rationale trumps handiness, so personally I rather opt for breaking backwards compatibility than for a kludge that still wouldn't make sense in a hundred years when people would ask themselves: "What does $0 mean in a message box? Ah yes, it is special ... "
Personally, I even prefer the status quo to the proposed use of $0. It is cumbersome, admittedly, but I'd rather miss a feature than using a feature that fully breaks the logic of the whole.
Roman
p.s. I may sound as I'd care a lot about the future of $0 in message boxes. Actually, I do not so much. I certainly could live with the proposed use of $0 in msg boxes. I'd consider it a kludge, nevertheless.
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-09-14 01:16, Jonathan Wilkes via Pd-dev wrote:
To address your initial query about why may naturally want $0 in msg boxes, in no particular order: * the syntax for variables is the same in object and message boxes. So when a user learns that $0 in an object box expands to a unique id, and $0 in msg expands to 0, their minds may naturally wander freely between the two separate contexts for the same combination of characters '$0'. Some users reasonably wonder why msg expansion to "0", which is all but useless,
as a non-native i had some trouble to correctly parse the term "all but useless", but after a websearch came to my rescue, i agree.
what's more: i really think that $0 expanding to (float)'0' is a BUG.
unless we acn assign something *useful* to $0-in-msgboxes, i think it should stay undefined, much like an argument out of range.
error: $0 unavailable in msgboxes
- related to above-- for consistency $0 in an obj or msg ought to
expand to the selector.
oh yes.
it's a pity that this is unlikely to happen (for compat reasons), but imho it's the only sensible expansion to $0 - in any context.
fgmasdr IOhannes
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Ivica Ico Bukvic -
Jonathan Wilkes -
Miller Puckette -
Roman Haefeli