I understand what is going on, what I don't understand is why it was done like this. Basically, I don't see any benefit to having a mixed type message (symbols and floats) be treated differently depending on whether it starts with a float or a symbol. It makes general message handling a lot more difficult because you often have to do things differently for all these different conditions, rather than having a more unified approach. Maybe there is something I am missing, but I have tried a number of different approaches with basically the same outcome.
.hc
On Monday, Mar 15, 2004, at 04:54 America/New_York, Krzysztof Czaja wrote:
hi Hans-Christoph,
what drives you nuts is the message-passing system -- pure data structured types are quite another story. In the message-passing system, the only typed entities are "atoms". Every message is being handled as
<selector> <atom>*
The <selector> is a symbol, which purpose is to determine a method -- the actual handler, as defined by a class for that kind of a message (so, in short, you cannot bind methods to particular floats in Pd).
When the message-passing system (actually, the binbuf_eval() routine in this case), constructs a message from a sequence of atoms, it just tries to be nice and smart, that is all. First atom being a symbol, becomes the selector. If it is a float, and there are no more atoms, the message is to be handled by a "float" method, if defined, otherwise the handler is the "list" method.
I wonder, perhaps you will be less confused, if you think about the Max-in-Pd part in terms of a communication protocol of sorts?
Krzysztof
Hans-Christoph Steiner wrote:
There are a number of datatype inconsistencies that drive me nuts in Pd and I am wondering what the rhyme or reason is, or whether they are just
...
Ok, I can see that anything that starts with a float is automatically deemed a list, while anything that starts with a symbol is automatically deemed not a list unless cast as such. This is confusing and I don't see the benefit.