On Mon, Oct 27, 2008 at 12:40 PM, Joachim Ganseman wrote:

Hello,

After some experiments of my own, and following the tutorial at ISMIR'08, I'd like to see if I can contribute something to ChucK. Main thing that I'd like to see added is support for strings. Not much, but in such a way that a fairly common thing like a parser could be written. I work with MusicXML myself, and I'd love to be able to parse a music score in ChucK.

Cool! Another pre-req for that of course will be to enable file I/O. This is less-than-obvious if you consider real-time issues. (I've mentioned before that I think a solution to this is to model I/O on Events instead of as blocking function calls.)

Outputting and concatenating is a good beginning, but what I'd like to see is e.g. an [] operator to select characters in a string (treating it as an array), eventually augmented with some basic functionality like the things that can be found in the C++ STL or the Java standard library.

Before I dive blindly into the code and hacking things together, I'd like to open this up for discussion first: - a lot of C++ STL implementations are infamous for not being threadsafe. Shredsafeness seems to me however a first requirement. True or false? If anyone has some good pointers or links on this issue, please let me know!

In practice shreds are not run with true concurrency, so you shouldn't have any problems with this. The ChucK VM takes turns executing each shred's code. If there are any semantics to be aware of to future-proof your code, however, I'm not aware of it.

- Any major programming language today has to be able to process Unicode strings. This also brings up the problem of different encodings, etc... Perhaps it's a good idea to model strings after Java, and have a look at how Java VM's do it?

Unicode is a huge headache, but sure. It may be enough to support ASCII but keep unicode in mind for the future. You gotta start somewhere after all.

- After giving it some thought I'd like to avoid introducing a character datatype, and instead regard a character as a string with length 1. There's already types enough in this world. But is this feasible, or do I miss something which would require a character type?

I like the idea, I think.

- Is it perhaps easier to integrate a string library from another open source project instead of writing an own library? Pointers and links very welcome!

Well, the ChucK math functions are borrowed from C, of course, so I see no reason not to borrow an API from elsewhere for strings as well. One main difficulty is that parsing requires a lot of memory allocating and deallocating, which is not good seeing as I don't think the status of ChucK's garbage collection is really up to par. (Am I wrong on this?) In any case, some thought should be given to how string handling will interact with memory allocation issues. You'll probably have to dive into the heart of the VM to understand this completely and make informed decisions.

- Java and C++ have very different ways of handling strings. In Java all strings are managed in a pool in the VM and only references to them are used at runtime, while in C++ you can endlessly screw around with pointers to char arrays. Which paradigm is preferable in ChucK? (personally, I tend to say Java, but then again, I truly hate the difference between the == and .equals() operators messing with my mind)

I think a more managed approach to strings is probably called for. Personally I love Python's list slicing syntax. (Though the concatenation ' '.join() can go...!)

I don't have much spare time so I'm not going to promise that I'm even going to start working on this - if the task at hand would eventually seem to be too big, It's perhaps better for a grad student's project...

I've found it pretty interesting to get into the VM's internals. Having a specific project in mind is a good excuse for jumping into it, even if nothing concrete comes out immediately. Steve