Hi Roman,I'll try to address the question of how difficult each of these is to implement. [...]
== GROUPING IN ABSTRACTION ARGUMENTS == Allow grouping of atoms, so that you can pass a whole list to one single argument like this:
[myabs ( one two 3 ) 4 five]
inside the abstraction:
$1 would evaluate to 'list one two 3' $2 would evaluate to '4' $3 would evaluate to '5'
This would require changes to t_atom because there is no "list" atom type. That's a fairly involved change, especially given that plenty of internal and external classes do "lazy" type checking (if it isn't a float it must be a symbol, etc.).
== GETTING NUMBER OF ARGS == With the same example:
[myabs ( one two 3 ) 4 five]
inside the abstraction:
$# would evaluate to '3' (number of arguments given)
This requires changes to the parser, which requires extensive testing and bug fixing, too. Pd-l2ork uses "$@" to expand to all the arguments, which you can then shoot to a [list length] to get the equivalent of "$#". It's based off a patch submitted originally submitted to Pd Vanilla by IOhannes which is probably still hanging around on the sourceforge patch tracker.
== GROUPING IN MESSAGES == [1 2 ( 97 98 99 ) 4 5( | [$2 (
would give '97 98 99'
Did you mean [$3(?
If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'? In other words, what would be the rule for flattening a list atom into a series of atoms?
Regarding parentheses-- Gridflow adds a syntax like that for handling nested message data. I don't like the idea in general, but I like Gridflow's implementation better than your example because it doesn't require space in between the parentheses and the data itself. Anyhow, this is another parser change (in m_binbuf).
== NAMED ARGUMENTS ==
[myabs freq=440 vol=1]
inside the abstraction:
$freq would evaluate to '440' $vol would evalute to '1'
If a certain argument is not specified as creation argument, it would evaluate to '0' (similar to existing behavior).
What would $1 and $2 evaluate to in this case? What would [$freq( expand to?
I'm not actually sure what changes this would require. At the very least you'd need a new case in the parser for handling dollar signs that don't match the A_DOLLAR or A_DOLLSYM. It seems like you'd need a new atom type, too. Let's call it A_DOLLVAR. How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR? Can it be concatenated with them? (The case for "$@" is that it doesn't concatenate.) But you also have to account for A_DOLLVAR expanding to arbitrarily-deeply-nested lists because it's going to work inside message boxes, too.
== USE CASE == [oscformat] takes an arbitrary number of arguments to create an OSC address. While I find this the cleaner and more pd-like way than /one/two/three, this has big draw-back. You currently cannot pass the OSC address (containing an arbitrary number of address fields) to an abstraction when using [oscformat]. The number of arguments must known beforehand when using this format. With [packOSC] from the osc library, you can do:
[myabs /base/address]
and therein:
[packOSC $1/freq]
which evaluates to /base/address/freq.
By allowing grouping of arguments, one could achieve the same without resorting to long symbols (which has other drawbacks). In the main patch you could create:
[myabs ( base address )]
and therein:
[oscformat $1 freq]
and [oscformat] would actually see 'base address freq'.
Wouldn't it see '(base address) freq'?
There are many other cool things you could do. It would allow to create lists of lists, which can be easily split again later (which is currently very hard to do and involves a lot of serializing and using delimiters or prepended number-of-elements). Generally, it would allow to create much more flexible abstractions.
Does [text] address some of this?
Any feedback welcome. Roman
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list