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 bugs. I have tried to start documenting them as I come along them. Here's a start:
When is a list a list? According to [route]:
[list 1 2 3( is a list [1 2 3( is a list [list one two three( is a list [one two three( is NOT a list [one 2 3( is NOT a list [1 two three( is a list
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.
.hc
#N canvas 704 57 539 385 10; #X msg 126 63 1 2 3; #X obj 149 202 route list; #X obj 149 223 print list; #X obj 224 223 print NOTlist; #X msg 118 43 list 1 2 3; #X msg 145 88 list one two three; #X msg 152 107 one two three; #X msg 167 130 1 two three; #X msg 174 160 one 2 3; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 1 3 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 1 0; #X connect 7 0 1 0; #X connect 8 0 1 0;
Hello Hans & list
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.
Wouldnt this be related more to route then to list?
From the route help files: " Route check the first element of a mesage
agains each of its arguments, which may be numbers or symbols (but not a mixture of the two)."
Maybe the list cant be a mixture either?
Cheers Anton
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.
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.
hi Hans-Christoph,
Hans-Christoph Steiner wrote: ...
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 how would you unify these -- by using float selectors, or not using selectors at all?
Krzysztof
On Tuesday, Mar 16, 2004, at 07:48 America/New_York, Krzysztof Czaja wrote:
hi Hans-Christoph,
Hans-Christoph Steiner wrote: ...
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 how would you unify these -- by using float selectors, or not using selectors at all?
I am not sure of how to what needs to be done, so I wanted to start a discussion as to what the overarching structure of message handling is, in situations like these, so that we could come up with some solutions to making things more intuitive. Or at the very least, we could write some in-depth docs explaining it.
I guess the crux of the matter is that a group of floats is assumed to
be a list while a group of symbols is not. I am wondering why floats
would be treated differently than symbols when they are all messages.
This also has implications on mixed-type messages, which I use a lot.
One way to work around this would be to have [route] check for
mixed-media messages and treat them all the same. But this could get
computationally expensive if the messages where large.
.hc
On Sun, 14 Mar 2004, Hans-Christoph Steiner wrote:
[list 1 2 3( is a list [1 2 3( is a list [list one two three( is a list [one two three( is NOT a list [one 2 3( is NOT a list [1 two three( is a list 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.
A message has two parts, a selector and an argument list. it's like a function call: "list 1 2 3" does something like call list(1,2,3) in the context of an object and inlet. However, a selector must be a symbol, and if it's not, then Pd has to fake it and pull something from somewhere. So the rules are:
single float messagebox -> selector "float" multi-element messagebox starting with float -> selector "list" any messagebox starting with a symbol -> selector is that symbol
In addition there are fallback rules so that if the function is not defined, other calls are attempted. e.g. selector "float" vs single-float list.
Well, that's what I think it is... looks rather simple to me.
However, the docs may be a bit confusing wrt selector-vs-arguments distinctions, and may call a selector a "first argument"... sigh
(Hey. I wrote all of this message days ago. And then I forgot to send it. Silly me.)
Mathieu Bouchard http://artengine.ca/matju
On Friday, Mar 19, 2004, at 12:04 America/New_York, Mathieu Bouchard wrote:
On Sun, 14 Mar 2004, Hans-Christoph Steiner wrote:
[list 1 2 3( is a list [1 2 3( is a list [list one two three( is a list [one two three( is NOT a list [one 2 3( is NOT a list [1 two three( is a list 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.
A message has two parts, a selector and an argument list. it's like a function call: "list 1 2 3" does something like call list(1,2,3) in the context of an object and inlet. However, a selector must be a symbol, and if it's not, then Pd has to fake it and pull something from somewhere. So the rules are:
single float messagebox -> selector "float" multi-element messagebox starting with float -> selector "list" any messagebox starting with a symbol -> selector is that symbol
In addition there are fallback rules so that if the function is not defined, other calls are attempted. e.g. selector "float" vs single-float list.
Well, that's what I think it is... looks rather simple to me.
However, the docs may be a bit confusing wrt selector-vs-arguments distinctions, and may call a selector a "first argument"... sigh
(Hey. I wrote all of this message days ago. And then I forgot to send it. Silly me.)
Right, to reiterate, I understand what is happening, but I am wondering
why. This set up makes handling mixed symbol/float messages in a
general way more difficult and I don't see the benefit of this system.
I am a big fan of "as simple as possible, but no simpler". I am
wondering if this could be simpler.
I have started making patches that illustrate confusing message behavior with the aim of hopefully smoothing some out, or at the very least documenting them well. I would like to use lists in this way, but I find I mostly use [prepend]s with message handling because they are simple and general to all message types. But it always feels like I am cheating a bit, like there should be a better way.
.hc
On Fri, 19 Mar 2004, Hans-Christoph Steiner wrote:
Right, to reiterate, I understand what is happening, but I am wondering why. This set up makes handling mixed symbol/float messages in a general way more difficult and I don't see the benefit of this system. I am a big fan of "as simple as possible, but no simpler".
I am wondering if this could be simpler.
I think this might be the result of evolution of dataflow systems from one in which only single values would be transmitted, to one augmented with the OOP concept of message (a kind of abstracted function call). I think the current way of handling this is pretty much the simplest, or perhaps there is a slightly simpler way of having the same functionality, that is probably not worth migrating to (way too much compatibility trouble).
jMax has had those semantics changed from 2.5 to 4.0, and generally speaking it's been a mess.
Mathieu Bouchard http://artengine.ca/matju
-
Anton Woldhek -
Hans-Christoph Steiner -
Krzysztof Czaja -
Mathieu Bouchard