[PD] Feature Proposal

[Jonathan Wilkes]

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 at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160818/a0e6597e/attachment-0001.html>