Well, yes, I was referring to Java and C++, whose object model more
closely matches what Chuck uses than what Scheme uses.

Yes, so "strongly typed" OO languages. I should have used that word, as opposed to taking Scheme as a example of something very OO yet not -typically- strongly typed (you can write strongly typed Scheme if you'd like)

If you want to
make Chuck more like Scheme, then that's a different (and very
interesting) discussion.

Well, no. I like both but I see no need to combine them. I do think that strategies like returning arrays as a way to enable us to go over trees are nice and we can get inspired here and there.

And I'm not too familiar with the Scheme
community, but I have a feeling that if you proposed using
introspection when you could just use polymorphism (or multiple
dispatch, or some other mechanism that Scheme offers that would
provide a cleaner solution), someone in the community would probably
point out that there is a better solution.

In Scheme you'd use "(integer? foo)" to determine whether foo is a integer; it's no great issue there, but then in Scheme you are far more likely to encounter objects of a unknown type. Here I am not after any one specific strategy; I'd just like to be able to tell what kind of thing a object is in some way and suggested some syntax for that.

Of course the underlying issue (situations like swapping a Chorus for a Reverb) could also be solved in another way, like encapsulating both objects in a new kind of class that would have a string member telling us the type. This could be done by extending UGen and allowing us to overload the chuck operator. A lot of issues that we have could be solved by allowing us to overload the chuck operator, I suspect.

I simply want to encourage
people to look at what people using other languages (that are similar
to Chuck) have done to try to solve similar problems and think about
the tradeoffs that they have observed in those different solutions.

Yes. I think that's a good idea and clearly you know a lot about that. I'm not sure that any one syntax would need to exclude any given underlying strategy but we could borrow the syntax as well, if it's nice.

I would consider livecoding an extreme example of a quick script, so I
would say that this is a case where introspection might be a better
way to get things done.

Probably. And things like overloading the chuck operator would be too cumbersome there. We do have a bit of a odd position in that we have a statically typed and compiled language that we -amongst other things- want to use in a way that's more typical for dynamically typed interpreted systems. It's a bit of a unusual problem, maybe it needs some strange new solutions as well?

Kas.