[PD] non-leaky symbols

[Mathieu Bouchard]

On Thu, 25 Nov 2004, Bryan Jurish wrote:
> On 25 November 2004 at 07:18:59, Mathieu Bouchard wrote:
>  > 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...

Which is exactly what I am saying. Lisp's (format ...) function does the
job of printf(), only it has several times more options. I'm saying that
because LISP added Strings just after starting with Symbols, Pd should be
the same; and then it would become in line not only with
Lisp/Scheme/Dylan, but also with Smalltalk/Self/Ruby, and possibly a few
more.

> 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.

Ok, so you suppose that strings are theoretically better served by the
existing abstractions of list and integer? (i mean the "at least" part).

IMHO, I'd go more the Lisp way (if I'm not mistaken as to how it is
solved.) There is a thing called a Sequence, which is not a class of data
in particular, but is any class of data that can be trivially iterated:
you can go through the elements in sequence. In other words, it's a
"Virtual List" type. Vectors (the Lisp Arrays that have exactly 1
dimension of indices), the (linked) Lists, and Strings, are 3 examples of
Sequences, and because of that they have a lot of operations in common.

If I misread that about Lisp, then there is the same in Smalltalk and Ruby
anyway. In the latter it's a pseudo-class called Enumerable and contains
methods for making various kinds of for-loops on the elements.

> ... and when "car" really *did* mean "contents of the address register" ;-)

Sigh yes. Nowadays it sounds so silly that it gets deserved puns such as
"My other car is a cdr".

> 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 --

With reference counting, the only potential spike is the time that free()
may take on a bad day, but that's nothing on the same scale as the main
thread blocking due to socket abuse wrt to the GUI.

However with mark'n'sweep, there is a small delay (i think it's 25 ms
nowadays on a typical setup of Ruby/GridFlow/Pd) that is caused by
non-delayed garbage collection. In Ruby you can disable GC for a short
while, which could be useful, if the audio didn't have a need for
continuous CPU, hence the solution to that is either a faster GC, a
multi-pass GC, or a threaded GC.

> 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:

For Ruby itself it will make sense in the future and then GridFlow will
behave properly on the audio side (I mean the latency will be
reducible). For Pd it's overkill, and since the only simple mark+sweep is
non-realtime, we're stuck with ref-counting. But that's not such a big
problem because Perl and Python still use ref-counting, and the problems
you get with circular references with not too much hassle; techniques
include:

Weak Pointers, which are pointers that do not affect the ref-count, and
self-destruct when the pointed-to is gone;

Symbolic/Numeric References: you instead record the location of an object
in terms of another pointer or global name, and then also you record how
to get to your object from there. e.g. the list "myarray1 42" can be used
to talk about element #42 of the array myarray1 declared globally, without
having a true pointer to it.

> 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...

That _is_ too close to C. People can scream as hard as they want about
GridFlow being conceptually hard, but inviting people to allocate and free
stuff themselves is pure suicide and a real joke.
> 
>  > (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 ;-)

Being well-versed in Perl/Ruby, i know the mentality. (In Ruby, there are
nine different syntactic forms for an "if" statement. Really.) However in
any language, as minimal as you want (Scheme), there are also always
several ways to do anything. The problem is more about exactly how many
(and which ones) you should provide to make the users comfortable.

Well, the issue I wanted to raise is slightly different. It has to do with
the mapping of concepts from one language (whichever) to the other (here,
PureData). Very often, something that is a class in Pd is normally just
a method outside of Pd (like [+]), and sometimes it's the other way, like
[f] being a holder of float (and also a message type and an atom type,
which are very distinct things!).

I would enjoy some kinds of guidelines for the (potentially automatic but
possibly instead manual and heuristic) mapping of functionality from a
programming language like Perl/Python/Ruby/Scheme to PureData.

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju