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