[PD-dev] mystery type generated by [list trim]

Hans-Christoph Steiner hans at eds.org
Sun Oct 29 21:59:27 CET 2006

On Oct 29, 2006, at 7:38 AM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>> That might be one solution when using [list trim], but this example
>> actually shows a problem with the type system.  Things are supposed
>> to be strictly typed, atoms are either floats, symbols, or pointers.
>> This is an example of an atom that is none of the above.  That should
>> not happen, its a bug somewhere.
>> I updated the example patch with a couple of more relevant examples:
> The mystery type "symbol atom with numeric content" cannot be dealt
> with in Pd like this yet, because you cannot really input this mystery
> type in Pd: Every numeric value in an object box will be converted to
> a float atom, you have to generate a symbol-atom with numeric content
> through other means like makefilename.
> That's why [select 1234] fails to detect a "1234"-symbol without
> selector. [select 1234] will generate a [select] object in "float
> mode". [select something] will generate a [select] in "symbol mode".
> The float-[select] only has methods for float- and symbol-messages,
> but no methods for meta-messages like "set a b c", "set" or the
> "1234"-mystery-symbol.  (It also has no methods for bang-message and
> "list a b c"-messages will generate an error message, but at least
> works.)
> Similar things happen with [route 1234]: This route waits for a "float
> 1234" but in your example it gets a symbol-atom "1234" and correctly
> passes it along to the miss-outlet.
> See attached example for this illustrated.

That outlines the situation well.  So my point is now that this needs  
to be fixed either way. The definition of atoms should be  
consistent.  I think its good the way its defined in the manual:

"Atoms are either numbers or symbols like "+". Anything that is not a  
valid number is considered a symbol."

Therefore "1234" should always be a numeric atom.  I think that the  
type system should prevent this from happening, but maybe its also  
possible to fix the objects that are creating this mystery type.  So  
far its [makefilename] and [dumpOSC].

But perhaps it would me nice to be able to use a numeric atom in a  
symbol message, I seem to recall that being useful sometimes.  But  
that should probably be tested out in examples.



Looking at things from a more basic level, you can come up with a  
more direct solution... It may sound small in theory, but it in  
practice, it can change entire economies.     - Amy Smith

More information about the Pd-dev mailing list