<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p><span>Maybe instead of changing the existing parsing it would be easier to create a second class of variables which can be defined from within the patch.</span></p>
<p><span><br>
</span></p>
<p><span>So</span></p>
<p><span><br>
</span></p>
<p><span>[30 20(</span></p>
<p><span>|</span></p>
<p><span>[#define vol]</span></p>
<p><span><br>
</span></p>
<p><span>defines #vol as "30 20", and then "#vol" is replaced with "30 20" wherever it is encountered.</span></p>
<p><span><br>
</span></p>
<p><span>Most of Roman's suggestions, and many more things, could then be achieved
</span>by iterating and routing the creation arguments (obtained either by $@ or iemguts/canvasargs]).</p>
<p><br>
</p>
<p>I don't know how easy it would be to have # variables undated in real time, rather than only once when the patch loads. [expr] seems to achieve this by integrating [v] values.<br>
</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Pd-list <pd-list-bounces@lists.iem.at> on behalf of Jonathan Wilkes via Pd-list <pd-list@lists.iem.at><br>
<b>Sent:</b> 20 August 2016 02:15<br>
<b>To:</b> Roman Haefeli; Pd list<br>
<b>Subject:</b> Re: [PD] Feature Proposal</font>
<div> </div>
</div>
<div>
<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 id="yui_3_16_0_ym19_1_1471641211711_7307" class="yahoo_quoted" style="display:block">
<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" 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>
</div>
</div>
</div>
</body>
</html>