On 10/1/07, skaller <[EMAIL PROTECTED]> wrote:
> It isn't clear how useful this would be, since likely it
> would be restricted to inference from the function definition
> and not be allowed to infer from usage. Furthermore because
> of overloading, many inferences would fail whereas in Ocaml
> they'd pass due to the lack of it.
I've wanted something like this for a while :) Generally, I'm fine
with specifying types at functional boundaries (although occasionally
not needing to would be nice for small functions). We could use it
similarly to how haskell does things, where you specify the types at
the function boundaries, but use inference inside the function. It's
always been a bit of a pet peeve that you need to specify types in a
higher order lambda even though it's obvious to a human what type the
inner function will take:
open List;
proc foo (xs:list[int]) {
iter (proc (x:int) {
print x;
}) xs;
}
It would be soo nice if this hypothetical type inference could just have it be:
open List;
proc foo (xs:list[int]) {
iter (proc x {
print x;
}) xs;
}
And if we ever implement the ruby shorthand lambda functions and
reorder the arguments to take advantage of the '.' operator, the this
could look nearly like ruby:
open List;
proc foo (xs:list[int]) {
xs.iter { |x|
print x;
};
}
:)
-------------------------------------------------------------------------
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
