Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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.
To be pedantic: You cannot conclude this from the manual, because one could extend the quote as: "Anything that is not a valid number is considered a symbol ... and something that is a valid number can be (made into) a symbol as well in certain rare circumnstances. But then it's not a usual number ("float") anymore and you need to be careful."
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.
I somehow remember that numeric symbols have their use with the text-rendering objects of Gem (phone numbers that start with 0 come to mind). In day-to-day use purely numeric symbols aren't needed and normally they aren't generated as well. I'd consider generating numeric symbols "advanced Pd usage. ;) And *if* someone generates them, one should be aware of the consequences for example in [select] and [route].
Anyway what is needed in the long term is a proper string type.
Ciao