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.
No. As I said above, to be really flexible, the user should make it
> 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'?
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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list