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

[Hans-Christoph Steiner]

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

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

________________________________________________________________________ 
____

  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