[PD] definitions of data types

[Frank Barknecht]

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__