On Tue, 2007-07-31 at 00:50 -0700, Erick Tryzelaar wrote:
> We don't support ocaml's "with" construct with our records yet, do we?
Nope. It could be done I guess, with compiler support and caveats:
> val x = struct { a = 5; b = 6; };
> val y = struct { x with a = 1; }; // equals struct { a = 1; b = 6; }
To make this work, the compiler needs to know the type of x.
Then it can synthesise:
struct {
b = x.b; // synth
// a = x.b overriden
a = 1;
}
The
> This can help a little with emulating keyword arguments to a function,
> with something ugly like this:
On todo list .. the syntax sucks with keyword 'struct' needed,
but { .. } has two other meanings as a closure for both
procedures and functions. In fact, the struct thing is actually
a closure, if you write:
{ var a = 5; var b = 6; }
then the 'stack frame' of this procedure more or less IS the
record of variables a and b. So perhaps
&{ .. }
might be used instead of
struct { .. }
?? .. although it suggests a pointer .. lol .. ??
> proc foo1 (s:struct { a: int; b = 5; }) { ... }
> foo1 (struct { a = 1; });
>
> proc foo2 (s:struct { a = 4; b = 5; }) { ... }
> foo2 (struct {});
>
>
> Where the struct we pass in is automatically converted to use "with"
> expansion. Would this violate the whole "no automatic conversions"
> rule?
You're suggesting default arguments .. and that definitely
does break the rule. The problem isn't the rule as such,
the problem is that overload resolution depends on the argument.
The type of the argument has to be known precisely (up to lvalueness)
for overload resolution to work -- there's no subtyping support
in the unification engine.
Note the overload routine DOES support 'generic subtyping' aka
specialisations .. i.e. it does support subtyping 'type variables'
but not actual types.
HOWEVER .. this problem wouldn't exist with structs, only records,
because structs are nominally typed.
Consider instead:
struct X {
var a = 1;
var b = 2;
};
f: X -> int;
println$ f$ X { b = 99; };
Here, f takes an explicit X argument, and there is a 'generic'
_ctor_X function accepting suitable 'records'.
This doesn't impact overloading ordinary functions, although it
does impact overloading _ctor_X function things. However the 'lookup'
of _ctor_X things is special anyhow, so we can code a special check
to see if a record is given as an argument.
The trick here is that 'X' is a type and so can't be overloaded itself,
only one type named X is allowed in scope.
Perhaps something like this would be OK?
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
