[PD-dev] proposed new "list" object

[Hans-Christoph Steiner]

On Wed, 20 Jul 2005, Georg Holzmann wrote:

> Hallo!
>
>>     list append - append a list to another
>>     list prepend - prepend a list to another
>>     list cat - build a list by accumulating elements
>>     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
>>     list pack - synonym for 'pack'
>>     list unpack - synonym for 'unpack'
>>     list selector - change selector of a list
>>     list <no args> - "prepend" the selector list to non-list messages
>
> just some more suggestions (these objects are often the reason why I  
> have to
> use externals in simple patches):
>
> 1) a storage object for lists would also be useful in main-pd (like  
> "lister"
> from zexy - maybe the easiest way would be to make a 2.inlet at the  
> "list"
> object (to have the same behaviour as "symbol" or "float" ...) ?
>
> 2) get a specific element from a list (like "packel" from zexy) - so  
> it's
> easier to handle dynamic length list (if you know which atoms you want  
> and
> don't know the exact length)
> don't know a good name, maybe "list get" or "list packel" (IOhannes:  
> why
> packel?)
> (also I don't if it is a good idea to count the elements from 1 and  
> not from
> 0 - like in packel ...)
> -> maybe also a "list set", where you can set a specific element in a  
> list
> without unpack - repack everything (which is not possible if you don't  
> know
> the exact size ...)

Since I think we should try to implement as much of Pd in Pd, I think
these two (get/set) should both be implemented in Pd.  They would be  
quite
straightforward to do, though Matju might demonstrate how inefficient
these would be.

>> 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:
> Hm - I see, but what is the advantage of only handle messages with
> list-selector (beside that you can use the name "list" for the objects  
> ...
> :) ?
> This means you often have to:
>
> |
> [list]  - add a list selector
> |
> do something like [list reverse]
> |
> [list selector]  - remove again the list selector
> |
>
> (should it also be possible to remove the list selector at all with  
> "list
> selector" ?)

That could come in handy since sometimes that can be a problem and  
there is currently know way to do this AFAIK.

.hc

	zen
	   \
	    \
	     \



________________________________________________________________________ 
____

"Information wants to be free."
                                      -Stewart Brand