[chuck-dev] string support

[Stephen Sinclair]

On Mon, Oct 27, 2008 at 12:40 PM, Joachim Ganseman <musicalign at gmail.com> 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