[PD] Feature Proposal

[Roman Haefeli]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160820/08b91f45/attachment.sig>