[chuck-users] wishlist for the new year

[Hans Aberg]

On 6 Jan 2010, at 18:30, Kassen wrote:

> fun int foo( int arg)
>   {
>   return 3;
>   }
>
> fun void bar( int arg)
>   {
>   <<<"boring">>>;
>   }
>
> //overload
> fun void bar ( fun arg)
>   {
>   <<<"fun">>>;
>   }
>
> 1 => foo => bar;
>
> Would that print "fun" or "boring"? That last line is a case where  
> we refer to the function without parentheses yet still expect it to  
> be called and to return under current syntax.

In C++, thinking about the output stream operator >>, this is resolved  
by defining how this operator binds. This enables writing stream  
manipulators, not possible in ChucK, as it does not seem to have any  
such rules.

So if the last line binds as
   (1 => foo) => bar;
then the inner parenthesis returns an int, and then it must be the  
first bar. To get the other one, one must write explicitly
   1 => (foo => bar);

Treating functions as data is of course possible in C/C++, only that  
they are static there: can only happen at compile time. ChucK is  
interpreted, so all already happens at runtime. Perhaps that makes it  
easier to implement the stuff.

The other question is what kind of polymorphy one wants to have. In C/C 
++, one would have to specify the type of the function:
   fun void bar(fun int f(int))
so that the actions operated on f can be checked - if one would not  
want to be able to pass a string onto f, and the compiler should check  
that, this is necessary.

But one wants polymorphy when implementing more general things, like  
say a sorting algorithm that should be applicable over a range of  
types. One would then want the computer to check that the data type  
has defined a comparison operator necessary for the sorting. (In C,  
one can do this by essentially type-less function pointers.)

C++ tries to amend this by a complicated template system. Haskell uses  
a Hindley-Milner-like type system, whose main property is that the  
polymorphic type of an expression can be computed (by unification of  
the components). For example, in Hugs, I can compute the type using  
":t", if first define a function without a type as
   f (x:xs) = x
and the in HUgs interactively
   :t f
   f :: [a] -> a
It is nice, but imposes huge restriction on the function name  
overloading.

   Hans