On Tue, 23 Oct 2007, Hans-Christoph Steiner wrote:
- About the symbol/float stuff, I think Pd is intended to always reduce
atoms to their elemental type based on their content. Therefore, {symbol 123} shouldn't really exist.
If I make symbol 123456789 it's because it's intended to stay 123456789. I don't want tclpd to bastardise it by assuming that i'm ok with an approximation of the number that it could be representing if my intent was really to represent a quantity instead of just having a string of characters.
Federico and I came to the conclusion that we came to because pretty much anything else sucked in some way. We don't care that Pd seems perfectly ok with blowing up the saving of symbols that look like numbers, and we don't care that you don't want support for pointers.
I don't think that you and I and all of us have to stick with mere original intents.
The main alternative I would have had to that, is to represent Pd symbols in Tcl as the Pd parser would accept them. This means that a float would be backslashed. But I had ruled that out because then there would be no way to represent a pointer, unless some extra syntax is designed, plus other reasons.
Therefore, I think it would be better to just use normal Tcl lists, at least for now.
If you do it "at least for now", you're stuck with it forever or so.
Plus, I think Pd's type handling is partially modeled after Tcl's.
I don't know how you can argue that, but there's a large enough chunk of difference, that you could ignore the similarities. If Pd's type system was roughly like Tcl's, then users would never have to think about types in [pack], [unpack], [t], and such, for example.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada