Hi,
Maybe I'm late, but I try to answer to the questions that have been
raised about the list stuff, for two reasons: first, in case this is
helpful to those who asked, and second, so that those who know more than
I do can correct me where I'm wrong or show me if the whole thig can be
stated in a different way.
This is my understanding of how lists and messages interact.
1) The "float" or "list" identifiers are implicit when a message starts
with a number atom, so
[1( is equivalent to [float 1(
[1 2 3( is equivalent to [list 1 2 3(
Another way of stating this (perhaps more correct??) may be that a
message cannot start with a number atom, i.e. it always starts with a
symbol atom which is its identifier, so if you type "1" into a message
box (or a text file read by [textfile]) the message actually generated
has an implicit (or automatically added) "float" or "list" identifier -
Which of the two interpretations is more correct is, from my point of
view, just an implementation matter.
2) One-element lists are equivalent to symbols or numbers, depending on
the type of their only element, so
[list foo( is equivalent to [symbol foo(
[list 1( is equivalent to [float 1( - which is equivalent to [1(
3) Equivalent means that ALL objects in Pd will treat such messages
exactly the same way. The fact that some signal objects such as
[*~]
will not accept "list <somenumber>" complaining they have no method for
list, is in my opinion a BUG. Somebody just forgot to do the needed
conversions at the inlets. I remember someone agreed with me on this.
Whether the conversions are made at outlets or inlets of objects is
another implementation matter that I think should be
transparent/irrelevant to the user.
4) A "bang" is equivalent to an empty list, so
[bang( is equivalent to [list(
A message with identifier "bang" _and_ arguments, such as
[bang 1 2 3( or [bang foo bar(
is equivalent to just "bang". At least, [list] objects and [route] treat
it as such and ignore its arguments.
5) [route] has a peculiar behaviour, fairly well defined, perhaps less
well documented, more pragmatical (maybe) than elegant, but pretty
consistent, which seems to be:
a. If the arguments are all symbolic atoms, they match the message
identifier
b. If the arguments are all numbers, they are interpreted as the
first element of a list starting with a number; that is, any list
starting with a float that matches an argument, will go out through the
corresponding outlet (with the matching float stripped; i'll go into
stripping later). Any non-list message will go unmatched.
c. You can use "symbol", "float", "bang" or "list" as arguments of
[route]; consistently with what stated at point (a), a symbol (which is
a message whose identifier is "symbol") will match the "symbol"
argument, etc.
d. Since "symbol foo" and "list foo" are perfectly equivalent
messages, it won't matter how you write them, they both mean the same to
[route]. So this raises a potential ambiguity: What do you expect to
happen with
[symbol foo(
|
[route symbol list]
?
This is both a (one element) list and a symbol. Well, this will match
the "symbol" argument (i.e. be output at the first outlet)
The same would happen with [list foo(, since it is exactly the same.
Consistently, though surprisingly at first sight, this:
[list foo(
|
[route list]
will output the list to the "unmatched" (second) outlet, since the
message is recognised as a symbol.
For the same reason,
[list 1(
|
[route list]
will go unmatched, since the message is recognised as a float.
That is, "being a float" or "being a symbol" takes priority over "being
a one-element list".
This is (i suppose) for the sake of being able to distinguish symbols
from floats and from lists. Imagine it wouldn't be so. You couldn't
expect [route] to distinguish "list 1" from "1" or "float 1" since this
would break the equivalence rules; but then, it would match floats and
symbols as lists and you couldn't even distinguish floats from symbols
(they would all be one-element lists).
Well maybe it was more obvious than i've made it: the specific takes
priority over the general, that's it.
e. If you mix numeric arguments with non-numeric arguments, then the
symbolic arguments match a list starting with them as symbol, i.e.
[list foo bar(
|
[route 1 2 foo]
will match foo, and output "bar" at the third outlet, while
[foo bar(
|
[route 1 2 foo]
will go unmatched.
I don't think this is documented anywhere and it is rather questionable
whether one can expect it... however it is kind of consistent to what it
does with floats.
f. This was about matching. Now about the "stripping" behaviour of
[route]. Here I do think it has some arbitrary aspects, that is it could
behave differently than it does and still be consistent (or even more
consistent?), or maybe it's me who don't see the reasoning that make its
behaviour the "only consistent possible one" (not that it needs be).
Well, here it is:
- When the identifier of the message, other than "list", "float",
"symbol", "bang", is matched, it is stripped. For example:
"foo bar 1 2 3" ->[route foo]-> "bar 1 2 3"
- No illegal message can be produced, so:
-- an empty message will be converted to a bang
-- a message starting with a number will become a list
(or you may say it already implicitly is)
For example:
"foo" ->[route foo]-> "bang"
"foo 1 2 3" ->[route foo]-> "list 1 2 3" (or "1 2 3" which would be
the same)
"bang" ->[route bang]-> "bang"
- The "float" identifier cannot be stripped
(or you may say stripping it is identical to leaving it intact
since "float 1" becomes "1" which is identical to "float 1")
Here comes the (imho) questionable part:
- The "symbol" identifier WON'T be stripped, but
- The "list" identifier WILL be stripped
(when legal, i.e. when the first element is not a float)
That is:
"list foo bar" ->[route list]-> "foo bar"
"symbol foo" ->[route symbol]-> "symbol foo"
I personally think that either both or none should be stripped. My
personal experience kind of suggests to me that NOT stripping the symbol
identifier is probably more desirable (dunnow if it can be "proven" to
be so), so I think not stripping the list identifier would be more
consistent. Then a simple and general rule could be stated: "All the
special identifiers (list, symbol, float, bang) are stripped, while all
other identifiers are not"; now you have to exclude list.
I may guess that at some point of history the [list trim] object didn't
exist, so [route list] was the only way of stripping a list identifier
and converting a list to a non-list?
- finally, when numeric arguments are used and a list starting with a
number is matched, e.g. [1 2 3(->[route 1], both the "list" identifier
_and_ the matched first element are stripped, that is:
"list 1 foo bar"->[route 1]->"foo bar", not "list foo bar"
Obviously when the second element is also a float, the list identifier
cannot be stripped (or you may say, stripping it is irrelevant). The
result is still a list.
6) All [list ...] objects convert any message to a list prior to
performing with it the operations they have to perform.
This includes [list length] which indeed once upon a time didn't. That
is, [foo 2 3 4(--[list length] gave 3. Now it gives 4, consistently with
the rule that the message is converted to a list prior to anything, as
with all other list objects. This was a break of backward compatibility
(in the case of patches relying on [list length] to count the number of
arguments of a non-list message) for the sake of consistency.
I'm not sure exactly where all this information comes from. I think the
most part is stated in the "all about data types" patch, or can be
somewhat deduced from there; the rest I guess I inferred from tests.
I never found any behaviour of Pd that does not match this model, except
the abovementioned fact that signal objects (which are supposed to
accept floats in their signal inlets), don't accept one-float lists
(which are supposed to be equivalent to floats according to this model),
and I am not the only one to think this is a bug (note they do accept
the one-element list in an inlet if the presence of a float argument
converts that inlet to a non-signal inlet)
This whole discussion totally ignores POINTERS (thery are yet another
type of atom, aren't they?) because I don't know anything about them. If
anybody can fill this gap that would be appreciated (by me at least lol).
Hope this message is of some use.
cheers
m.
--
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteosistisette.com
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
