<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px">> Hey all<br clear="none"><div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1480537961623_8730" style="display: block;"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1480537961623_8729"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1480537961623_8728"><div class="y_msg_container" id="yui_3_16_0_ym19_1_1480537961623_8734"><br clear="none">> After watching "Future Pd Developments" round-table (thanks to everyone<br clear="none">involved for the effort to record/put online), I feel like poking some<br clear="none">more into the structured list idea. Some of the conclusions that came<br clear="none">up:<br clear="none"><br clear="none">> * Something like [list args] as a way to get all given arguments as a<br clear="none"> list would be utterly helpful.<br clear="none"><div id="yui_3_16_0_ym19_1_1480537961623_8936"><br></div><div id="yui_3_16_0_ym19_1_1480537961623_8937">Please don't name it that. [list] objects currently operate on incoming lists or <br></div><div id="yui_3_16_0_ym19_1_1480537961623_9021" dir="ltr">take an incoming symbol and output it as a list. In both cases the output is <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_9078">generated from the data arriving at the inlet (and in the latter case at least <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_9093">the name tells you exactly what kind of non-list data to feed it).</div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_9079"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_9266">[list args] would instead operate on load time data associated with its parent <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_9267">glist. In the common case where a user creates it on a toplevel canvas, it also <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_9280">has the drawback of not outputting a sane default-- i.e., an outgoing "bang" <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_9281">doesn't give you any clue about what "args" refers to.<br></div><div id="yui_3_16_0_ym19_1_1480537961623_8896"><br></div>> * Many data structures like nested lists or hashes can actually be<br clear="none"> implemented without changing the core of Pd.<br><div id="yui_3_16_0_ym19_1_1480537961623_9299"><br></div>> I agree and I'm totally looking forward to a [list args]. Now, here<br clear="none">comes the thing. Let's say I want to make a wrapper abstraction around<br clear="none">[oscformat] and my wrapper abstraction takes an arbitrary number of<br clear="none">arguments. What I'm looking for is a way to define which part of the<br clear="none">argument list is part of an OSC address and should be passed as<br clear="none">arguments to [oscformat] and which part should be used to set some<br clear="none">defaults in my wrapper abstraction. <br clear="none"><br clear="none">> Example:<br clear="none"><br clear="none">> [myOSCmodule { dog cat food } { foo 123 }]<br clear="none"><br clear="none">> inside this:<br clear="none"><br clear="none">> [oscformat $1] <- would be instantiated as [oscformat dog cat food]<br clear="none"><br clear="none">> [loadbang]<br clear="none">> |<br clear="none">> [list append $2] <- would return 'list foo 123'<br clear="none"><br clear="none"><br clear="none">> As far as I can see it, it is currently impossible to pass a variable<br clear="none">number of arguments to child objects and also [list args] wouldn't<br clear="none">address that. The simplest case of passing all arguments to a child<br clear="none">object could be covered with something like a '$@', but really cool<br clear="none">would be a way to define which arguments specifically should be passed<br clear="none">to child objects. That's why I came up with the idea of nesting lists.<br clear="none">Actually, I'm interested in a more sophisticated mechanism for argument<br clear="none">inheritance.<br clear="none"><br clear="none">> Comments?<br clear="none"><div id="yui_3_16_0_ym19_1_1480537961623_9489"><br></div><div id="yui_3_16_0_ym19_1_1480537961623_9548">There is this comment from the "$@" thread on the patch tracker:</div><div id="yui_3_16_0_ym19_1_1480537961623_9491">https://sourceforge.net/p/pure-data/patches/92/<br></div><div id="yui_3_16_0_ym19_1_1480537961623_9493"><br></div><div id="yui_3_16_0_ym19_1_1480537961623_9516">"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]..."</div><div id="yui_3_16_0_ym19_1_1480537961623_9514"><br></div><div id="yui_3_16_0_ym19_1_1480537961623_9627">Something like $@-4 would fulfill your case...</div><div id="yui_3_16_0_ym19_1_1480537961623_9636"><br></div><div id="yui_3_16_0_ym19_1_1480537961623_9706">General comment:</div><div id="yui_3_16_0_ym19_1_1480537961623_10146">Didn't we talk about abusing the comma atom for situations like this?</div><div><br></div><div>So</div><div dir="ltr">[myOSCabstraction selector1 foo bar, selector2 bing bang, selector3 something else]</div><div><br></div><div>Then inside of that</div><div><br></div><div>[loadbang]</div><div>|</div><div>[myArgParser selector2] <-- get the "selector2" part of the args<br></div><div id="yui_3_16_0_ym19_1_1480537961623_9767">|</div><div>[list prepend set]</div><div>|</div><div>[list trim]</div><div>|</div><div dir="ltr">[oscformat]</div><div dir="ltr"><br></div><div dir="ltr">The benefit is that "selector2" is an arbitrary symbol in your own language that <br></div><div dir="ltr">tells you and other users something about its data. $2, or even $@-2, only <br></div><div dir="ltr">tells you where it came from, which is incidental and not as meaningful. I.e., <br></div><div dir="ltr">compare:</div><div dir="ltr"><br></div><div dir="ltr">[unpack 0 0 0 0 0]</div><div dir="ltr">|</div><div dir="ltr">[$2 $1 $3 $4 $5]</div><div dir="ltr">|</div><div dir="ltr">[s voice3]</div><div dir="ltr"><br></div><div dir="ltr">to <br></div><div dir="ltr"><br></div><div dir="ltr">[get note a d s r pitch]</div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_10514">|</div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_10521">[pack 0 0 0 0 0]</div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_10532">|<br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_10533">[s voice3]</div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_10535"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1480537961623_10537">-Jonathan<br></div><div dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1480537961623_9768">> Roman</div><br clear="none"><br clear="none"><br clear="none"><div class="yqt8308795312" id="yqtfd79583"><br clear="none">On Mon, 2016-10-31 at 13:53 +0100, Roman Haefeli wrote:<br clear="none">> How can Pure Data's capabilities for dealing with different data sets<br clear="none">> be extended? Does it make sense to adopt concepts from scripted<br clear="none">> languages to the dataflow paradigm? Examples: tuples, dictionaries,<br clear="none">> multi-dimensional arrays, [...]<br clear="none">> <br clear="none">> PROPOSAL:<br clear="none">> Syntax for nesting lists so that lists can be organized in a<br clear="none">> hierarchical manner and sublists (as opposed to only atoms) can be<br clear="none">> access with dollargs.<br clear="none">> <br clear="none">> Reserved symbol atoms '{' and '}' could be used to enclose sublists<br clear="none">> (Since those characters are forbidden now, introduction wouldn't<br clear="none">> break<br clear="none">> anything). <br clear="none">> <br clear="none">> An example nested list containing two sublists:<br clear="none">> <br clear="none">> 'list { a b c } { 1 2 3 }'<br clear="none">> <br clear="none">> The third element of the the first list would be accessed like this:<br clear="none">> <br clear="none">> [list $1( <- returns 'list a b c'<br clear="none">> > <br clear="none">> > <br clear="none">> [list $3( <- returns 'symbol c'<br clear="none">> <br clear="none">> Dollargs would strip the encompassing curly braces and return only<br clear="none">> the<br clear="none">> content of the specified sublist:<br clear="none">> <br clear="none">> [list $2( <- returns 'list 1 2 3'<br clear="none">> <br clear="none">> To extract the second sublist without losing its encapsulation, one<br clear="none">> would use:<br clear="none">> <br clear="none">> [list { $2 }( <- returns 'list { 1 2 3 }'<br clear="none">> <br clear="none">> The same syntax can be used for dollargs used in arguments. This<br clear="none">> allows<br clear="none">> to pass a whole list or even a list of lists through a single<br clear="none">> dollarg:<br clear="none">> <br clear="none">> [myabstraction { animal mammal cat }]<br clear="none">> <br clear="none">> and inside this abstraction, we have:<br clear="none">> <br clear="none">> [oscformat $1 miau] <- instantiates [oscformat animal mammal cat<br clear="none">> miau]<br clear="none">> <br clear="none">> <br clear="none">> Whether to use curly braces or something different as list markup and<br clear="none">> whether to separate markup symbols with spaces or not is to be<br clear="none">> discussed. Also, the feasibility to implement the proposed idea would<br clear="none">> be an important discussion point, since the proposer only considered<br clear="none">> a<br clear="none">> user point-of-view. <br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> </div><br><div class="yqt8308795312" id="yqtfd11057">_______________________________________________<br clear="none"><a shape="rect" ymailto="mailto:Pd-list@lists.iem.at" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="https://lists.puredata.info/listinfo/pd-list" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>