Patches item #1543850, was opened at 2006-08-21 06:24 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1543850...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: wishlist Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: $@ and $# expansion (argc, argv)
Initial Comment: the attached patch extends the $-expansion mechanism:
$# expands to the number of arguments; usable both as A_DOLLAR (just "$#") and A_DOLLSYM ("$#-bla")
$@ expands to the entire list of arguments (e.g. [$@ $@( will expand [1 2 3( to [1 2 3 1 2 3(); this is only usable as A_DOLLAR; i.e. [symbol $@-a( will always expand to "$@-a"
why: well, its a way to deal with dynamic length lists that is still missing in pd (though 1st steps have been made with [list])
caveats: what is still missing is an expansion for the selector of messages and objects (the selector of an object would be the object's instantation name); would $$ be a good name for this? (since $0 is already taken)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-08-22 18:21
Message: Logged In: YES user_id=27104
Yes! This is great!
As for the selector, $0 is not taken in message space, so I think it makes sense there. Since message expansion variables are already different than object arguments, I think that won't be too confusing. Plus the $ variable syntax comes from shell scripting, where $0 is basically the selector of the message that is the command line arguments.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1543850...
i don't agree.
if pd was bash, $0 would be the selector (or object name); $1,... would be the numbered arguments (as they already are); in bash, $$ is the "process id", which could roughly map to the canvas id in objects (what is currently $0)
however, pd is not bash.
$1 in object boxes and messages boxes has the same meaning in a different context. (i know this is kind of a weak argument since it derives the idea from the implementation, but: on the C-level of pd, the entire expansion thing is handled by one function; there is no separation between objects & messages)
$0 has a meaning in objects (which is unfortunately not consistent with $1), but no meaning in messages. this does not mean, that we are free to use it for whatever we want.
for me the selector of a message is structurally the same as the object name (the "selector" of the object), therefore they should have the same expansion-symbol. since $0 is taken (for good or bad), we have to find an alternative, (if we really think we need a selector-expansion).
a meaning for $0 in messages could be a "timestamp". ("objects" are "images", spatial entities; contrary, the basic property of "messages" is there position in time; so arbitrary messages could be grouped together bythis property: messages at the same moment have the same $0)
mfg.asdr. IOhannes
On Aug 23, 2006, at 3:46 AM, IOhannes m zmoelnig wrote:
I think we agree with the overall logic, just not the solution. I think in general, we spend way too much effort remaining backwards compatible and it cripples the development of Pd. All of the old versions are freely available, if you need to run an old patch, you can easily use an old version of Pd.
The whole $ argument scheme has been laid out and clearly defined for a very long time. I think its a bad idea to use the $ argument scheme, then invert the meaning of a couple of parts. That will inevitably lead to people wasting many hours debugging things because they expected a normal $ argument scheme. This kind of kludgey, patch-fix progress has led to things like the symbol atom/symbol message madness, and the convoluted logic of Max's/Pd's list/set handling, or that $0 was used as process ID. We need less of these headaches, not more.
Instead, we need to start to take a step back and look at the bigger picture, and think about how it should have been done had there been no backwards compatibility issues.
I think we should implement the whole $ argument scheme the right way, like in bash, perl, tcsh, etc. etc. Or use a different scheme. For a transition, it would be possible to have a flag that switched $0 to the old behavior. Or many other possible solutions. We could have API version declarations, so that a patch can declare which version of the API it needs, then Pd would adjust accordingly. This could also be done with a startup flag.
.hc
------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.