On Jul 28, 2005, at 5:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This investigation lead me to another odd behavior: [route symbol] outputs a symbol on its left outlet, while [route list] outputs a non-list. While it is definitely useful to have an object with can strip off the "list" selector, I don't think it should be called [route list]. [route list] should output a list for every list it receives on its inlet.
But
[something which is a kind of list( | [route something]
will strip of the "something" part, so stripping off "list" with "route list" is consistent with that behaviour.
Apart from that, using [route list] to trim lists of "list" is probably very common (Iohannes does it, I did it) so changing it would mean breaking patches.
These two points are definitely true, I am not saying that it would be an easy change. But I think [route list] would have to always output a list on its left outlet in order for Miller's suggestion to work, which was to try to treat everything as a list when doing message handling. I could be wrong, but I think we should try it.
Also, [route symbol] does not trim the selector "symbol", so there is a precedence here. We can look at the reserved words in Pd: "bang", "float", "symbol", and "list". [route bang], [route float], [route symbol] all output the same data type on their left inlet. [route list] does not always output a list, even though it is interpreting incoming lists, not merely routing by keyword. More example patches!
In the process, I documented some more behaviors of Pd related to all this. [trigger list] outputs a list for everything except sets starting with a symbol that is not "list". It also interprets lists on input, like [route list] (i.e. [list 1 2 3( is [1 2 3( on the outlet).
According to [route bang float symbol list], [float( remains a float and is inited to 0. [symbol( remains a blank symbol. [list( is converted to a bang.
And another: [float 1( remains a float; [float 1 2 3( remains a float, but is cut to one element; [list 1 2 3( remains a list; and [list 1( is converted to a float. (It would be nice to have a warning when [float 1 2 3( is chopped to one element, that could help with debugging perhaps).
And lastly: [print] interprets all floats (i.e. [1( and [float 1( both output "1"). [print] does not interpret symbols (i.e. [symbol test( prints "symbol test", [symbol( prints "symbol") and only interprets lists whose first element is a float.
I am not saying that all these things I am documenting must change, I am trying to demonstrate what makes handling data in Pd so confusing at times, especially when working with lists. Things do not always behave consistently or intuitively.
In order for things to get better, there will have to be some changes that will break backwards compatibility. But that's why Pd is version 0, right? Plus for old patches, you can always use old versions of Pd. Many programs break backwards compatibility in the quest for 1.0, its too be expected. Its the only way to make real progress.
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!