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