[PD] [pdconv16_r] Topic idea: Nested lists

Jonathan Wilkes jancsika at yahoo.com
Wed Nov 30 22:58:55 CET 2016


> 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 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/20161130/0687cf29/attachment.html>


More information about the Pd-list mailing list