RE: ROverloading

RE: ROverloading

[Dave Berry]

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.

Dave. 

Re: ROverloading

[John Max Skaller]

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

ROverloading

[John Max Skaller]

Mattias Waldau wrote:

> >> I would like to note that type inference (i.e. code without
> >> annotations) helps a lot when developing programs: the annotation free
> >> code is not only easier to write but also easier to maintain since it
> >> is kind of ``auto-adaptative'' and resistant to reorganisations and
> >> names modifications.
> 
> If this were important, we shouldn't have different operators for * and *.
> I had to change a program from integers to float recently, and it isn't fun
> at all.

	Overloading is, perhaps unfortunately, more or less
mandatory in the long run, perhaps not so much to support 'ad hoc
polymorphism'
as to relieve the programmer of learning lots of names for
things. In Ocaml, learning + for int and +. for float isn't
so bad. But add in ten other integer representations, and we're rapidly
forced to resort to named prefix operators (i.e. function names).

	Unfortunately, overloading isn't quite so simple when 
you've also got type inference:

	let f a b = a + b in
	let x = f 1.0 2.0 in
	let y = f 1 2 in 

If we take 'f' to be monomorphic, then
the second call is in error, because the overloaded + in the
definition of 'f' doesn't determine it's type until x is
calculated. Otherwise, 'f' could be taken to define an overloaded
set of functions (somewhat like a C++ template) and the calculations
of x and y would call different specialisations .. but this rapidly
gets quite messy.

Felix supports overloading, but it works more easily because
functions must be explicitly typed. Nevertheless it is sometimes
necessary to explicitly resolve an overload:

	function f(a:int):int { ..}
	function f(a:float):float { ..}
	val g = f of (int); // which f?

because there is inference of val's and var's, and, even without that:

	function g(f:int->int):int { .. }
	function g(f:float->float):float { .. }
	.. g(f of (int)) .. //which g? depends on which f!


-- 
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