[PD] non-leaky symbols
moocow at ling.uni-potsdam.de
Thu Nov 25 15:27:42 CET 2004
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
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.
> 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 ;-)
More information about the Pd-list