Georg Werner wrote:

hi,

Hi Georg,

can somebody explain why there is a "3rd rule of $-expansion: 'there is no $0 in message-boxes'".

The following is from an implementor's viewpoint, not a user's viewpoint, so be warned :)

I don't know why, but it makes parsing Pd patches 1000x less straightforward than required (you need a two-phase parser that has a special exception to detect message boxes and not expand dollars, allowing the message box objects to parse them itself later, while expanding dollars for everything else).

I ran into this problem implementing PotatoData (basically a proof of concept, it's a Pd patch interpreter written in Lua with minimal amounts of C for DSP, can run some trivial audio patches) a couple of months ago, and just ducked it completely - message boxes in my implementation don't support dollars at all (nor commas or semicolons for sequencing and redirection, but that's a separate issue).

I wish message boxes had used a different special character, it would have made life much much easier.

i stumble every now and then about it and it is IMHO not self-explanatory.

It's a mess. There are two similar concepts at work:

1. replacing dollars with arguments at patch execution time
2. replacing dollars with arguments at message passing time

But they both use the same $ symbol syntax in Pd, so you can't have both taking place (ie, use $ at patch execution to create a message box that has $ to replace at dataflow time). And $0 is in phase 1, so what should a message box do with $0 in phase 2?

The confusion arises partly because when Pd loads a patch, it's really internally passing messages around.

$ in message boxes is unfortunate. If there was a different symbol, perhaps #, you could combine both phases in one object box to avoid jumping through pointless hoops.

[$0-#1-$2-#3( would be nice, but as Pd is now, it's a nightmare.

Claude

http://claudiusmaximus.goto10.org

On Sat, 7 Feb 2009, Claude Heiland-Allen wrote:

I don't know why, but it makes parsing Pd patches 1000x less straightforward than required (you need a two-phase parser that has a special exception to detect message boxes and not expand dollars, allowing the message box objects to parse them itself later, while expanding dollars for everything else).

The way it works in Pd, Is that the parsing only cuts a patch into lists of atoms, and then the evaluation of $ is a separate phase. There are two levels of evaluation of $ in patches: one is because the patch is saved as a sequence of messages that do dynamic patching of all of the patch. Therefore, an objectbox containing $0 has to be saved as $0, which gets converted to $0 on the first evaluation, and the $0 turns into a float on the second evaluation.

I don't think that this way of doing things is really bad, except perhaps that it allows one to make patches that do weird things that don't get saved back the same way (e.g. what if you edit a .pd file to put non-backslashed dollars in it?)

That #X obj has this extra evaluation level compared to #X msg and others, is not necessarily bad nor uncommon. The LISP languages generally have that: there are a number of so-called special-forms in which arguments are not evaluated, and some others in which only some arguments are evaluated. This is how 'foo is a shortcut for (quote foo) in which the argument of quote is not evaluated. In theory, you only really need that one special-form in such a language, but the inventors of this figured out that it was annoying to have to have only one special-form because it needs too many apostrophes all over the place. In the end, though, inventors of various LISP dialects could not agree on how many special-forms there should be. (Macros allow the user to define its own things that look like special-forms, but because of their evaluation order, it also allows bypassing any non-evaluation too)

In Tcl, which is a distant cousin of LISP, things are different. Instead, there is an extra level of syntax because all lists are assumed to be quoted, a first parsing handles only { } { } and a second parsing handles $ $ [ ] [ ] ... not counting the [expr] calls, which are a third level of parsing and happens quite often because it's explicit in [if] [while] etc. The avoidance of having some kind of evaluation at the first level of parsing makes it necessary to have the second level. My point is that it's a tradeoff in the design of languages. If you remove complexity in one way, it reappears in another way if the complexity is necessary.

So, what could have Pd done differently? Perhaps two things:

1. Avoid the substitution in the first evaluation, so that most

backslashes aren't needed in the file format.

2. Use a different character for substitution in messageboxes, so that

message arguments are substituted using # or whatever (that's a second level of parsing because # is not recognised at the first parsing level; or would it??). But this makes people want to use $ to access abstraction-args directly in it, and if that feature is considered as a good thing, then you still need to either skip substitution in #X msg by opposition to #X obj, or add another level of backslashes in msg.

(But that's all very hypothetical and nothing of that will change in pd)

I ran into this problem implementing PotatoData (basically a proof of concept, it's a Pd patch interpreter written in Lua with minimal amounts of C for DSP, can run some trivial audio patches) a couple of months ago, and just ducked it completely - message boxes in my implementation don't support dollars at all (nor commas or semicolons for sequencing and redirection, but that's a separate issue). I wish message boxes had used a different special character, it would have made life much much easier.

I don't think it's a big deal. There are much more difficult things than that, that you have to do to make a good interpreter and/or compiler. It's just a bit confusing and somewhat easy to get wrong if you don't put all of your attention in it, but if pd were different, this set of problems would be replaced by another set of problems.

It's a mess. There are two similar concepts at work:

1. replacing dollars with arguments at patch execution time
2. replacing dollars with arguments at message passing time

There are three of them. 0. replacing dollars when loading patch (not normally used)

1. replacing dollars when loading #X obj
2. replacing dollars when message is sent to a #X msg box

The confusion arises partly because when Pd loads a patch, it's really internally passing messages around.

That's why level 0 is there. It's never used by normal patches, yet it makes it necessary to add extra backslashes everywhere.

Perhaps all this Pd parsing process is more difficult because it is not so well documented (or the documentation has been forgotten in some dungeon and is not part of any manual). Therefore you have to discover more of it yourself and may have surprises and there are not many people paying attention to the topic and not much standard terminology to talk about how it is done in Pd. It doesn't *have* to be simplified, it has to be seen as simpler. But in any case, things become seen as simpler once they are understood.

$ in message boxes is unfortunate. If there was a different symbol, perhaps #, you could combine both phases in one object box to avoid jumping through pointless hoops.

exactly. well, it's very well possible to just avoid using messageboxes and instead use an external that would do the same job. It's not so hard.

[$0-#1-$2-#3( would be nice, but as Pd is now, it's a nightmare.

What about [m $0-#1-$2-#3] ? if such an external existed... the only funky thing in there is if $2 substitutes to something with a "#" in it... in that case, the extra level of evaluation would become apparent.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Sat, 7 Feb 2009, Frank Barknecht wrote:

Messages don't have anything comparable to the canvas' $0. A possible alternative use for $0 in messages would be the selector ("list", "symbol", ...) as that is the thing before $1, but implementing that could be even more confusing to beginners.

Why would that be confusing to beginners?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Tue, 10 Feb 2009, Frank Barknecht wrote:

Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

...

On Sat, 7 Feb 2009, Frank Barknecht wrote:

...

Messages don't have anything comparable to the canvas' $0. A possible alternative use for $0 in messages would be the selector ("list", "symbol", ...) as that is the thing before $1, but implementing that could be even more confusing to beginners.

Why would that be confusing to beginners?

Because it's not the $0 from object boxes.

Ok. That was my impression too. As Johannes was saying, $0 in objectboxes could have been referring to the name of the abstraction (as it was located in the first place). That would have made it much more sensible to have that $0 in messageboxes.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

There is already [route] to get the selectors bang, symbol, list,
float and only 'other'. But it would be nice to have something like
this :

[33 hello -4.5 world( | [$0( | [print]

and get print: list not 0 as now

or

[open mytext.txt 45( | [$0( | [print]

and get print: open not 0 as now (and nor 'other' as does [route])

So the first element is $0, the second is $1, etc. I think it is not so difficult to understand for a beginner because
it's logical. We must explain that [33 hello 4.5 world( is a list without the word
list in the message because the message begin by a number and has
several elements : it is the same [list 33 hello 4.5 world(. Idem for
float. What do you think ? ++

Jack

Le 10 févr. 09 à 17:45, Mathieu Bouchard a écrit :

On Sat, 7 Feb 2009, Frank Barknecht wrote:

...

Messages don't have anything comparable to the canvas' $0. A possible alternative use for $0 in messages would be the selector ("list", "symbol", ...) as that is the thing before $1, but implementing that could be even more confusing to beginners.

Why would that be confusing to beginners?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal,
Québec_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list