Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Yes but to me [1 two three four( and [one two three four( are both lists and pd shouldn't treat them differently as it now does.
And what about [one two three four( and [list one two three four( ? Should these both be 4-element lists or should one be a 5-element list? Should "float 2" be a 2-element list or a 1-element number? Should "symbol foo" be a 2-element list or a 1-element symbol?
The way I see it, they should be both 4-element lists. The first is an implicit list.
"float 2" and "2" are both float atoms so they should be 1-element lists. The second is an implicit float atom.
"foo" is an implicit symbol. It too should be a 1-element list. In pd explicit symbols go into an ever-expanding heap via gensym but implicit ones don't. You have to say "symbol foo" to get it 'registered' there but it can still be an 'unregistered' implicit symbol.
As I understand it, internally any single element has a type (usually float or symbol) associated with it. A list is (logically) just one or more of these atom elements. There is no element of type 'list' but there are objects to manipulate lists of elements.
Maybe pd should just treat all elements as lists?
Pd currently acts like this:
"cat Garfield" is one and not two cats.
"mice Micky Minnie" is two and not three mice.
"list mice Micky Minnie" however are three whatevers of unknown animal type. [list trim] could convert the three whatevers to two mice named "Mickey" and "Minnie".
This mechanism allows users to define their own types (of animals) and still do the same operations on them that they can do on the built-in types.
For example using [list] it's possible to make a group of mice and cats. For this, [list] first internally converts "mice Micky Minnie" and "cat Garfield" to proper list-messages: "list mice Micky Minnie" and "list cat Garfield".
Yes, but I'm saying that pd should automatically make "mice Mickey Minnie" into a list without the user having to explicitly pass it through [list], because after all what else could it be? And if the first element of a list is 'mice' that doesn't make 'Mickey' or 'Minnie' into 'mice', they are just symbols that may be routed using 'mice' as a selector/first-element-in-the-list. (In the sense that there is no type-checking going on.)
Now all objects, that know how to deal with list-messages but maybe not with cat- and mice-messages can deal with the combination message: "list mice Micky Minnie cat Garfield".
Now try to imagine an animal called "set". It's an almost extinct reptile living in South America that was once seen there in real live by Derek Holzer who recorded it and won a prize with that specific field recording at Transmediale 2005.
Jus' kidding.
A "set"-animal would totally confuse a lot of objects in Pd, most notably the [message(-object, but also tabread etc.
There are some reserved words like 'set' and 'float', 'symbol' and 'list' that shouldn't be used as the first element of an implicit list. If you need to do that you should pass them through [list] to get them to work, in the same way [symbol] is used to make sure something is interpreted as a symbol, but normally a multi-element message should be converted to a list.
However as Pd knows about list-messages, it is no big deal to use such an animal in your patches, because you just use [list] or something else to generate a proper list-message and then go on and put lots of set-animals with various names in cages and start breeding to save them from extinction.
Without Pd's use of the list-selector this would be harder to achieve in such a simple way.
For sure, just that the list selector should be implied if it's not needed to override another type-cast. So 'list float 5' would make a list containing the symbol 'float' and the float '5', whereas 'float 5' would just make the float '5', just as '5' makes a float '5'.
Martin