Hi Spencer, Very useful info. I'll snip a lot and only comment the stuff I have more questions or additions for.
Additionally, you can save a little time/memory by using arrays of null UGen references, rather than arrays of UGens. Hmm isn't this a bit suspicious, in terms of semantics. I mean the default of instanciating arrays as though objects where already constructed. If they are added, that design cannot support classes that lack a parameterless constructor, singleton classes in which it is private, and abstract classes or interfaces which cannot b instanciated in the first place. IS string also a class? I read something to that effect but cannot find its methods anywhere. I don't seem to be able to do much apart from concatenating them.
will there be a template mechanism or the ability to downcast arguments? You can always cast them to back to what they were initially, using the $ operator. You just have to actually know what they are. Ah that's the question. Quite OK for homogenous stuff but I can already imagine a design in which this is not known. IN which I have to branch on a type name. That's a bad smell in OOPy circles often but not always. Many recursive data structure dumpers require, for example, that you know whether an element is a single item, some reference to an array or object or something else. Not very relevant to chucK right now, though, as there's no serialization support.
consider that most programmers coming to ChucK will think that == makes the most sense, while arguably non-programmers won't have any particular predisposition to whether = or == is better. OK, but then again one could claim the same about => if it didn't serve a dual or triplle role as a way to pass function arguments and connect uGens. I'd like to be able to overload => on my own classes some day, though.
used to = for assignment, as expressions involving = are caught with a compile-time error instead of a more subtle runtime error. Yes, agreed. Some forms of Basic are the worst, they use = in a boolean context to mean equality but if it is not in a control structureand looks like a plain assignment, that's what it is. Pascal has := too.
Another thing I like is the syntactic sugar for handling setters as properties. That is: object.setter(firstArg); can be turned into firstArg => object.setter; So you don't have to know it is a function call behind the scenes. But could this also be exteneded to cover getters as well. Namely that as an l-value: object.getter() => itsValue; Could be reduced to: object.getter => itsValue; Where l-valueness and lack of braces Would imply a method call, provided that the class does not have a public data member named getter. This is an interesting idea, but it wouldn't work right now because functions without parentheses are already rvalues (returning the function address I believe). Hmm interesting. FUnctions as a first-class datatype are very nice and that makes sense for just that, functions and static methods. But I don't see much sense in getting the address of an instance method as you cannot determine that its invocant is of the correct type anyway. I think perl let's you do that, but hey it's Perl, <smile>.
don't know yacc either, but in my experience its pretty easy to pick up the basics by just reading a .y file. Ah I'll take a look. I'll be lazy and ask if there's a direct URL to the current CHucK yacc grammar. I usually don't get the source, though in this case it might be beneficial.
-- With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/