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
