[chuck-users] wishlist for the new year

[Hans Aberg]

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