[PD-dev] proposed new "list" object

[Hans-Christoph Steiner]

On Tue, 19 Jul 2005, Miller Puckette wrote:

> Hi devs...
>
> I'm thinking about finally writing a "list" object for Pd to do jobs
> like "append", "any", etc.  I've held off so far because I've felt
> unsure about the best design... and once I stick it in the "base" Pd
> it will be hard to change.

But it will be well worth the effort.  All in all, it seems like a useful
bunch of objects.  I am very happy to see this issue coming up now.

> To avoid cluttering up the namespace I want to use just the one name,
> "list", and use the first argument to differentiate between functions
> (an idea inspired by Krzysztof's xeq object).  Here are the functions I
> imagine:

Since there are currently no core Pd objects that use the [obj action]
syntax, I think we should try to avoid introducing it for a number of
reasons.  For example, I think these functions would work fine as
individual objects, and in many cases they would be generally useful with
things besides lists, like undefined sets for example.

As for the namespace question, that would be solved with some method of
dealing with the namespace rather than more obscure names.  I think that
Pd would work very well with a Java-style namespace, using the Geiger
namespace as a starting place.  The core objects would be included in the
namespace by default.  Any object could be called in the geiger namespace
style at anytime [maxlib/average] for example.  Then collections of
externals could be imported, so if a patch had [import maxlib] then
[average] would be the same as [maxlib/average].  The main missing piece
to implementing this is an [import] or some similar mechanism.  Guenter
already has a global version of this working (I think its called
[declare]?).  Then there would be an order of precedence for local names.
Java's is: 0) local names 1) imported names 2) core names, with local
names being able to override imported names and core names, and so on.

>     list append - append a list to another

A general purpose [append] would be very handy too.

>     list prepend - prepend a list to another

Krzysztof's [prepend] works quite well for this, and works with anything.

>     list cat - build a list by accumulating elements

This could be done simply with [prepend] or [append] and a list storage
object.

>     list serialize - spit out elements of a list one by one
>     list first - output first n elements
>     list last - output last n elements
>     list length - output number of items in list
>     list reverse - permute elements of a list back to front

It would be nice if these functions worked with all sets, not just lists.
That's the way [zl] works.  It could work so that if it receives lists, it
will output lists.  If it receives undefined sets (i.e. sets that begin
with a symbol) then it would output sets without "list" prepended.

>     list pack - synonym for 'pack'
>     list unpack - synonym for 'unpack'

What would these do differently that the originals?

>     list selector - change selector of a list

Sounds handy, but also, it would be handy for undefined sets as well.

>     list <no args> - "prepend" the selector list to non-list messages
>
> The "append" option would also play the role of "any" (just bang the left
> inlet after putting any list in the right).

How about [list] being a storage object too, like [symbol], [int],
[float], [pointer]?  [list( = [bang( seems to cause more trouble than not.


.hc


> All of these would expect the "list" selector at the head of messages, with
> the exception of plain "list"; all of them would output "list" messages except
> "list selector".  These would work as follows:
>
> --------------------------- list ----------------------------------
> in (real message)   in (as printed)    out (real message)    out (as printed)
> list                bang               (same)
> list 1              1                  (same)
> list foo            list foo           (same)
> foo                 foo                list foo              list foo
>
> --------------------------- list  selector bar -------------------------
> in (real message)   in (as printed)    out (real message)    out (as printed)
> list                bang               bar
> list 1              1                  bar 1
> list foo            list foo           bar foo
> foo                 foo                (error)
>
> There's one inconvenience with plain "list" since you can't differentiate
> "list foo" from "foo" using its output; you'd have to use "route list symbol"
> first and then do whatever you wanted to do differently ("list list foo" for
> example).  It seemed better to leave that to the imagination of programmers,
> since there seem to be disagreements about it...



	zen
	   \
	    \
	     \