[PD-dev] First attempt at "list" object uploaded

[Hans-Christoph Steiner]

I updated the attached patch to make my point much clearer.  The first 
attempt wasn't so clear.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: list_catalog.pd
Type: application/octet-stream
Size: 2551 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050725/75d2df6b/attachment.obj>
-------------- next part --------------


.hc


On Jul 25, 2005, at 5:36 PM, Hans-Christoph Steiner wrote:

>
> On Jul 24, 2005, at 3:51 PM, Miller Puckette wrote:
>
>> hi all,
>>
>> Thanks for all the discussion, which changed my mind on a number of  
>> points.
>
> I am definitely glad you are working on this!  This is something that  
> will greatly improve message handling in Pd.
>
>> I've uploaded a first attempt at a "list" object to CVS...  see the  
>> help
>> window, which also provides some examples.  So far, I implemented  
>> these
>> options:
>>
>>     list append - append a list to another
>>     list prepend - prepend a list to another
>>     list split - first n elements to first outlet, rest to second  
>> outlet
>>     list trim - trim off "list" selector
>>
>> I'm not sure whether to keep the "list <function>" format or not now;  
>> the
>> list seems divided over it and so am I.  The advantage is it's the  
>> least
>> visually cluttered way to name them.  I can't use "append",  
>> "prepend", or
>> "split" as names in their own right
>
> At pd~conf, we discussed renaming Pd's [append] for data structures to  
> [add] so it would match [get] and [set].  Then [append] could be made  
> to match [prepend].  Also, the current [append]'s help file describes  
> it as "add an item to a list", so [add] makes sense.  There is no  
> existing [add] that I know of.
>
>> (they're already used, and using namespaces
>> to alias well-known names would cause endless confusion!)
>
> Such namespaces work well in many languages like Java, C, C++, perl,  
> etc. etc.  I think there would be rough-ish bits in transition, but in  
> the long run would work much better for managing externals. It would  
> also allow external writers to do whatever they want with their  
> externals yet still be able to interoperate.  The centralized  
> management of a single namespace would no longer be necessary, it  
> would be split up into chunks managed by individuals.  And it would  
> push Pd to the next step of becoming a fully fledged programming  
> language.
>
> This would also allow Pd to have its own distinct namespace without  
> breaking Max compatibility.  If you import cyclone in a patch, then  
> cyclone's [split] would override Pd's.  Then you could rename it to  
> [cyclone/split] and you could take out the import statement and both  
> splits would work.  Or vice versa, with something like [pd/split].
>
>> The advantage to
>> Iohannes's suggestion (list_append, etc.) is that external objects  
>> could supply
>> list_whatever objects that could belong naturally to the series.
>
> Its not so pretty but it would work.
>
>> I think I have an adequate way to deal with non-list messages;  
>> they're converted
>> to lists on input, and the "list trim" object can be used to  
>> explicitly convert
>> back.  I still think it's better style to use "true" lists wherever  
>> possible,
>> but this will probably never find general agreement.  My only advice  
>> is that,
>> if you want to use non-list messages, just never, ever name a file  
>> "bang"!
>
> One of the core problems with message handling using lists is that  
> they are not interpreted consistently across objects.  For example,  
> objects like [route] and  [print] only interpret the first element  
> 'list' when the following body of the message is an implied list, i.e.  
> a set of atoms with a float as the first element.  This means you  
> can't use [route] to deal with a message stream that has both lists  
> and undefined sets.  If this was fixed, it would make mixed message  
> handling in Pd much easier.  With [print], this is a bummer because it  
> means that there is no method within Pd that allows you to see the  
> actual raw messages as Pd sees them.
>
> This leads to me something that can be very confusing when dealing  
> with message streams made up of lists, atoms, and "undefined sets":  
> there are some objects that work with lists and some that work with  
> "undefined sets" and its often not easily apparent to see which is  
> which.  Examples are [route], [print], [prepend].  I attached a patch  
> to illustrate this.
>
> .hc
>
> <list_catalog.pd>
> _______________________________________________________________________ 
> _____
>
>  As we enjoy great advantages from inventions of others, we should be  
> glad of an opportunity to serve others by any invention of ours; and  
> this we should do freely and generously.
>                                                                         
>                           - Benjamin Franklin
>

________________________________________________________________________ 
____

"Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war on  
terrorism."

                                                                          
                        - retired U.S. Army general, William Odom