Hey all
After watching "Future Pd Developments" round-table (thanks to everyone
involved for the effort to record/put online), I feel like poking some more into the structured list idea. Some of the conclusions that came up:
* Something like [list args] as a way to get all given arguments as a
list would be utterly helpful.
Please don't name it that. [list] objects currently operate on incoming lists or take an incoming symbol and output it as a list. In both cases the output is generated from the data arriving at the inlet (and in the latter case at least the name tells you exactly what kind of non-list data to feed it). [list args] would instead operate on load time data associated with its parent glist. In the common case where a user creates it on a toplevel canvas, it also has the drawback of not outputting a sane default-- i.e., an outgoing "bang" doesn't give you any clue about what "args" refers to.
- Many data structures like nested lists or hashes can actually be
implemented without changing the core of Pd.
I agree and I'm totally looking forward to a [list args]. Now, here
comes the thing. Let's say I want to make a wrapper abstraction around [oscformat] and my wrapper abstraction takes an arbitrary number of arguments. What I'm looking for is a way to define which part of the argument list is part of an OSC address and should be passed as arguments to [oscformat] and which part should be used to set some defaults in my wrapper abstraction.
Example:
[myOSCmodule { dog cat food } { foo 123 }]
inside this:
[oscformat $1] <- would be instantiated as [oscformat dog cat food]
[loadbang] | [list append $2] <- would return 'list foo 123'
As far as I can see it, it is currently impossible to pass a variable
number of arguments to child objects and also [list args] wouldn't address that. The simplest case of passing all arguments to a child object could be covered with something like a '$@', but really cool would be a way to define which arguments specifically should be passed to child objects. That's why I came up with the idea of nesting lists. Actually, I'm interested in a more sophisticated mechanism for argument inheritance.
Comments?
There is this comment from the "$@" thread on the patch tracker:https://sourceforge.net/p/pure-data/patches/92/
"i think that $@ is what is necessary to allow abstractions to do what they want with args, and that $# is not so useful in comparison, and what would be more useful than $# (in the sense of avoiding more detours) would be to be able to do a $@-like thing that only starts at the Nth argument, e.g. if I have an abstraction that takes $1 $2 $3 and then a variable number of arguments, and those arguments starting with $4 are to be all written directly in an objectbox. witness the strange stuff going on in [nqpoly]..." Something like $@-4 would fulfill your case... General comment:Didn't we talk about abusing the comma atom for situations like this? So[myOSCabstraction selector1 foo bar, selector2 bing bang, selector3 something else] Then inside of that [loadbang]|[myArgParser selector2] <-- get the "selector2" part of the args |[list prepend set]|[list trim]|[oscformat] The benefit is that "selector2" is an arbitrary symbol in your own language that tells you and other users something about its data. $2, or even $@-2, only tells you where it came from, which is incidental and not as meaningful. I.e., compare: [unpack 0 0 0 0 0]|[$2 $1 $3 $4 $5]|[s voice3] to
[get note a d s r pitch]|[pack 0 0 0 0 0]| [s voice3] -Jonathan
Roman
On Mon, 2016-10-31 at 13:53 +0100, Roman Haefeli wrote:
How can Pure Data's capabilities for dealing with different data sets be extended? Does it make sense to adopt concepts from scripted languages to the dataflow paradigm? Examples: tuples, dictionaries, multi-dimensional arrays, [...]
PROPOSAL: Syntax for nesting lists so that lists can be organized in a hierarchical manner and sublists (as opposed to only atoms) can be access with dollargs.
Reserved symbol atoms '{' and '}' could be used to enclose sublists (Since those characters are forbidden now, introduction wouldn't break anything).
An example nested list containing two sublists:
'list { a b c } { 1 2 3 }'
The third element of the the first list would be accessed like this:
[list $1( <- returns 'list a b c'
[list $3( <- returns 'symbol c'
Dollargs would strip the encompassing curly braces and return only the content of the specified sublist:
[list $2( <- returns 'list 1 2 3'
To extract the second sublist without losing its encapsulation, one would use:
[list { $2 }( <- returns 'list { 1 2 3 }'
The same syntax can be used for dollargs used in arguments. This allows to pass a whole list or even a list of lists through a single dollarg:
[myabstraction { animal mammal cat }]
and inside this abstraction, we have:
[oscformat $1 miau] <- instantiates [oscformat animal mammal cat miau]
Whether to use curly braces or something different as list markup and whether to separate markup symbols with spaces or not is to be discussed. Also, the feasibility to implement the proposed idea would be an important discussion point, since the proposer only considered a user point-of-view.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list