On Thu, 25 Nov 2004, Bryan Jurish wrote:
Johannes and Krzysztof have commented on the specifics of l2s, and I can only add a hearty "me too" regarding some kind of standardized list handling primitives, which might help in the individual cases you're talking about. Another option (attractive to me) might be some kind of "temporary symbol" convention -- i.e. a symbol whose s_name would be changeable, but whose actual t_symbol* component is permanent -- I suppose such symbols would have to be identified by a sort of "initial name" to ensure that they get hashed right, but would have to be set-able in some non-standard fashion (list of ASCII-valued floats?) in order for them to make any sense memory-allocation-wise...
In LISP, which was the first language to have a Symbol data type, they added a type roughly like what you say, for the same reasons. They called it STRING. I think they had to import that feature from FORTRAN or BASIC.
I don't know when exactly they did add it, but a not-so-wild guess would be back then when "tty" still meant tele-typewriter, which would be sometime before I was born, and prolly even before you were born. I guess Scheme got strings from the beginning, and that was designed in the seventies, no?
Meanwhile it is still said that Pd doesn't deserve to get any more than symbols because Pd is not a string processing language. Well I don't mean to turn Pd into SED or SNOBOL, sorry, I just want strings.
BTW, is Pd going to get a refcounted-pointer atom type as in Python? or even mark-sweep-pointer atom type as in Ruby/ST/LISP ?
I'm imagining that, with the help of smarter pointers, all basic data types of Ruby/Python/Scheme/etc could become available to Pd more directly, and without leaks.
(One problem I'd have is, it seems that, in Pd, I never know whether a certain structure is supposed to be implemented as an atom-type, an object-class, a selector/method of a given object-class, or whatever. I feel disoriented.)
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju