So there have been lots of emails over the years on what to call all
the various types of data that Pd works with. In order to support the
effort of getting to the bottom of this, I have started a wiki page to
document all of the relevant details.
http://puredata.org/dev/PdDefinitions
I've also started putting related patches in CVS ("messageoddness"
isn't the best name, but I haven't gotten around to changing it):
/doc/additional/messageoddness
The key thing to this discussion is to separate the implementation from
the language. Pd is a language in its own right, and therefore when
talking about definitions, we should not talk about how its
implemented, but rather how Pd interprets things.
For data types, I think its easiest to look to [route], [trigger], and
[select], three Pd objects whose core function is to interpret data
types. And this will give some perhaps surprising results. For
example:
[word( | [select symbol]
this tells us "error: select: no method for 'word'", therefore [word(
is not a symbol.
[word( | [route symbol]
This outputs on the right inlet, telling us [word( is not a symbol.
[word( | [trigger symbol]
This tells us "error: trigger: can only convert 's' to 'b' or 'a'".
This error message seems to tell us that [word( is not a symbol also.
So in Pd, [word( is not a bang, float, symbol, list, or pointer. So
its currently undefined, and its an "element". A list is made up of
"elements" also. There are "list" series and series which are
currently undefined, meaning series of 2 or more elements which starts
neither with an non-float element nor the selector "list". Which
brings me to something like this:
bang float (== numeric element) list (== list series) pointer symbol symbolic element selector series
Here are some attempts at definitions:
list: a series of 2 or more elements whose first element is either the
selector "list", or a float, which causes the "list" selector to be
implied. A 0-element list is a bang, a 1-element list is either a
float or a symbol, are there any exceptions where a 0- or 1-element
lists actually exists? I suppose only in a message box.
symbol: a symbol is a two element series where the first element is the
"symbol" selector and the second element is a symbolic element. But
any series with a selector of "symbol" with more than two elements is
automatically converted to a symbol by truncating all other symbolic
elements but the "symbol" selector and the second element.
selector series: a series of 2 or more elements whose first element is
neither the selector "list" nor a numeric element. But it needs a
better term.
numeric element: any element which is a functional representation of a
number. In Pd, a numeric element is the same as a float.
symbolic element: any element which is not a functional representation
of a number, usually in the form of words
.hc
"Computer science is no more related to the computer than astronomy is
related to the telescope."
-Edsger
Dykstra
Hans-Christoph Steiner wrote:
For data types, I think its easiest to look to [route], [trigger], and [select], three Pd objects whose core function is to interpret data types. And this will give some perhaps surprising results. For example:
[word( | [select symbol]
this tells us "error: select: no method for 'word'", therefore [word( is not a symbol.
very empiristic indeed.
btw, i don't know why you consider these results as "surprising". i think people with _no_ knowledge of pd will think it very surprising if [select symbol] would select anything _but_ "symbol" (like "word") people who are used to pd should be surprised about this any more (since they are used to it)
[...]
This error message seems to tell us that [word( is not a symbol also.
right. nobody said that "word" is a symbol.
but nevermind...
bang float (== numeric element) list (== list series) pointer symbol symbolic element selector series
Here are some attempts at definitions:
list: a series of 2 or more elements whose first element is either the selector "list", or a float, which causes the "list" selector to be
i think this is a bad start. implying "list" or "float" is an exception and should be handled as such: at the very end of the documentation! if people would use [float 1( instead of [1(, then i think that there would be less confusion. so we should get people to _think_ [float 1(, even though they _write_ [1(.
symbol: a symbol is a two element series where the first element is the "symbol" selector and the second element is a symbolic element. But any series with a selector of "symbol" with more than two elements is automatically converted to a symbol by truncating all other symbolic elements but the "symbol" selector and the second element.
isn't the 3rd argument of [list 1 two drei( a symbol too?
selector series: a series of 2 or more elements whose first element is neither the selector "list" nor a numeric element. But it needs a better term.
how about "anything" (just joking)
numeric element: any element which is a functional representation of a number. In Pd, a numeric element is the same as a float.
symbolic element: any element which is not a functional representation of a number, usually in the form of words
and don't forget "pointer element".
apropos, isn't "element" a synonym for "atom"?
mfg.asdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Here are some attempts at definitions:
list: a series of 2 or more elements whose first element is either the selector "list", or a float, which causes the "list" selector to be
i think this is a bad start. implying "list" or "float" is an exception and should be handled as such: at the very end of the documentation! if people would use [float 1( instead of [1(, then i think that there would be less confusion. so we should get people to _think_ [float 1(, even though they _write_ [1(.
I agree that a "bottom up" approach to get clear definitions would be better. That is, first start with the possible elements/atoms: floats/numbers, symbols, words (i.e. "symbols" without "symbol" selector), bang and pointer.
After these are defined, one could talk about how messages with more than one atom are handled: those with a proper "list" selector, those with an implied "list" selector and those with a different selector (out of band-/meta-messages).
Maybe this whole discussion should not so much focus on "data type" anyway, but instead on "messages", because all of these things in practice are only important when it comes to how Pd objects deal with messages while communicating with each other.
Here's my quick try at definitions using that approach.
============== Messages in Pd ==============
Objects in Pd send each other various data in the form of messages. Messages can transport various kinds of information: single numbers and words, groups of numbers and words etc. Understanding the various ways to built and work with messages is a key to understanding Pd.
Nomenclature (not scientific)
number: something you count and compute with like 1, 0.1, 1.21e+20
word: the thing you can look up in a dictionary and that is not a number as above. Normally must not contain whitespace (unless properly escaped).
Atomic messages
bang:
The most basic message is "bang". It consists of the single word "bang" for example written in a message box. There also is the object [bang] (short [b]) which transforms every incoming message to a "bang"-message.
Anatomy of a bang-message:
"bang"
float:
A message that starts with the word "float" followed by exactly one number. The first word "float" is also called the selector. Examples "float 1", "float -3.4", "float 1.21e+20". A message that only contains a number internally gets the word "float" prepended.
Anatomy of a float-message:
Selector: float (can be implied)
Data: one number
symbol:
A message that starts with the word "symbol" followed by (exactly) one word. The first word "symbol" is also called the selector. If there are more words or numbers following the data word, they get truncated to create a proper symbol-message.
Anatomy of a symbol-message:
Selector: symbol (can not be implied!)
Data: one word
pointer:
(Uhm, how to define a pointer?)
List-messages
The official text by Miller (list-help.pd):
Messages in Pd are somewhat artificially divided into two classes. First are data-holding messages (bang, float, symbol, list) which are the primary way of communicating between objects. Second is "everything else" (you could call them out-of-band messages or metamessages) that describe changes in configuration, read and write files, quit Pd, etc. These are provided so that complex objects don't need to have 100 separate inlets for every possible functionality. It's not clear whether this was a good design choice, but it's entrenched.
The distinction becomes visible, and ugly, when the leading item in a data-holding message is a symbol (i.e. word, fbar). In this case, to disambiguate it from the other sort, the printed form of the message has a selector, "list" or "symbol" prepended to it. Underneath, there is always a selector in fromt of data messages, but it is implied if the first data item is a number.
My take:
A list-message is a multi-atom message starting with the word "list" as selector. List-messages can be generated using the [list] object family, which all convert their input to a list-message and - except [list trim] - they all output proper list-messages. [list trim] splits off the "list"-selector and just passes the data part of a list-message.
List-messages with just one element are handled specially, see below.
Anatomy of a list-message:
Selector: list (can be implied, if data starts with a number)
Data: normally at least two atoms (words, numbers or
pointers). One-atom list-messages get converted to
atomic messages, see below.
One-element lists .................
If a list-message's data contains zero or one elements, the message gets converted to an atomic message according to the following rules:
No data: conversion to bang-message. One word: conversion to symbol-message One number: conversion to float message. One pointer: conversion to pointer
Implied list-selector .....................
A multi-atom message that starts with a number is a list-message, too. (Cf. implied selector in float-messages)
Meta-messages
Messages that are neither pointers, float-, symbol-, list- nor bang-messages.
Meta-messages can be generated out of atomic and list-messages using [list trim]. Many objects like [openpanel], [tabread] etc. accept and generate meta-message for administrative tasks.
Anatomy of a meta-message:
Selector: a word that is not "float", "symbol", "list" nor "bang"
Data: anything
Examples:
"reset"
"read -resize soundfile.wav"
"set pd-%s"
"/synth/param 0 127"
Hey, that was a short definition of meta-messages.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Feb 6, 2006, at 8:11 AM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Here are some attempts at definitions:
list: a series of 2 or more elements whose first element is either
the selector "list", or a float, which causes the "list" selector to bei think this is a bad start. implying "list" or "float" is an exception and should be handled as such: at the very end of the documentation! if people would use [float 1( instead of [1(, then i think that there would be less confusion. so we should get people to _think_ [float 1(, even though they
_write_ [1(.I agree that a "bottom up" approach to get clear definitions would be better. That is, first start with the possible elements/atoms: floats/numbers, symbols, words (i.e. "symbols" without "symbol" selector), bang and pointer.
I propose "element" and "series" as general words. "set" was a bad
word because is means something without order. A "series" has order,
so it makes more sense. We should not use the existing terms to define
things because we are trying to eliminate the current confusion of how
these terms are defined.
After these are defined, one could talk about how messages with more than one atom are handled: those with a proper "list" selector, those with an implied "list" selector and those with a different selector (out of band-/meta-messages).
Maybe this whole discussion should not so much focus on "data type" anyway, but instead on "messages", because all of these things in practice are only important when it comes to how Pd objects deal with messages while communicating with each other.
Here's my quick try at definitions using that approach.
============== Messages in Pd ==============
Objects in Pd send each other various data in the form of messages. Messages can transport various kinds of information: single numbers and words, groups of numbers and words etc. Understanding the various ways to built and work with messages is a key to understanding Pd.
Nomenclature (not scientific)
number: something you count and compute with like 1, 0.1, 1.21e+20
word: the thing you can look up in a dictionary and that is not a number as above. Normally must not contain whitespace (unless properly escaped).
"Word" has other meanings in computer land. Plus "1.1.1.1" is not a
number, nor is it a "thing you can look up in a dictionary". But
[list 1.1.1.1( is a symbol, not a float. So it is symbolic rather than
numeric, and it is a basic element, it is not divided within Pd (unless
you are using objects which are meant to chop up symbolic elements).
Atomic messages
bang:
The most basic message is "bang". It consists of the single word "bang" for example written in a message box. There also is the object [bang] (short [b]) which transforms every incoming message to a "bang"-message.
Anatomy of a bang-message:
"bang"
It just needs something like: bang means "do something".
float:
A message that starts with the word "float" followed by exactly one number. The first word "float" is also called the selector. Examples "float 1", "float -3.4", "float 1.21e+20". A message that only contains a number internally gets the word "float" prepended.
"float" doesn't get prepended, but rather implied. For example:
[5( | [+ 5]
The output is [10(, not [float 10(. The "float" is therefore implied
rather than prepended.
Anatomy of a float-message:
Selector: float (can be implied) Data: one numbersymbol:
A message that starts with the word "symbol" followed by (exactly) one word. The first word "symbol" is also called the selector. If there are more words or numbers following the data word, they get truncated to create a proper symbol-message.
Anatomy of a symbol-message:
Selector: symbol (can not be implied!) Data: one wordpointer:
(Uhm, how to define a pointer?)
Something like "a pointer to a position in a data structure", but I
think the existing definitions are clear. Or at least, I never had any
confusion over what it meant (using it was a different story ;)
List-messages
The official text by Miller (list-help.pd):
Messages in Pd are somewhat artificially divided into two classes. First are data-holding messages (bang, float, symbol, list) which are the primary way of communicating between objects. Second is "everything else" (you could call them out-of-band messages or metamessages) that describe changes in configuration, read and write files, quit Pd, etc. These are provided so that complex objects don't need to have 100 separate inlets for every possible functionality. It's not clear whether this was a good design choice, but it's entrenched.
The distinction becomes visible, and ugly, when the leading item in a data-holding message is a symbol (i.e. word, fbar). In this case, to disambiguate it from the other sort, the printed form of the message has a selector, "list" or "symbol" prepended to it. Underneath, there is always a selector in fromt of data messages, but it is implied if the first data item is a number.
My take:
A list-message is a multi-atom message starting with the word "list" as selector. List-messages can be generated using the [list] object family, which all convert their input to a list-message and - except [list trim] - they all output proper list-messages. [list trim] splits off the "list"-selector and just passes the data part of a list-message.
List-messages with just one element are handled specially, see below.
Anatomy of a list-message:
Selector: list (can be implied, if data starts with a number) Data: normally at least two atoms (words, numbers or pointers). One-atom list-messages get converted to atomic messages, see below.One-element lists .................
If a list-message's data contains zero or one elements, the message gets converted to an atomic message according to the following rules:
No data: conversion to bang-message. One word: conversion to symbol-message One number: conversion to float message. One pointer: conversion to pointer
Can you even have a list of pointers? I didn't think so. I know that
there is not [route pointer] unless that's changed with 0.39. (Or
rather [route pointer] routes "selector series" or "symbolic element"
messages with the selector "pointer", but not the data type "pointer").
Implied list-selector .....................
A multi-atom message that starts with a number is a list-message, too. (Cf. implied selector in float-messages)
"atom" is not clearly defined, so I think we should stick with
"element" in our definitions.
Meta-messages
Messages that are neither pointers, float-, symbol-, list- nor bang-messages.
Meta-messages can be generated out of atomic and list-messages using [list trim]. Many objects like [openpanel], [tabread] etc. accept and generate meta-message for administrative tasks.
Anatomy of a meta-message:
Selector: a word that is not "float", "symbol", "list" nor "bang" Data: anythingExamples:
"reset" "read -resize soundfile.wav" "set pd-%s" "/synth/param 0 127"Hey, that was a short definition of meta-messages.
This defines "selector series" in terms of messages though. When a
"selector series" is stored in an [any], it is not a message. Messages
and data types are distinct things in Pd, therefore should be defined
distinctly.
.hc
"The arc of history bends towards justice."
- Dr. Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Feb 6, 2006, at 8:11 AM, Frank Barknecht wrote:
I agree that a "bottom up" approach to get clear definitions would be better. That is, first start with the possible elements/atoms: floats/numbers, symbols, words (i.e. "symbols" without "symbol" selector), bang and pointer.
I propose "element" and "series" as general words. "set" was a bad
word because is means something without order. A "series" has order,
so it makes more sense. We should not use the existing terms to define
things because we are trying to eliminate the current confusion of how
these terms are defined.
Replacing occurences of "atom" with "element" is fine with me and might make stuff clearer. Using "series" generally also would be fine with me, too, however I do think, that using the term "message" actually would make things simpler. They also are dealt with in this way in the manual in " 2.3.1. anatomy of a message"
Messages come in various flavours which are differentiated by the selector (sometimes implied) and the data they carry. I really believe, that a new general term is not needed and in the end could just confuse things more than necessary. The only new term actually needed would be the meta-message, all other messages are covered by bang, float, symbol and list (and pointers).
Of course that is just my view.
Nomenclature (not scientific)
number: something you count and compute with like 1, 0.1, 1.21e+20
word: the thing you can look up in a dictionary and that is not a number as above. Normally must not contain whitespace (unless properly escaped).
"Word" has other meanings in computer land. Plus "1.1.1.1" is not a
number, nor is it a "thing you can look up in a dictionary". But
[list 1.1.1.1( is a symbol, not a float. So it is symbolic rather than
numeric, and it is a basic element, it is not divided within Pd (unless
you are using objects which are meant to chop up symbolic elements).
I just wanted to avoid calling it "symbol", which of course would be the proper term, but is very confusing when you want to differentiate it from the symbol-symbol (Hi, Alice!.) Using "word" is used as a casual term here, intended to be understood by artists, not computing scientists. ;) Probably "word" needs a better definition, though. How about:
"Any atomic element that is not a valid number is considered a word or symbol, though we avoid the term "symbol" in this context to not confuse it with Pd's "symbol-messages". This includes, but is not limited to the things you can look up in a dictionary. More specifically a word is a string sequence that does not contain whitespace (unless properly escaped) and is not a functional representation of a number."
bang:
The most basic message is "bang". It consists of the single word "bang" for example written in a message box. There also is the object [bang] (short [b]) which transforms every incoming message to a "bang"-message.
Anatomy of a bang-message:
"bang"
It just needs something like: bang means "do something".
Maybe, maybe not. In practice "bang" means "do something", but from a pure syntactic view it's just a special message.
float:
A message that starts with the word "float" followed by exactly one number. The first word "float" is also called the selector. Examples "float 1", "float -3.4", "float 1.21e+20". A message that only contains a number internally gets the word "float" prepended.
"float" doesn't get prepended, but rather implied. For example:
[5( | [+ 5]
The output is [10(, not [float 10(. The "float" is therefore implied
rather than prepended.
Okay, I could change that.
One-element lists .................
If a list-message's data contains zero or one elements, the message gets converted to an atomic message according to the following rules:
No data: conversion to bang-message. One word: conversion to symbol-message One number: conversion to float message. One pointer: conversion to pointer
Can you even have a list of pointers? I didn't think so.
Yes, you can [pack] pointers just fine. Btw: "Pack" could be an alternative name for a list-message. Sending a single [pointer] through [list] converts it to a list and then it gets converted back again. Sending a pointer to [list prepend x] will give a list message: "list x (gpointer)"
I know that there is not [route pointer] unless that's changed with 0.39. (Or rather [route pointer] routes "selector series" or "symbolic element" messages with the selector "pointer", but not the data type "pointer").
[route] and [select] only deal with the other types of messages, however there is a [trigger pointer] and [t a] also passes along a pointer.
Meta-messages
Messages that are neither pointers, float-, symbol-, list- nor bang-messages.
Meta-messages can be generated out of atomic and list-messages using [list trim]. Many objects like [openpanel], [tabread] etc. accept and generate meta-message for administrative tasks.
Anatomy of a meta-message:
Selector: a word that is not "float", "symbol", "list" nor "bang"
Data: anything
Examples:
"reset" "read -resize soundfile.wav" "set pd-%s" "/synth/param 0 127"
Hey, that was a short definition of meta-messages.
This defines "selector series" in terms of messages though. When a
"selector series" is stored in an [any], it is not a message. Messages
and data types are distinct things in Pd, therefore should be defined
distinctly.
Well, I deliberately only talked about messages here, because the definitions in PdDefinitions in fact also only are concerned with the message aspect of data types. If you want to explain data types by how objects like route or select deal with them, you are in fact explaining messages.
I see data types in Pd slightly different. Defining data types would also need to take GemLists or PDP-packets into account. (Maybe at least the GemList should be added anyway, as it is in many aspects similar to a Pointer in that [t a] can deal with it. [list] stores GemLists as well, but outputs list-messages and [any] properly stores GemLists because it doesn't do any such conversions as [list].
Finally I think, that data types in Pd are not hard to understand, it is the message representation that can be confusing or ugly.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 6 Feb 2006, Frank Barknecht wrote:
I just wanted to avoid calling it "symbol", which of course would be the proper term, but is very confusing when you want to differentiate it from the symbol-symbol (Hi, Alice!.) Using "word" is used as a casual term here, intended to be understood by artists, not computing scientists. ;)
Even among comp.sci. and programmers, "word" doesn't have a consistent
definition. Some define it as a 16-bit integer, some define it as an
integer the same size as the main registers of a computer, and then which
ones are the "main" ones is debatable. That's just one usage of the "word"
word! Then there is Forth, in which "word" means like "atom" in Pd. In
parser theory it may mean "single letter" (i'm not joking!).
Yes, you can [pack] pointers just fine. Btw: "Pack" could be an alternative name for a list-message.
That sounds like a good idea worthy of investigation.
[route] and [select] only deal with the other types of messages, however there is a [trigger pointer] and [t a] also passes along a pointer.
Yes. For all practical purposes, there are three stable atom types, and then a bunch of extras. In the not-too-periodic table of the atom types,
stable: A_FLOAT A_SYMBOL A_POINTER | virtual: A_DEFFLOAT A_DEFSYMBOL | radioactive: A_DOLLAR A_DOLLSYM | A_COMMA A_SEMI ----------------------------------------------+--------------- bogons: A_NULL A_CANT A_GIMME
In which "stable" and "radioactive" are the only ones actually existing, and the others are cases of trying to shove too many features in t_atomtype.
I see data types in Pd slightly different. Defining data types would also need to take GemLists or PDP-packets into account.
Those are message-types, and GF's "grid" is also a message-type, but it's partially because pd doesn't support user-defined atom-types, so defining those things as message-types is a way around the problem.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 10, 2006, at 5:09 PM, Mathieu Bouchard wrote:
On Mon, 6 Feb 2006, Frank Barknecht wrote:
I just wanted to avoid calling it "symbol", which of course would be
the proper term, but is very confusing when you want to differentiate it from the symbol-symbol (Hi, Alice!.) Using "word" is used as a casual term here, intended to be understood by artists, not computing scientists. ;)Even among comp.sci. and programmers, "word" doesn't have a consistent definition. Some define it as a 16-bit integer, some define it as an integer the same size as the main registers of a computer, and then
which ones are the "main" ones is debatable. That's just one usage of the
"word" word! Then there is Forth, in which "word" means like "atom" in Pd. In parser theory it may mean "single letter" (i'm not joking!).Yes, you can [pack] pointers just fine. Btw: "Pack" could be an alternative name for a list-message.
That sounds like a good idea worthy of investigation.
[route] and [select] only deal with the other types of messages, however there is a [trigger pointer] and [t a] also passes along a pointer.
Yes. For all practical purposes, there are three stable atom types, and then a bunch of extras. In the not-too-periodic table of the atom
types,stable: A_FLOAT A_SYMBOL A_POINTER | virtual: A_DEFFLOAT A_DEFSYMBOL | radioactive: A_DOLLAR A_DOLLSYM | A_COMMA A_SEMI ----------------------------------------------+--------------- bogons: A_NULL A_CANT A_GIMME
In which "stable" and "radioactive" are the only ones actually
existing, and the others are cases of trying to shove too many features in t_atomtype.I see data types in Pd slightly different. Defining data types would also need to take GemLists or PDP-packets into account.
Those are message-types, and GF's "grid" is also a message-type, but it's partially because pd doesn't support user-defined atom-types, so defining those things as message-types is a way around the problem.
data types and messages are separate. So what's the data type for
gridflow? Well, in terms of Pd, grids are not made up of numeric
atoms, symbolic atoms, or pointer atoms, so...
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously.
- Benjamin Franklin
On Feb 6, 2006, at 4:27 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
For data types, I think its easiest to look to [route], [trigger], and [select], three Pd objects whose core function is to interpret data types. And this will give some perhaps surprising results. For
example:[word( | [select symbol]
this tells us "error: select: no method for 'word'", therefore [word( is not a symbol.
very empiristic indeed.
btw, i don't know why you consider these results as "surprising". i think people with _no_ knowledge of pd will think it very surprising if [select symbol] would select anything _but_ "symbol" (like "word") people who are used to pd should be surprised about this any more
(since they are used to it)[...]
Sorry, it wasn't the most clear example. This may be clearer:
[word( | [select word]
which gives the same error: "error: select: no method for 'word'"
This error message seems to tell us that [word( is not a symbol also.
right. nobody said that "word" is a symbol.
but nevermind...
Actually, you are wrong, and that is one of the key problems I am
trying to clear up. From 2.3.1 in the Pd manual:
http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s3.1
"Messages contain a selector followed by any number of arguments. The
selector is a symbol, which appears in the patch as a non-numeric
string with no white space, semicolons, or commas. The arguments may be
symbols or numbers."
So, by that definition [word( is a message with a selector and no
arguments. It quite clearly says "The selector is a symbol", but these
quite clearly disagree:
[word( [word( [word( | | | [select word] [route symbol] [trigger symbol]
This gives no output on either outlet. Instead [select word] says
"error: select: no method for word", [route] outputs on the right
outlet, and [trigger symbol] says "error: trigger: can only convert 's'
to 'b' or 'a'".
bang float (== numeric element) list (== list series) pointer symbol symbolic element selector series
Here are some attempts at definitions:
list: a series of 2 or more elements whose first element is either
the selector "list", or a float, which causes the "list" selector to bei think this is a bad start. implying "list" or "float" is an exception and should be handled as such: at the very end of the documentation! if people would use [float 1( instead of [1(, then i think that there would be less confusion. so we should get people to _think_ [float 1(, even though they _write_
[1(.
First, the PdDefinitions page isn't meant to learn from, but instead
for us to work out the details of this issue. Second, I agree, things
are much clearer if people use the "float" selector, and mentally think
it too. But that is only part of the problem.
symbol: a symbol is a two element series where the first element is
the "symbol" selector and the second element is a symbolic element. But any series with a selector of "symbol" with more than two elements is automatically converted to a symbol by truncating all other symbolic elements but the "symbol" selector and the second element.isn't the 3rd argument of [list 1 two drei( a symbol too?
That's what the docs say, but that is not what [select], [route], and
[trigger] say. We need to document what is actually happening, not
follow the docs and ignore what is actually happening.
The 3rd argument of that list is only a symbol if it has a "list" or
"symbol" selector. Consider this patch:
[list 1 two drei( | [list split 2] | [list trim]
The output of [list trim] is not a symbol. [symbol drei( is a symbol,
[list drei( is a symbol. [drei( is not a symbol.
selector series: a series of 2 or more elements whose first element is neither the selector "list" nor a numeric element. But it needs a better term.
how about "anything" (just joking)
numeric element: any element which is a functional representation of a number. In Pd, a numeric element is the same as a float.
symbolic element: any element which is not a functional representation of a number, usually in the form of words
and don't forget "pointer element".
I think that bangs and pointers are clearly defined, I feel no need to
try to redefine them.
apropos, isn't "element" a synonym for "atom"?
An atom is a float or a symbol, right?. [word( is not float or a
symbol, so it is therefore not an atom. But it is an element in a
message, in this case, its used as a selector. And from what I see,
"atom" is not a useful distinction when you view things from Pd.
Instead, it is part of the implementation.
We could use the word "atom" instead of "element", but it is currently
not clearly defined. From 2.1.2 of the manual:
http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s1.2
"The text is divided into atoms separated by white space." "Atoms are either numbers or symbols..."
By the first definition, atoms and elements are the same thing. But
not according to the second.
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes.
Now that he can realize them, he must either change them, or perish.
-William Carlos
Williams
Hans-Christoph Steiner wrote:
right. nobody said that "word" is a symbol.
but nevermind...
Actually, you are wrong, and that is one of the key problems I am
arguments. It quite clearly says "The selector is a symbol", but these
[...]
First, the PdDefinitions page isn't meant to learn from, but instead for us to work out the details of this issue. Second, I agree, things
yes, but if we can make it clear for us (so we can talk about it) then chances are high that things are so clear that others can learn from it.
That's what the docs say, but that is not what [select], [route], and [trigger] say. We need to document what is actually happening, not follow the docs and ignore what is actually happening.
The 3rd argument of that list is only a symbol if it has a "list" or "symbol" selector. Consider this patch:
[list 1 two drei( | [list split 2] | [list trim]
The output of [list trim] is not a symbol. [symbol drei( is a symbol, [list drei( is a symbol. [drei( is not a symbol.
so the basic confusion comes from the fact that there are 2 different kinds of symbol: a) the atom-type symbol b) the message-type symbol
ad a: "drei" is always symbol, even if it is a selector; "symbol drei" consists of 2 symbols, one is "symbol", the other one "drei". symbols of that kind are always stored within a hash-table and are produced with gensym() (on the C side of things) the message-selector is _always_ of atom-type symbol.
ad b: a symbol-message is a message with a selector "symbol" and exactly one argument of type symbol.
and don't forget "pointer element".
I think that bangs and pointers are clearly defined, I feel no need to try to redefine them.
i thought "definitions of data types" would define everything.
apropos, isn't "element" a synonym for "atom"?
An atom is a float or a symbol, right?. [word( is not float or a
wrong (as i read it): an atom is a float or a symbol or a pointer.
symbol, so it is therefore not an atom. But it is an element in a message, in this case, its used as a selector. And from what I see, "atom" is not a useful distinction when you view things from Pd.
Instead, it is part of the implementation.
i think the implementation tries to reflect the design. however, i am very used to reading pd in C, so my view might be narrow.
http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s1.2
"The text is divided into atoms separated by white space." "Atoms are either numbers or symbols..."
By the first definition, atoms and elements are the same thing. But not according to the second.
this quote refers to "text". a message need not necessarily be writeable as text. (of course it makes everything (esp. documentation) much easier, if you can write down the message).
mfg.a.dr IOhannes
On Feb 6, 2006, at 3:06 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
right. nobody said that "word" is a symbol.
but nevermind...
Actually, you are wrong, and that is one of the key problems I am
arguments. It quite clearly says "The selector is a symbol", but
these[...]
First, the PdDefinitions page isn't meant to learn from, but instead for us to work out the details of this issue. Second, I agree, things
yes, but if we can make it clear for us (so we can talk about it) then chances are high that things are so clear that others can learn from
it.
Absolutely. But first let's figure out all the details, then come up
with clear definitions, then teach people them.
That's what the docs say, but that is not what [select], [route], and [trigger] say. We need to document what is actually happening, not follow the docs and ignore what is actually happening.
The 3rd argument of that list is only a symbol if it has a "list" or "symbol" selector. Consider this patch:
[list 1 two drei( | [list split 2] | [list trim]
The output of [list trim] is not a symbol. [symbol drei( is a symbol, [list drei( is a symbol. [drei( is not a symbol.
so the basic confusion comes from the fact that there are 2 different kinds of symbol: a) the atom-type symbol b) the message-type symbol
ad a: "drei" is always symbol, even if it is a selector; "symbol drei" consists of 2 symbols, one is "symbol", the other one "drei". symbols of that kind are always stored within a hash-table and are produced with gensym() (on the C side of things) the message-selector is _always_ of atom-type symbol.
ad b: a symbol-message is a message with a selector "symbol" and
exactly one argument of type symbol.
One of the big problems is that symbol messages and symbolic atoms are
both called "symbols", yet then behave very differently. So it would
be very helpful to use different words here, like "symbolic atom",
"numeric atom", "pointer atom". Then a "symbol" and "float" are purely
message types. So then you can rephrase the above:
"drei" is always a symbolic atom, even if it is a selector. "symbol
drei" consists of two symbolic atoms, "symbol" and "drei". symbolic
atoms of that kind are always stored within a hash-table and are
produced with gensym(). The message selector is always a symbolic
atom.
And that would be clearer... its a start...
I have switched up the PdDefinitions wiki. On the main page, its just
documentation of all of the various categories (data types is not the
right word, so I changed to categories). Plus there is documentation
of the of a number of specific details. Please add anything that you
find. Plus, at the bottom are separate pages for Frank's and my
attempts at definitions. Feel free to add your own.
.hc
and don't forget "pointer element".
I think that bangs and pointers are clearly defined, I feel no need to try to redefine them.
i thought "definitions of data types" would define everything.
apropos, isn't "element" a synonym for "atom"?
An atom is a float or a symbol, right?. [word( is not float or a
wrong (as i read it): an atom is a float or a symbol or a pointer.
symbol, so it is therefore not an atom. But it is an element in a message, in this case, its used as a selector. And from what I see, "atom" is not a useful distinction when you view things from Pd. Instead, it is part of the implementation.
i think the implementation tries to reflect the design. however, i am very used to reading pd in C, so my view might be narrow.
http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s1.2
"The text is divided into atoms separated by white space." "Atoms are either numbers or symbols..."
By the first definition, atoms and elements are the same thing. But not according to the second.
this quote refers to "text". a message need not necessarily be writeable as text. (of course it makes everything (esp. documentation) much easier, if you can write down the message).
mfg.a.dr IOhannes
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity."
-John Gilmore
Hans-Christoph Steiner wrote:
Here are some attempts at definitions:
list: a series of 2 or more elements whose first element is either the selector "list", or a float, which causes the "list" selector to be implied. A 0-element list is a bang, a 1-element list is either a float or a symbol, are there any exceptions where a 0- or 1-element lists actually exists? I suppose only in a message box.
...
selector series: a series of 2 or more elements whose first element is neither the selector "list" nor a numeric element. But it needs a better term.
I would call that an implicit list, and to be consistent with the way float works, it should have list prepended to it by pd and otherwise become indistinguishable from list.
Martin
On Feb 6, 2006, at 2:05 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
Here are some attempts at definitions:
list: a series of 2 or more elements whose first element is either
the selector "list", or a float, which causes the "list" selector to
be implied. A 0-element list is a bang, a 1-element list is either
a float or a symbol, are there any exceptions where a 0- or
1-element lists actually exists? I suppose only in a message box....
selector series: a series of 2 or more elements whose first element
is neither the selector "list" nor a numeric element. But it needs
a better term.I would call that an implicit list, and to be consistent with the way
float works, it should have list prepended to it by pd and otherwise
become indistinguishable from list.
But its not a list because objects that deal with lists say so. "list"
is a keyword in Pd, so we need to define these things using other
words. Try this to see what I mean:
[one 2 three four( | [route list]
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously.
- Benjamin Franklin
Hans-Christoph Steiner wrote:
On Feb 6, 2006, at 2:05 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
Here are some attempts at definitions:
list: a series of 2 or more elements whose first element is either
the selector "list", or a float, which causes the "list" selector to be implied. A 0-element list is a bang, a 1-element list is either a float or a symbol, are there any exceptions where a 0- or 1-element lists actually exists? I suppose only in a message box....
selector series: a series of 2 or more elements whose first element
is neither the selector "list" nor a numeric element. But it needs a better term.I would call that an implicit list, and to be consistent with the way float works, it should have list prepended to it by pd and otherwise become indistinguishable from list.
But its not a list because objects that deal with lists say so.
"list" is a keyword in Pd, so we need to define these things using other words. Try this to see what I mean:[one 2 three four( | [route list]
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.
From m_pd.h these are all the atom types:
typedef enum { A_NULL, A_FLOAT, A_SYMBOL, A_POINTER, A_SEMI, A_COMMA, A_DEFFLOAT, A_DEFSYM, A_DOLLAR, A_DOLLSYM, A_GIMME, A_CANT } t_atomtype;
There is no list atom-type. A list is just a list of atoms. The existence of more than one atom in a message implies that it is a list.
Martin
On Feb 6, 2006, at 3:25 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On Feb 6, 2006, at 2:05 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
Here are some attempts at definitions:
list: a series of 2 or more elements whose first element is either
the selector "list", or a float, which causes the "list" selector
to be implied. A 0-element list is a bang, a 1-element list is
either a float or a symbol, are there any exceptions where a 0-
or 1-element lists actually exists? I suppose only in a message
box....
selector series: a series of 2 or more elements whose first element
is neither the selector "list" nor a numeric element. But it
needs a better term.I would call that an implicit list, and to be consistent with the
way float works, it should have list prepended to it by pd and
otherwise become indistinguishable from list.But its not a list because objects that deal with lists say so.
"list" is a keyword in Pd, so we need to define these things using
other words. Try this to see what I mean:[one 2 three four( | [route list]
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.
This is one of the sources of confusion, but its a difficult question
of how _should_ Pd do it. So for now, I am trying to document all the
details of Pd actually does it from within Pd.
From m_pd.h these are all the atom types:
typedef enum { A_NULL, A_FLOAT, A_SYMBOL, A_POINTER, A_SEMI, A_COMMA, A_DEFFLOAT, A_DEFSYM, A_DOLLAR, A_DOLLSYM, A_GIMME, A_CANT } t_atomtype;
There is no list atom-type. A list is just a list of atoms. The
existence of more than one atom in a message implies that it is a
list.Martin
I put the atom types any other things into this wiki page. Please add
anything that's missing, especially documentation of odd cases of
message/data handling. At the bottom are links to Frank's and my stabs
at definitions.
http://puredata.org/dev/PdDefinitions
.hc
"Information wants to be free." -Stewart Brand
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?
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".
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.
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.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
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
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Frank Barknecht wrote:
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.
The problem is: there is a virtually unlimited amount of words that can behave like "set" and thus couldn't be used as first elements. Some examples:
the [fluid~] external has these: load, help, init, n, note, cc, control, bend, p, prog, gen. And it also accepts list-messages starting with "list ..."
[OSCroute] accepts user-defined symbol selectors specified by arguments.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Frank Barknecht wrote:
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.
The problem is: there is a virtually unlimited amount of words that can behave like "set" and thus couldn't be used as first elements. Some examples:
the [fluid~] external has these: load, help, init, n, note, cc, control, bend, p, prog, gen. And it also accepts list-messages starting with "list ..."
[OSCroute] accepts user-defined symbol selectors specified by arguments.
OK I see, so then wouldn't it be a good idea to merge those two types of list into one? Just treat all messages as lists. Then there is no restriction on the first element. Then an external could have a single list method which would be called for any possible input, instead of the plethora of methods for each possible input symbol and type the way it is now; the external would parse its input and call all those functions itself instead of registering them all with pd and having pd call them. Probably the time taken would be no different and the symbol table would be much smaller.
Martin
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
OK I see, so then wouldn't it be a good idea to merge those two types of list into one? Just treat all messages as lists. Then there is no restriction on the first element. Then an external could have a single list method which would be called for any possible input, instead of the plethora of methods for each possible input symbol and type the way it is now; the external would parse its input and call all those functions itself instead of registering them all with pd and having pd call them. Probably the time taken would be no different and the symbol table would be much smaller.
Let me quote Matju on this (from a post he did on pd-dev replying to Hans, when the term "undefined set" was still debated and finally abandoned and which I called "meta-messages".)
Messages have selectors. Selectors are used to select methods.
Suppose that the Pd of your dreams comes to existence, and that may mean without any so-called "undefined sets". Every message would be a "list". Then how would you send a message like "set $1" or "color $1 $2" to an object? somehow the list method (which is then the only method in each class) would have to deal with all messages. Then a neat idea to break down the code in more manageable bits would be to select one of several C functions depending on the first element of the received list. This first argument could be called a "selector". But now, what about a list-processing object that really needs to be able to receive a list in the same inlet as you would use to do "set" and "color" and such? To disambiguate this, let's prefix the lists intended for list-processing with a special selector that we might call "list".
Thus messages would be called lists and former lists would be called something else like "really lists" but there might be better names. And then again there would be things that are lists but not "really lists" and there appear again the "undefined sets" that aren't undefined nor sets.
Or in the words of Miller:
It's not clear whether this was a good design choice, but it's entrenched.
I learned the word "entrenched" from that.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Feb 7, 2006, at 7:32 PM, Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
OK I see, so then wouldn't it be a good idea to merge those two types
of list into one? Just treat all messages as lists. Then there is no restriction on the first element. Then an external could have a single list method which would be called for any possible input, instead of the plethora of methods for each possible input symbol and type the way it is now; the external would parse its input and call all those functions itself instead of registering them all with pd and having pd call them. Probably the
time taken would be no different and the symbol table would be much
smaller.Let me quote Matju on this (from a post he did on pd-dev replying to
Hans, when the term "undefined set" was still debated and finally abandoned
and which I called "meta-messages".)Messages have selectors. Selectors are used to select methods.
Suppose that the Pd of your dreams comes to existence, and that may
mean without any so-called "undefined sets". Every message would be a
"list". Then how would you send a message like "set $1" or "color $1 $2" to
an object? somehow the list method (which is then the only method in
each class) would have to deal with all messages. Then a neat idea to
break down the code in more manageable bits would be to select one of
several C functions depending on the first element of the received list. This
first argument could be called a "selector". But now, what about a list-processing object that really needs to be able to receive a
list in the same inlet as you would use to do "set" and "color" and such? To disambiguate this, let's prefix the lists intended for
list-processing with a special selector that we might call "list".Thus messages would be called lists and former lists would be called something else like "really lists" but there might be better names.
And then again there would be things that are lists but not "really
lists" and there appear again the "undefined sets" that aren't undefined nor sets.Or in the words of Miller:
It's not clear whether this was a good design choice, but it's entrenched.
I learned the word "entrenched" from that.
It is entrenched so it probably won't change anytime soon. But I do
think that Pd could work without "list" and "symbol" selectors. Then
symbolic atoms would automatically be symbols and any series with more
than one atom would automatically be a list. You can then have
separate inlets to handle different situations, like the first inlet
handling config messages like [set 1 3( and the second inlet handling
lists that are meant as only data.
Right now its somewhere in the middle, floats don't need selectors, but
other things do. That makes things whacky... it might even better to
go the opposite route and eliminate implied float and lists...
.hc
If you are not part of the solution, you are part of the problem.
-
Eldridge Cleaver
Hans-Christoph Steiner wrote:
On Feb 7, 2006, at 7:32 PM, Frank Barknecht wrote:
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
OK I see, so then wouldn't it be a good idea to merge those two types of list into one? Just treat all messages as lists. Then there is no restriction on the first element. Then an external could have a single list method which would be called for any possible input, instead of the plethora of methods for each possible input symbol and type the way it is now; the external would parse its input and call all those functions itself instead of registering them all with pd and having pd call them. Probably the
time taken would be no different and the symbol table would be much
smaller.Let me quote Matju on this (from a post he did on pd-dev replying to
Hans, when the term "undefined set" was still debated and finally abandoned and which I called "meta-messages".)Messages have selectors. Selectors are used to select methods.
Suppose that the Pd of your dreams comes to existence, and that may mean without any so-called "undefined sets". Every message would be a
"list". Then how would you send a message like "set $1" or "color $1 $2" to an object? somehow the list method (which is then the only method in
each class) would have to deal with all messages. Then a neat idea to
break down the code in more manageable bits would be to select one of
several C functions depending on the first element of the received list. This first argument could be called a "selector". But now, what about a list-processing object that really needs to be able to receive a
list in the same inlet as you would use to do "set" and "color" and such? To disambiguate this, let's prefix the lists intended for
list-processing with a special selector that we might call "list".Thus messages would be called lists and former lists would be called something else like "really lists" but there might be better names. And then again there would be things that are lists but not "really
lists" and there appear again the "undefined sets" that aren't undefined nor sets.Or in the words of Miller:
It's not clear whether this was a good design choice, but it's entrenched.
I learned the word "entrenched" from that.
It is entrenched so it probably won't change anytime soon. But I do
think that Pd could work without "list" and "symbol" selectors. Then
symbolic atoms would automatically be symbols and any series with more than one atom would automatically be a list. You can then have
separate inlets to handle different situations, like the first inlet
handling config messages like [set 1 3( and the second inlet handling
lists that are meant as only data.
I guess separate having data and program buses like that would mean that pd had a 'leaky' Harvard architecture because there would be no way to ensure the connections were made to the correct inlet. Another approach would be to have another kind of patch cord for control messages, like the signal cords on the dsp objects.
Martin
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Hans-Christoph Steiner wrote:
It is entrenched so it probably won't change anytime soon. But I do
think that Pd could work without "list" and "symbol" selectors. Then
symbolic atoms would automatically be symbols and any series with more than one atom would automatically be a list. You can then have
separate inlets to handle different situations, like the first inlet
handling config messages like [set 1 3( and the second inlet handling
lists that are meant as only data.I guess separate having data and program buses like that would mean that pd had a 'leaky' Harvard architecture because there would be no way to ensure the connections were made to the correct inlet. Another approach would be to have another kind of patch cord for control messages, like the signal cords on the dsp objects.
Actually I think, that all this would just complicate issues much more than necessary. Apart from a slight linguistic confusion regarding the term list (and somehow symbol) I really don't see any grave practical problems with the way things currently are. (Except the symbol-table, but that might be an implementation issue?) The linguistic problems only are a problem when talking about the symbol or lists in a casual way. However once the rules are understood (Hans and I both tried to explain them in a concise way) they are easy to *work* with. C++ is much harder.
And personally I wouldn't want to always have to write "float 1" instead of "1" in messages as I wouldn't want to have to type "list 1 1 0" just to describe a Gem-color so I'm really glad that both selectors can be implied when numbers are involved - as numbers are the bread and butter in Pd. Just enforcing a float-selector for the sake of consistency is wrong, IMO. There must be much better reasons, before such a step should be made.
As I wrote in PdMessages, I would propose to talk about float-, symbol- and list-MESSAGES when it is important to describe them in detail. I also like the term meta-messages for "other" messages, which don't have to be a multi-element series, they can also be a single element item as "reset" (without "symbol"!).
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
Mathieu Bouchard