Default arguments are now implemented. /////////////////////////////////// #import <flx.flxh>
fun df(a:int=1,b:long)=> long a + b; println$ df (b=2L); // a should default to 1 //////////////////////////////////// BUGS: The argument must be a record. The empty record or unit tuple doesn't work. Will fix soon I think. Note: empty record isn't equal to unit tuple. Probably should be. They are of course isomorphic. Please test! Issues: Interaction with polymorphism may not work. Most default arguments will be non-polymorphic, we need USE CASES for polymorphic defaults. A default argument is bound in the context of the function, not inside the function, so may NOT refer to other parameters (which means the type had better not be polymorphic .. :) Note again: the argument MUST BE A RECORD, i.e. you have to use named arguments for defaults to work. You cannot supply a tuple argument which is too short and let the defaulted tail values fill the tuple out. ********************************************************* Note again even more: named arguments and defaults only apply to the FIRST argument of a curried function. This is because the application to the second argument is made by a closure of a child function the main function returns, and so it is not a direct call, and overload resolution doesn't apply. That's the theory, but the practice is different: the overloading routine DOES in fact consider as many curry arguments as supplied in a call when resolving overloads. The problem is arguments are overloaded based on the main function's type, and, in the special case of a record argument in the first position, the parameter names. The names of the child function chain parameters (those of the second and subsequent arguments) isn't recorded in the function, and could only be found be deep analysis which tried to locate the child function whose closure is returned: fun f(x:int) (y:int, z:int) => x + y; is modelled by: fun f(x:int) = { fun g(y:int,z:int)=> x + y+z; return g; } so to match f 1 (y:2,z:3) would need matching against g .. the semantics are (f 1) (y:2,z:3) and (f 1) is an expression, so it isn't clear how to lookup the parameter list of g from that.. this could be fixed with a change in representation so f is represented as written, rather than being desugared. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language