[PD-dev] First attempt at "list" object uploaded

[Hans-Christoph Steiner]

On Jul 28, 2005, at 5:54 AM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>> This investigation lead me to another odd behavior:  [route symbol]
>> outputs a symbol on its left outlet, while [route list] outputs a
>> non-list.  While it is definitely useful to have an object with can
>> strip off the "list" selector, I don't think it should be called 
>> [route
>> list].  [route list] should output a list for every list it receives 
>> on
>> its inlet.
>
> But
>
>  [something which is a kind of list(
>  |
>  [route something]
>
> will strip of the "something" part, so stripping off "list" with
> "route list" is consistent with that behaviour.
>
> Apart from that, using [route list] to trim lists of "list" is
> probably very common (Iohannes does it, I did it) so changing it would
> mean breaking patches.

These two points are definitely true, I am not saying that it would be 
an easy change. But I think [route list] would have to always output a 
list on its left outlet in order for Miller's suggestion to work, which 
was to try to treat everything as a list when doing message handling.  
I could be wrong, but I think we should try it.

Also, [route symbol] does not trim the selector "symbol", so there is a 
precedence here.  We can look at the reserved words in Pd: "bang", 
"float", "symbol", and "list".  [route bang], [route float], [route 
symbol] all output the same data type on their left inlet.  [route 
list] does not always output a list, even though it is interpreting 
incoming lists, not merely routing by keyword.  More example patches!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: routing_data_types.pd
Type: application/octet-stream
Size: 3486 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050728/a7426afb/attachment.obj>
-------------- next part --------------



In the process, I documented some more behaviors of Pd related to all 
this.  [trigger list] outputs a list for everything except sets 
starting with a symbol that is not "list".  It also interprets lists on 
input, like [route list] (i.e. [list 1 2 3( is [1 2 3( on the outlet).

According to [route bang float symbol list], [float( remains a float 
and is inited to 0.  [symbol( remains a blank symbol.  [list( is 
converted to a bang.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: empty_data_types.pd
Type: application/octet-stream
Size: 981 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050728/a7426afb/attachment-0001.obj>
-------------- next part --------------


And another: [float 1( remains a float; [float 1 2 3( remains a float, 
but is cut to one element; [list 1 2 3( remains a list; and [list 1( is 
converted to a float.  (It would be nice to have a warning when [float 
1 2 3( is chopped to one element, that could help with debugging 
perhaps).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: float_conversion.pd
Type: application/octet-stream
Size: 1142 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050728/a7426afb/attachment-0002.obj>
-------------- next part --------------


And lastly: [print] interprets all floats (i.e. [1( and [float 1( both 
output "1").  [print] does not interpret symbols (i.e. [symbol test( 
prints "symbol test", [symbol( prints "symbol") and only interprets 
lists whose first element is a float.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: print_oddities.pd
Type: application/octet-stream
Size: 1218 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050728/a7426afb/attachment-0003.obj>
-------------- next part --------------



I am not saying that all these things I am documenting must change, I  
am trying to demonstrate what makes handling data in Pd so confusing at  
times, especially when working with lists.  Things do not always behave  
consistently or intuitively.

In order for things to get better, there will have to be some changes  
that will break backwards compatibility.  But that's why Pd is version  
0, right?  Plus for old patches, you can always use old versions of Pd.  
  Many programs break backwards compatibility in the quest for 1.0, its  
too be expected.  Its the only way to make real progress.

.hc

________________________________________________________________________ 
____

                   ?El pueblo unido jam?s ser? vencido!