Re: ROverloading

[John Max Skaller <skaller@ozemail.com.au>]

Dave Berry wrote:
> 
> John Max Skaller wrote:
> 
> >       Unfortunately, overloading isn't quite so simple when
> > you've also got type inference:
> 
> That depends on how general you try to be.  I'd be quite happy with a system
> that allowed multiple definitions of a name, but forced applications to be
> monomorphic.  In your example, the definition of f would require a
> disambiguating type annotation (or assume a default):
> 
> >       let f a b = a + b in
> >       let x = f 1.0 2.0 in
> >       let y = f 1 2 in
> 
> would become
> 
>         let f a b = a + b : int in ...
> 
> Theoretically inelegant, but pragmatically sufficient.  As indeed you seem
> to be doing in Felix.
> 
> I'd use the module system to introduce and control overloading, rather than
> trying to extend the core language.  It seems a simpler route.

	In Felix, overload resolution is done during a name binding
phase. It is necessary to 'chase' the type of variables introduced
without a type annotation recursively, but the process appears to
always terminate (though I'm not completely sure).

	There are no 'type variables', hence no generic functions:
instead, I plan to use functors (as in ocaml) exclusively. This fits
better with the back end target (C++), and I hope it will be easy
enough for C++ programmers to use .. as well as generating efficient
code .. and providing some interesting challenges in reducing
code bloat (the compiler target is a shared library :-)

	But I do not have a good model for using the module system
to control overloading. I worked on the design of namespaces in C++
and don't really consider it satisfactory. So I'd be interested in how
you'd control overloading leveraging the module system. ??


	In felix, only functions can be overloaded, NOT function
closures. So while you can do this:

	module fred { function f(a:int):int { return 1; } }
	val f = fred::f of (int);

the 'f' in the outer scope cannot be overloaded. It isn't a function,
its a function closure. It would be possible to implement:

	open fred;
	open joe;

so that function overload sets merged (and other duplications caused an
error on use). This is equivalent to 'using namespace fred; using
namespace joe;' in C++ (except that it doesn't change the public
interface
of the module doing the opening). It's also very coarse.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net