Hey all,
I've been barely able to keep up with this thread. Lots of ideas and changes. Here I agree with everything that HC has to say.
I'm also a bit confused (anoyed) about the whole list vs nonlist things just for the reasons HC mentions. Miller, you said it is probably "better" to use lists rather than lists that do not start with "list" as the first element, non-lists. Why is this?? I think a list should be:
* interpreted in many cases as a non-list. (ie creating OSC names for example, [list send /hello/blah value] automatically gets rid of the "list" part because it knows what to do about it.
* be able to contain a mix of symbols and float atoms
* there be only be one "list-like" thing, I don't know what this would make a non-list into... an undefined list? One would not need a non-list if the first point above was true and the "list" part not considered part of the list. (NOT the first element, but something invisible that you never need to see, like "float [float]" where I have never had the need to worry about it but the damn list selector comes up all the time. :(
Thats all for me.
b>
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
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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev