Re: [PD-dev] proposed new "list" object

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 \ \ \