On Tue, 6 Sep 2011, [email protected] 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
