Andrew, I'm replying to the list to this. I hope that's ok. It seems to me like this was intended to go to the list as it doesn't seem especially personal.<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br><br>
</div>Well, yes, I was referring to Java and C++, whose object model more<br>
closely matches what Chuck uses than what Scheme uses. </blockquote><div><br></div><div>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)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If you want to<br>
make Chuck more like Scheme, then that's a different (and very<br>
interesting) discussion.</blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> And I'm not too familiar with the Scheme<br>
community, but I have a feeling that if you proposed using<br>
introspection when you could just use polymorphism (or multiple<br>
dispatch, or some other mechanism that Scheme offers that would<br>
provide a cleaner solution), someone in the community would probably<br>
point out that there is a better solution.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I simply want to encourage<br>
people to look at what people using other languages (that are similar<br>
to Chuck) have done to try to solve similar problems and think about<br>
the tradeoffs that they have observed in those different solutions.<br>
<div class="im"><br></div></blockquote><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I would consider livecoding an extreme example of a quick script, so I<br>
would say that this is a case where introspection might be a better<br>
way to get things done.<br><br></blockquote><div><br></div><div>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?</div>
<div><br></div><div>Kas.</div></div></div>