[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2000-12-19 (16:29) |
From: | John Max Skaller <skaller@o...> |
Subject: | Re: ROverloading |
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