[chuck-users] Intraspection - an example of what I'm attempting

[Kassen]

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.

>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20101109/793b30ad/attachment.html>