[PD] Should message objects be able to pre-parse $0 into valid dollarzero?

[Ivica Bukvic]

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 at 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 at vt.edu>
> wrote:
>
>
>
> On Sep 10, 2014 1:17 AM, "Chris McCormick" <chris at 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 at lists.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/20140910/a3f73e7c/attachment-0001.html>