On 4 Jan 2010, at 14:58, Kassen wrote:
These are much more modest additions, and it would be nice to see them.
I wonder how close we could get to Lambda calculus by allowing for overloading the ChucK operator from within the language? I want that. The ChucK operator is clearly "ChucKian" and I feel it has proven to be very expressive.
In Haskell, it is (examples below) really the Hindley-Milner type system that imposes limitations on function name. Similar to the unification in of Prolog clause heads, it requires two expressions to be unifiable. In more diverse system, as math, this is not true. And if one would want to keep the C++ style name overloading that Chuck, one must find ways to localize names. To be more explicit by these problems, Haskell has a class class (Eq a, Show a) => Num a where (+), (-), (*) :: a -> a -> a negate :: a -> a abs, signum :: a -> a fromInteger :: Integer -> a fromInt :: Int -> a -- Minimal complete definition: All, except negate or (-) x - y = x + negate y fromInt = fromIntegral negate x = 0 - x As you can see, this class has arithmetic operators (+), (-), and (*) in it, plus some sporadic functions fromInteger (conversion from multiprecision integers), fromInt (conversion from int). Now, the limitation is that in order to name load these operators, one has to define a data type and make an instance of the whole class. So you can't just define a monoid which overloads just (*). It blocks all uses of the symbol (*) outside this class. It has to do with the polymorphy of these operators: (+), (-), (*) :: a -> a -> a The "a" can be substituted with any other type, which may itself be polymorphic. The class tries to ensure that the behavior of these operators are consistent over all types. (Haskell does however admit partially defined classes, so one can skip some definitions. But it is still ain't convenient.) So, for example, it is not possible to define a data type "Vector a" that contains a lists of elements from a data and then define scalar multiplications (*) :: a -> Vector a -> Vector a because (*) must be of type a -> a -> a and defined via the class Num. So this is something that is a problem when trying to do C++ style name overloading. There is a Haskell project of a "Numerical Prelude" that should refine the original Prelude so that such things should be possible, but it seems stalled for years now. And attempts to generalize seem getting stuck on essentially extending the type system with elements from mathematical logic. This can't be done easily, because this type unification feature simply isn't true in general math or even programming. So even though this polymorphic type system is nice in some respects, it also prevents one from doing the operator overloading one might want to have.
Aside from that I think that the suggestions and notes here are really interesting and I'm learning a lot from them but I think it would be short-changing ourselves to have this debate solely in CS terms. CS to me (no offence to the CS professors here) is a tool and the end result will have to be music/sound/etc. The tools will have to make practical sense in reasoning about music and sound.
It might be easier to talk about these things using muck-up example code that would do some musical thing. In the end we would like to express feelings (or learn about sound, or get our feet wet in code...) and while CS papers might be a stage in getting there they aren't so great as a end result. Personally I would have made Ge fail if his thesis (which really is quite interesting) wasn't backed by people the world over actually using this stuff and enjoying themselves.
I don't mean to critique the proposals above saying this, I just wanted to make some suggestions on what to judge such proposals on and provide a perspective on how we might make them in the most efficient way.
This is in fact an important aspect of language design: a language tends to be better if the developers are using them. Languages designed for others to use (like Cobol I think was mentioned) tend to be rather awful. I think Haskell has a very nice syntax. Perhaps it can influence if ChucK gets functional. But ChucK must find its own way. Hans