Re: [chuck-users] Intraspection - an example of what I'm attempting
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.
Just my own opinion, but over the past three years I've totally fallen for javascript. I wish chuck were like javascript, with the addition of the strongly timed incredible chuck VM and timing model! I've written programs in strongly typed and compiled languages like Fortran and C, as well as looser languages like scheme. Javascript and scheme allow me to do almost anything with very little effort. Add a brilliantly designed library like jQuery, and one can almost think an idea into code with no effort at all. Of course, I'm completely overstating the issue, but I think that draconian type checking and limited semantics are really not helpful when all you want to do is get complex ideas into code, focusing more on the idea / algorithm than on the code / implementation. Just my three cents... -- Rich - extremely powerful and expressive. ----- Original Message ----- From: Kassen To: ChucK Users Mailing List Sent: Tuesday, November 09, 2010 4:38 PM Subject: Re: [chuck-users] Intraspection - an example of what I'm attempting 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. ------------------------------------------------------------------------------ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (2)
-
Kassen -
Rich Caloggero