I updated the attached patch to make my point much clearer. The first attempt wasn't so clear.
.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