[PD] definitions of data types

[Martin Peach]

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