[CM] Help sought for a macro

[Iain Duncan]

Oops, you're right I meant to start the example with the ~> macro. And I'm
not really attached to whether or not one has to write "eval" or not, or
even start with that clause. That thing could be whatever: variable,
symbol, number, string.  It could just as usefully be (where $i1 is integer
from an incoming max message)

So maybe this is a better example (albeit a bit contrived), where the
message is triggered by a message with two values, that become $i1 and $i2
(max does this for us)

~> random $i1 ~> + $i2 _ ~> * -1 _
which could also be, if I'm thinking straight, written as:
~> eval $i1 ~> random _ ~> + $i2 _ ~> * -1 _

Does that make more sense? I had originally been thinking of the clojure
syntax for thread first and thread last, but then upon seeing the chain
sfri, I thought the use of _ was going to be more generally readable, and
more useful in cases where one might be interpolating to anywhere in arg
positions. Just seems like an elegant version of Clojure's thread-as macro?
The issue in max is that one has to do something different when you have
the parens in there, requiring more message objects in the patch. (you have
to make it a symbol, and then pipe it to s4m as eval-string {symbol}. It's
certainly not a big inconvenience, but it would be nice to support both
options.

thanks for looking at this!

On Sat, Sep 19, 2020 at 1:47 PM Christos Vagias <chris.actondev at gmail.com>
wrote:

> I kind of get it, but I think that your example should be
> (~> eval x ~> fun1 arg1 _ ~> fun2 _ arg2 arg3)
>
> To produce the same thing as you said,
> (fun2 (fun1 arg1 (eval x)) arg2 arg3)
>
> I realise that x in your case will always be incoming string data that you
> want to eval it,
> and for the sake of "syntactic sugar" you want to skip writing eval  every
> time.
>
> But that would be a special case that is built upon the ~>. And for the ~>
> I think
> the modification I mentioned would be needed. Also, in this example, in
> the "eval x" form,
> the "_" would be nil to start with.
>
> So the first step is to agree on the syntax :)
> After that, could probably dig a bit into it next week (from Monday on)
> and will let you know
> in private.
>
>
> On Sat, 19 Sep 2020 at 22:23, Iain Duncan <iainduncanlists at gmail.com>
> wrote:
>
>> thanks Christos. I guess my one liner example was not clear, it's not
>> infix notation, it's still prefix notation, just as one whitespace and
>> token separated call. As in, the first slot in each ~> delimited s-exp is
>> still a function call, the parens are just implied. I imagine it's not of
>> use to anyone outside of Max, but it will be very useful in that context.
>> To clarify what I meant, this is probably a better example:
>>
>> (x ~> fun1 arg1 _ ~> fun2 _ arg2 arg3)
>> would execute the same as
>> (chain (eval x) (fun1 arg1 _) (fun2 _ arg2 arg3) )
>> which is also equivalent to
>> (fun2 (fun1 arg1 (eval x)) arg2 arg3)
>>
>> so it's really just a way to write chains without having parens in there,
>> the reason being that lists in messages with max are very easy to work with
>> when they are all whitespace separated tokens, and allow interpolation with
>> max's built in tools. So it allows people to make s4m "one-liners" that
>> replace a whole wack of max objects for some use cases, and have access to
>> s4m variables.
>>
>> iain
>>
>>
>> On Sat, Sep 19, 2020 at 1:13 PM Christos Vagias <chris.actondev at gmail.com>
>> wrote:
>>
>>> Hi Iain,
>>>
>>> Wasn't aware of the chain srfi. Interesting.
>>> Since I'm coming more from clojure I guess I'll focus a bit more on the
>>> "as->", "->" and "->>".
>>> Could try fiddling with these from Monday on and will keep you posted on
>>> the process.
>>>
>>> The "(x ~> a _ b ~> c _ )" form seems kinda too much though, adding
>>> infix notation to the mix
>>>
>>> On Sat, 19 Sep 2020 at 19:37, Iain Duncan <iainduncanlists at gmail.com>
>>> wrote:
>>>
>>>> Hi colleagues, I'm trying to figure out how to build a couple of
>>>> threading macros that would be very helpful in Max/MSP for Scheme for Max,
>>>> but it is frankly over my head right now. Working it out will be a good
>>>> exercise but I figured I would post here in case this is trivial for some
>>>> macro experts in S7 and they are willing to share something I can study.
>>>>
>>>> I want to implement something like srfi-197, where it is called
>>>> "chain". (but srfi-197 uses syntax-case and syntax-rules)
>>>>
>>>> so from the docs there:
>>>>
>>>> (chain x (a b _)) ; => (a b x)
>>>> (chain (a b) (c _ d) (e f _)) ; => (let* ((x (a b)) (x (c x d))) (e f x))
>>>> (chain (a) (b _ _) (c _)) ; => (let*-values (((x1 x2) (a)) ((x) (b x1 x2))) (c x))
>>>>
>>>>
>>>> But what I'd really to make on top of that is a version for allows one
>>>> to use this for one liners in Max without inner parens, so something like
>>>> this, where the macro is ~>
>>>>
>>>> (x ~> a _ b ~> c _ )
>>>> becomes something  equivalent of:
>>>> (c (a (eval x) b))
>>>>
>>>> Because Scheme for Max will take a max message and treat it as code to
>>>> be wrapped in outer parens and then eval'd, this will let people do very
>>>> useful things in one short max message (where say $i and $i2 come from
>>>> another max message sending to it:
>>>>
>>>> $i1 ~> + 10 _ ~> / $i2 _
>>>>
>>>> If anyone has suggestions or feels like helping that would be amazing.
>>>> thanks!
>>>> _______________________________________________
>>>> Cmdist mailing list
>>>> Cmdist at ccrma.stanford.edu
>>>> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20200919/50cbd696/attachment-0001.html>