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.
Frank Barknecht _ ______footils.org_ __goto10.org__