<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"><div id="yiv6980655542"><div id="yui_3_16_0_ym19_1_1471537212182_20699"><div id="yui_3_16_0_ym19_1_1471537212182_20698" style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div id="yiv6980655542"><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_14737"><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_14736" style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div id="yui_3_16_0_ym19_1_1471537212182_25478">Hi Roman,</div><div id="yui_3_16_0_ym19_1_1471537212182_25479">I'll try to address the question of how difficult each of these is to implement.<br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_9008"><span></span></div>[...]<br clear="none"></div></div></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_14718"><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_9025" style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_9024" style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div class="yiv6980655542y_msg_container" id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_9186"><br clear="none">> == GROUPING IN ABSTRACTION ARGUMENTS ==<br clear="none">> Allow grouping of atoms, so that you can pass a whole list to one<br clear="none">> single argument like this:<br clear="none"><br clear="none">> [myabs ( one two 3 ) 4 five]<br clear="none"><br clear="none">> inside the abstraction:<br clear="none"><br clear="none">> $1 would evaluate to 'list one two 3' <br clear="none">> $2 would evaluate to '4'<br clear="none">> $3 would evaluate to '5'<br clear="none"><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_11823"><br clear="none"></div><div dir="ltr" id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_11822">This would require changes to t_atom because there is no "list" atom type. That's <br clear="none"></div><div dir="ltr" id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_11821">a fairly involved change, especially given that plenty of internal and external classes <br clear="none"></div><div dir="ltr" id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_11819">do "lazy" type checking (if it isn't a float it must be a symbol, etc.).<br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_11818"><br clear="none"></div>> == GETTING NUMBER OF ARGS ==<br clear="none">> With the same example:<br clear="none"><br clear="none">> [myabs ( one two 3 ) 4 five]<br clear="none"><br clear="none">> inside the abstraction:<br clear="none"><br clear="none">> $# would evaluate to '3' (number of arguments given)<br clear="none"><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_11769"><br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_11768">This requires changes to the parser, which requires extensive testing and <br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_11816"><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15701">bug fixing, too.</div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15702"><br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15703">Pd-l2ork uses "$@" to expand to all the arguments, which you can <br clear="none"></div><div dir="ltr" id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15704">then shoot to a [list length] to get the equivalent of "$#". It's based off a patch <br clear="none"></div><div id="yui_3_16_0_ym19_1_1471537212182_23475" dir="ltr">submitted originally submitted to Pd Vanilla by IOhannes which is probably <br clear="none"></div><div dir="ltr" id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15705">still hanging around on the sourceforge patch tracker.<br clear="none"></div></div><div class="qtdSeparateBR"><br><br></div><div class="yiv6980655542yqt4634495408" id="yiv6980655542yqtfd53094"><br clear="none">> == GROUPING IN MESSAGES ==<br clear="none">> [1 2 ( 97 98 99 ) 4 5(<br clear="none">> |<br clear="none">> [$2 (<br clear="none"><br clear="none"><br clear="none"><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_16268">> would give '97 98 99'</div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_16267"><br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15706">Did you mean [$3(?<br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15707"><br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15708">If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'?</div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15709"><br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15710">In other words, what would be the rule for flattening a list atom into <br clear="none"></div><div dir="ltr" id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15759">a series of atoms?<br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_15711"><br clear="none"></div><div id="yiv6980655542yui_3_16_0_ym19_1_1471537212182_16266"><div id="yui_3_16_0_ym19_1_1471537212182_23071">Regarding parentheses-- Gridflow adds a syntax like that for handling <br></div><div id="yui_3_16_0_ym19_1_1471537212182_23072" dir="ltr">nested message data. I don't like the idea in general, but I like Gridflow's <br></div><div id="yui_3_16_0_ym19_1_1471537212182_22900" dir="ltr">implementation better than your example because it doesn't require <br></div><div id="yui_3_16_0_ym19_1_1471537212182_22907" dir="ltr">space in between the parentheses and the data itself.</div><div id="yui_3_16_0_ym19_1_1471537212182_23478" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1471537212182_23479" dir="ltr">Anyhow, this is another parser change (in m_binbuf).<br></div><div class="yiv6980655542yqt4225828417" id="yiv6980655542yqtfd91009"><br clear="none"></div></div><div class="yiv6980655542yqt4225828417" id="yiv6980655542yqtfd80922"><br clear="none">> == NAMED ARGUMENTS ==<br clear="none"><br clear="none">> [myabs freq=440 vol=1]<br clear="none"><br clear="none">> inside the abstraction:<br clear="none"><br clear="none">> $freq would evaluate to '440'<br clear="none">> $vol would evalute to '1'<br clear="none"><br clear="none">> If a certain argument is not specified as creation argument, it would<br clear="none">> evaluate to '0' (similar to existing behavior).<br clear="none"><div id="yui_3_16_0_ym19_1_1471537212182_23924"><br></div><div id="yui_3_16_0_ym19_1_1471537212182_23925" dir="ltr">What would $1 and $2 evaluate to in this case? What would [$freq( expand to?<br></div><div id="yui_3_16_0_ym19_1_1471537212182_23926"><br></div><div id="yui_3_16_0_ym19_1_1471537212182_23927">I'm not actually sure what changes this would require. At the very least you'd need a <br></div><div id="yui_3_16_0_ym19_1_1471537212182_24401" dir="ltr">new case in the parser for handling dollar signs that don't match the A_DOLLAR or <br></div><div id="yui_3_16_0_ym19_1_1471537212182_24402" dir="ltr">A_DOLLSYM. It seems like you'd need a new atom type, too. Let's call it <br></div><div id="yui_3_16_0_ym19_1_1471537212182_24403" dir="ltr">A_DOLLVAR.</div><div id="yui_3_16_0_ym19_1_1471537212182_25619"><br></div><div>How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR? Can it be <br></div><div dir="ltr">concatenated with them? (The case for "$@" is that it doesn't concatenate.) But <br></div><div id="yui_3_16_0_ym19_1_1471537212182_24952" dir="ltr">you also have to account for A_DOLLVAR expanding to arbitrarily-deeply-nested <br></div><div dir="ltr">lists because it's going to work inside message boxes, too.</div><div><br></div>> == USE CASE ==<br clear="none">> [oscformat] takes an arbitrary number of arguments to create an OSC<br clear="none">> address. While I find this the cleaner and more pd-like way than<br clear="none">> /one/two/three, this has big draw-back. You currently cannot pass the<br clear="none">> OSC address (containing an arbitrary number of address fields) to an<br clear="none">> abstraction when using [oscformat]. The number of arguments must known<br clear="none">> beforehand when using this format. With [packOSC] from the osc library,<br clear="none">> you can do:<br clear="none"><br clear="none">> [myabs /base/address]<br clear="none"><br clear="none">> and therein:<br clear="none"><br clear="none">> [packOSC $1/freq]<br clear="none"><br clear="none">> which evaluates to /base/address/freq. <br clear="none"><br clear="none">> By allowing grouping of arguments, one could achieve the same without<br clear="none">> resorting to long symbols (which has other drawbacks). In the main<br clear="none">> patch you could create:<br clear="none"><br clear="none">> [myabs ( base address )]<br clear="none"><br clear="none">> and therein:<br clear="none"><br clear="none">> [oscformat $1 freq]<br clear="none"><br clear="none"><div id="yui_3_16_0_ym19_1_1471537212182_23420">> and [oscformat] would actually see 'base address freq'.</div><div id="yui_3_16_0_ym19_1_1471537212182_23421"><br></div><div id="yui_3_16_0_ym19_1_1471537212182_23422">Wouldn't it see '(base address) freq'?<br></div><br clear="none">> There are many other cool things you could do. It would allow to create<br clear="none">> lists of lists, which can be easily split again later (which is<br clear="none">> currently very hard to do and involves a lot of serializing and using<br clear="none">> delimiters or prepended number-of-elements). Generally, it would allow<br clear="none"><div id="yui_3_16_0_ym19_1_1471537212182_23423">> to create much more flexible abstractions.</div><div id="yui_3_16_0_ym19_1_1471537212182_23424"><br></div><div id="yui_3_16_0_ym19_1_1471537212182_23425">Does [text] address some of this?</div><div id="yui_3_16_0_ym19_1_1471537212182_25667"><br></div><div id="yui_3_16_0_ym19_1_1471537212182_25668">> Any feedback welcome.</div><br clear="none">> Roman<br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none"> <br clear="none">_______________________________________________<br clear="none"><a id="yui_3_16_0_ym19_1_1471537212182_23457" rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a><br clear="none"><br clear="none"><br clear="none"></div></div></div><div class="yiv6980655542yqt4225828417" id="yiv6980655542yqtfd78660"><div class="yiv6980655542yqt4634495408" id="yiv6980655542yqtfd30833"> </div></div></div><div class="yiv6980655542yqt4225828417" id="yiv6980655542yqtfd37666"><div class="yiv6980655542yqt4634495408" id="yiv6980655542yqtfd09886"> </div></div></div><div class="yiv6980655542yqt4225828417" id="yiv6980655542yqtfd66968"><div class="yiv6980655542yqt4634495408" id="yiv6980655542yqtfd49296"> </div></div></div></div></div></div></div></body></html>