> 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.
>
>
>
>
>