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