[PD] non-leaky symbols

[Bryan Jurish]

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