[PD] Feature Proposal

[Matt Barber]

Reminder that IOhannes came up with a solution for variable args quite a
while ago. See attached, which allows up to 10. It can be extended to
whatever you think the maximum is, or if you really feel like it it's easy
to dynamically patch.



On Fri, Aug 19, 2016 at 6:13 PM, Roman Haefeli <reduzent at gmail.com> wrote:

> Hi Jonathan,
>
> On Don, 2016-08-18 at 19:28 +0000, Jonathan Wilkes wrote:
> > Hi Roman,
> > I'll try to address the question of how difficult each of these is to
> > implement.
> > [...]
> >
> > > == GROUPING IN ABSTRACTION ARGUMENTS ==
> > > Allow grouping of atoms, so that you can pass a whole list to one
> > > single argument like this:
> >
> > > [myabs ( one two 3 ) 4 five]
> >
> > > inside the abstraction:
> >
> > > $1 would evaluate to 'list one two 3'
> > > $2 would evaluate to '4'
> > > $3 would evaluate to '5'
> >
> > This would require changes to t_atom because there is no "list" atom
> > type.  That's
> > a fairly involved change, especially given that plenty of internal
> > and external classes
> > do "lazy" type checking (if it isn't a float it must be a symbol,
> > etc.).
>
> Thanks for the insight. That doesn't like realistic thing to do, then.
>
> > > == GETTING NUMBER OF ARGS ==
> > > With the same example:
> >
> > > [myabs ( one two 3 ) 4 five]
> >
> > > inside the abstraction:
> >
> > > $# would evaluate to '3' (number of arguments given)
> >
> > This requires changes to the parser, which requires extensive testing
> > and
> > bug fixing, too.
> >
> > Pd-l2ork uses "$@" to expand to all the arguments, which you can
> > then shoot to a [list length] to get the equivalent of "$#".  It's
> > based off a patch
> > submitted originally submitted to Pd Vanilla by IOhannes which is
> > probably
> > still hanging around on the sourceforge patch tracker.
>
> $@ alone would be already quite a cool feature. I hope it'll get
> accepted once in Pd-vanilla, too.
>
> > > == GROUPING IN MESSAGES ==
> > > [1 2 ( 97 98 99 ) 4 5(
> > > |
> > > [$2 (
> >
> >
> > > would give '97 98 99'
> >
> > Did you mean [$3(?
>
> Oh, yes. Sorry for that.
>
> > If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'?
>
> I think it should be up to the user to decide whether to stay compact
> or expand. So, [$3 3( would give you the expanded version '97 98 99 3',
> while [ ( $3 ) 3 ( would output
> '( 97 98 99 ) 3'.
>
>
> > In other words, what would be the rule for flattening a list atom
> > into
> > a series of atoms?
>
> You have to put something explicitly in between parentheses to stay
> compact.
> >
> > Regarding parentheses-- Gridflow adds a syntax like that for
> > handling
> > nested message data.  I don't like the idea in general, but I like
> > Gridflow's
> > implementation better than your example because it doesn't require
> > space in between the parentheses and the data itself.
>
> I'm no proponent for spaces, but I assumed it would make the idea
> easier to realize (which is moot now) and would be more Pd-like.
>
>
> > Anyhow, this is another parser change (in m_binbuf).
> >
> >
> > > == NAMED ARGUMENTS ==
> >
> > > [myabs freq=440 vol=1]
> >
> > > inside the abstraction:
> >
> > > $freq would evaluate to '440'
> > > $vol would evalute to '1'
> >
> > > If a certain argument is not specified as creation argument, it
> > would
> > > evaluate to '0' (similar to existing behavior).
> >
> > What would $1 and $2 evaluate to in this case?
>
> In order to stay backwards compatible, I think they should have the
> same behavior like now:
>
> $1 -> 'freq=440'
> $2 -> 'vol=1'
>
> > What would [$freq( expand to?
>
> It would not expand to anything, it would just output '$freq'. I don't
> see why there should be any expectation that $-args in message boxes
> would expand to creation arguments. Named arguments really only make
> sense as creation arguments. I don't see how this could be useful for
> message boxes.
>
> > I'm not actually sure what changes this would require.  At the very
> > least you'd need a
> > new case in the parser for handling dollar signs that don't match the
> > A_DOLLAR or
> > A_DOLLSYM.  It seems like you'd need a new atom type, too.  Let's
> > call it
> > A_DOLLVAR.
> >
> > How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR?  Can it be
> > concatenated with them?  (The case for "$@" is that it doesn't
> > concatenate.)  But
> > you also have to account for A_DOLLVAR expanding to arbitrarily-
> > deeply-nested
> > lists because it's going to work inside message boxes, too.
> >
> > > == USE CASE ==
> > > [oscformat] takes an arbitrary number of arguments to create an OSC
> > > address. While I find this the cleaner and more pd-like way than
> > > /one/two/three, this has big draw-back. You currently cannot pass
> > the
> > > OSC address (containing an arbitrary number of address fields) to
> > an
> > > abstraction when using [oscformat]. The number of arguments must
> > known
> > > beforehand when using this format. With [packOSC] from the osc
> > library,
> > > you can do:
> >
> > > [myabs /base/address]
> >
> > > and therein:
> >
> > > [packOSC $1/freq]
> >
> > > which evaluates to /base/address/freq.
> >
> > > By allowing grouping of arguments, one could achieve the same
> > without
> > > resorting to long symbols (which has other drawbacks). In the main
> > > patch you could create:
> >
> > > [myabs ( base address )]
> >
> > > and therein:
> >
> > > [oscformat $1 freq]
> >
> > > and [oscformat] would actually see 'base address freq'.
> >
> > Wouldn't it see '(base address) freq'?
>
>
> No. As I said above, to be really flexible, the user should make it
> explicit whether they want to expand or stay compact. So:
>
> [oscformat $1 freq]
>
> evaluates to:
>
> [oscformat base address freq]
>
> However, if we want the nesting to go one level deeper, we would
> create:
>
> [myabsabs ( $1 voice1 )]
>
> and therein:
>
> [oscformat $1 freq]
>
> which would evaluate to:
>
> [oscformat base address voice1 freq]
>
>
> This kind of nesting is currently not possible with [oscformat] and
> [oscparse]. That is the one single reason I have to stick with
> [packOSC] and [unpackOSC] (not that it's bad to stay with those, they
> work great. I do have a slight preference for internals, though).
>
>
> >
> > > There are many other cool things you could do. It would allow to
> > create
> > > lists of lists, which can be easily split again later (which is
> > > currently very hard to do and involves a lot of serializing and
> > using
> > > delimiters or prepended number-of-elements). Generally, it would
> > allow
> > > to create much more flexible abstractions.
> >
> > Does [text] address some of this?
>
> I think it does to some degree, since you gain one additional dimension
> with the concept of lines. And it makes it easy to create something
> like dictionaries / key-value stores.
>
> Roman
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160819/b7dc5c7d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: args.pd
Type: application/octet-stream
Size: 5564 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160819/b7dc5c7d/attachment-0001.obj>