<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"><br><br><div class="qtdSeparateBR"><br><br></div><div style="display: block;" id="yui_3_16_0_ym19_1_1471641211711_7307" class="yahoo_quoted"> <div id="yui_3_16_0_ym19_1_1471641211711_7306" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div id="yui_3_16_0_ym19_1_1471641211711_7305" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> >On Friday, August 19, 2016 6:15 PM, Roman Haefeli <reduzent@gmail.com> wrote:<br></font></div> <br><br> <div id="yui_3_16_0_ym19_1_1471641211711_7332" class="y_msg_container">> Hi Jonathan,<br clear="none"><br clear="none">> On Don, 2016-08-18 at 19:28 +0000, Jonathan Wilkes wrote:<br clear="none">>> Hi Roman,<br clear="none">>> I'll try to address the question of how difficult each of these is to<br clear="none">>> implement.<br clear="none">>> [...]<br clear="none">>> <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">>> <br clear="none">>> This would require changes to t_atom because there is no "list" atom<br clear="none">>> type. That's <br clear="none">>> a fairly involved change, especially given that plenty of internal<br clear="none">>> and external classes <br clear="none">>> do "lazy" type checking (if it isn't a float it must be a symbol,<br clear="none">>> etc.).<br clear="none"><br clear="none">> Thanks for the insight. That doesn't like realistic thing to do, then.<br clear="none"><br clear="none">>> > == 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">>> <br clear="none">>> This requires changes to the parser, which requires extensive testing<br clear="none">>> and <br clear="none">>> bug fixing, too.<br clear="none">>> <br clear="none">>> Pd-l2ork uses "$@" to expand to all the arguments, which you can <br clear="none">>> then shoot to a [list length] to get the equivalent of "$#". It's<br clear="none">>> based off a patch <br clear="none">>> submitted originally submitted to Pd Vanilla by IOhannes which is<br clear="none">>> probably <br clear="none">>> still hanging around on the sourceforge patch tracker.<br clear="none"><br clear="none">> $@ alone would be already quite a cool feature. I hope it'll get<br clear="none">> accepted once in Pd-vanilla, too.<br clear="none"><div id="yui_3_16_0_ym19_1_1471641211711_7427"><br></div><div id="yui_3_16_0_ym19_1_1471641211711_7428">>> > == GROUPING IN MESSAGES ==<br clear="none"></div>>> > [1 2 ( 97 98 99 ) 4 5(<br clear="none">>> > |<br clear="none">>> > [$2 (<br clear="none">>> <br clear="none">>> <br clear="none">>> > would give '97 98 99'<br clear="none">>> <br clear="none">>> Did you mean [$3(?<br clear="none"><br clear="none">> Oh, yes. Sorry for that.<br clear="none"><br clear="none">>> If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'?<br clear="none"><br clear="none">> I think it should be up to the user to decide whether to stay compact<br clear="none">> or expand. So, [$3 3( would give you the expanded version '97 98 99 3',<br clear="none">> while [ ( $3 ) 3 ( would output<br clear="none">> '( 97 98 99 ) 3'.<br clear="none"><div id="yui_3_16_0_ym19_1_1471641211711_7506"><br></div><div id="yui_3_16_0_ym19_1_1471641211711_7562">Well, there's an additional issue here: you're speaking specifically about <br></div><div id="yui_3_16_0_ym19_1_1471641211711_7635">abstractions, but I'm speaking on the language level.</div><div id="yui_3_16_0_ym19_1_1471641211711_7636"><br></div><div id="yui_3_16_0_ym19_1_1471641211711_7637">If you only mean to have a way to group abstraction args, either Pd-l2ork <br></div><div id="yui_3_16_0_ym19_1_1471641211711_7689" dir="ltr">or Pd Vanilla plus iemguts will give you a way to build your own abstraction <br></div><div id="yui_3_16_0_ym19_1_1471641211711_7690" dir="ltr">to parse those arguments. In that case requiring the space between <br></div><div id="yui_3_16_0_ym19_1_1471641211711_7691" dir="ltr">parentheses is indeed useful as it makes it much easier to parse the creation <br></div><div id="yui_3_16_0_ym19_1_1471641211711_7793" dir="ltr">arguments from within Pd.<br></div><div id="yui_3_16_0_ym19_1_1471641211711_7794" dir="ltr"><br clear="none"></div>>> In other words, what would be the rule for flattening a list atom<br clear="none">>> into <br clear="none">>> a series of atoms?<br clear="none"><br clear="none">> You have to put something explicitly in between parentheses to stay<br clear="none">> compact.<br clear="none">>> <br clear="none">>> Regarding parentheses-- Gridflow adds a syntax like that for<br clear="none">>> handling <br clear="none">>> nested message data. I don't like the idea in general, but I like<br clear="none">>> Gridflow's <br clear="none">>> implementation better than your example because it doesn't require <br clear="none">>> space in between the parentheses and the data itself.<br clear="none"><br clear="none">> I'm no proponent for spaces, but I assumed it would make the idea<br clear="none">> easier to realize (which is moot now) and would be more Pd-like.<br clear="none"><div><br></div><div id="yui_3_16_0_ym19_1_1471641211711_7905">It would if you're just looking for a way to build an abstraction library to <br></div><div id="yui_3_16_0_ym19_1_1471641211711_7906">do this for abstraction arguments. But if you want it to be a language <br></div><div id="yui_3_16_0_ym19_1_1471641211711_7907" dir="ltr">feature (as it becomes in Gridflow) that's no longer an issue.<br></div><br clear="none">>> Anyhow, this is another parser change (in m_binbuf).<br clear="none">>> <br clear="none">>> <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"><div id="yui_3_16_0_ym19_1_1471641211711_8255"><br></div><div id="yui_3_16_0_ym19_1_1471641211711_8345" dir="ltr">Parsing that in a Pd patch would be a pain. You basically have to</div><div id="yui_3_16_0_ym19_1_1471641211711_8397" dir="ltr">reimplement the C code that Pd uses to convert a string into atoms (well, <br></div><div id="yui_3_16_0_ym19_1_1471641211711_8398" dir="ltr">slightly modified, but same idea). Then you also need to reimplement the <br></div><div id="yui_3_16_0_ym19_1_1471641211711_8399" dir="ltr">C function that converts an array of ASCII values to a floating point number.<br></div><div id="yui_3_16_0_ym19_1_1471641211711_8400" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1471641211711_8401">>> </div>>> > If a certain argument is not specified as creation argument, it<br clear="none">>> would<br clear="none">>> > evaluate to '0' (similar to existing behavior).<br clear="none">>> <br clear="none">>> What would $1 and $2 evaluate to in this case? <br clear="none"><br clear="none">> In order to stay backwards compatible, I think they should have the<br clear="none">> same behavior like now:<br clear="none"><br clear="none">> $1 -> 'freq=440'<br clear="none">> $2 -> 'vol=1'<br clear="none"><br clear="none">>> What would [$freq( expand to?<br clear="none"><br clear="none">> It would not expand to anything, it would just output '$freq'. I don't<br clear="none">> see why there should be any expectation that $-args in message boxes<br clear="none">> would expand to creation arguments. Named arguments really only make<br clear="none">> sense as creation arguments. I don't see how this could be useful for<br clear="none"><div id="yui_3_16_0_ym19_1_1471641211711_8461">> message boxes.</div><div><br></div><div id="yui_3_16_0_ym19_1_1471641211711_8479">If this were implemented on the language level, you'd basically get message <br></div><div id="yui_3_16_0_ym19_1_1471641211711_8480" dir="ltr">box expansion of A_DOLLVAR for free because msg and obj both share <br></div><div id="yui_3_16_0_ym19_1_1471641211711_8481" dir="ltr">the same code for converting their content into Pd atoms.<br></div><br clear="none">>> I'm not actually sure what changes this would require. At the very<br clear="none">>> least you'd need a <br clear="none">>> new case in the parser for handling dollar signs that don't match the<br clear="none">>> A_DOLLAR or <br clear="none">>> A_DOLLSYM. It seems like you'd need a new atom type, too. Let's<br clear="none">>> call it <br clear="none">>> A_DOLLVAR.<br clear="none">>> <br clear="none">>> How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR? Can it be <br clear="none">>> concatenated with them? (The case for "$@" is that it doesn't<br clear="none">>> concatenate.) But <br clear="none">>> you also have to account for A_DOLLVAR expanding to arbitrarily-<br clear="none">>> deeply-nested <br clear="none">>> lists because it's going to work inside message boxes, too.<br clear="none">>> <br clear="none">>> > == 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<br clear="none">>> the<br clear="none">>> > OSC address (containing an arbitrary number of address fields) to<br clear="none">>> an<br clear="none">>> > abstraction when using [oscformat]. The number of arguments must<br clear="none">>> known<br clear="none">>> > beforehand when using this format. With [packOSC] from the osc<br clear="none">>> 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<br clear="none">>> 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">>> > and [oscformat] would actually see 'base address freq'.<br clear="none">>> <br clear="none">>> Wouldn't it see '(base address) freq'?<br clear="none"><br clear="none"><br clear="none">>No. As I said above, to be really flexible, the user should make it<br clear="none">>explicit whether they want to expand or stay compact. So:<br clear="none"><br clear="none">>[oscformat $1 freq]<br clear="none"><br clear="none">>evaluates to:<br clear="none"><br clear="none">>[oscformat base address freq]<br clear="none"><br clear="none">>However, if we want the nesting to go one level deeper, we would<br clear="none">>create:<br clear="none"><br clear="none">>[myabsabs ( $1 voice1 )]<br clear="none"><br clear="none">>and therein:<br clear="none"><br clear="none">>[oscformat $1 freq]<br clear="none"><br clear="none">>which would evaluate to:<br clear="none"><br clear="none">>[oscformat base address voice1 freq]<br clear="none"><br clear="none"><br clear="none">>This kind of nesting is currently not possible with [oscformat] and<br clear="none">>[oscparse]. That is the one single reason I have to stick with<br clear="none">>[packOSC] and [unpackOSC] (not that it's bad to stay with those, they<br clear="none">>work great. I do have a slight preference for internals, though).<br clear="none"><br clear="none"><br clear="none">>> <br clear="none">>> > There are many other cool things you could do. It would allow to<br clear="none">>> 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<br clear="none">>> using<br clear="none">>> > delimiters or prepended number-of-elements). Generally, it would<br clear="none">>> allow<br clear="none">>> > to create much more flexible abstractions.<br clear="none"><div><br></div><div id="yui_3_16_0_ym19_1_1471641211711_8748">That's starting to sound like more of a language feature than a feature <br></div><div dir="ltr">merely to make abstractions more flexible. If it generalizes for <br></div><div dir="ltr">abstractions, it would probably be useful for Pd messages, too.<br> </div><div id="yui_3_16_0_ym19_1_1471641211711_8749"><br></div><div>>> </div>>> Does [text] address some of this?<br clear="none"><br clear="none">>I think it does to some degree, since you gain one additional dimension<br clear="none">>with the concept of lines. And it makes it easy to create something<br clear="none">>like dictionaries / key-value stores.<div class="yqt0808926372" id="yqtfd78972"><br clear="none"><br clear="none">>Roman<br clear="none"></div><br><div class="yqt0808926372" id="yqtfd23493">_______________________________________________<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>