On Tue, 6 Sep 2011, martin.peach@sympatico.ca wrote:
The disaster would be if Pd tried to guess what the user intends based on some general idea of what Pd is 'for'. For instance I've been working on an xbee external where I need to specify numbers like 0x0a060123 for the remote address. I do that by interpreting the symbol as a 64-bit integer internally but I would not expect any other external to do this unless it needs to.
The xbee external uses a function that shows that it expects to read a symbol where you gave it the 0x0a060123 symbol. Therefore Pd would not do any implicit conversion, because it's being requested to give a symbol atom as a symbol.
However, if ever 0x0a060123 is to be parsed as a float (that's a different issue, actually), then xbee would be getting 168165667 rounded to 168165664 and then it would be implicitly converted to gensym("168165664"). But that's a parser difference, and not a difference of implicit type conversions. The solution would be to backslash it or doublequote it.
Perhaps it is confusing because we are talking about several related propositions at once :
implicit conversion to replace type mismatch errors
getting atom_string to write backslashes to files and to messageboxes, to match what the parser can already do
modifying both the parser and atom_string, to change the meaning of doublequotes
and AFAIK, no-one talked about adding support for aztec numerals or parsing «half-dozen» as meaning {A_FLOAT,6}.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC