moin Mathieu,
On 25 November 2004 at 07:18:59, Mathieu Bouchard wrote:
On Thu, 25 Nov 2004, Bryan Jurish wrote:
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.
yup, LISP was pretty much my inspiration for the idea; but by now, most LISPs have "real" strings and vectors anyways... PROLOG at least makes it look as if its strings are nothing more than lists of ASCII values, but I certainly don't want to turn Pd into PROLOG.
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
... and when "car" really *did* mean "contents of the address register" ;-)
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.
Likewise.
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.
I'm not sure that "smarter pointers" would really be a good way to go for Pd. If I understand your use of the term correctly, they would necessarily involve a garbage collection routine which could potentially get in the way of other computation -- ok, maybe it could be parked in its own thread, but that seems to me to be introducing too much complexity for relatively little gain: I'd be happy with some explicit control of the relevant memory management routines (allocate|set|copy|free) at the patch level, but maybe that's taking things too close to C...
(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.)
As the Perl folks say, "TMTOWTDI". This is a Good Thing ;-)
marmosets, Bryan