[Haskell] Per-type function namespaces

Peter Strand peter at zarquon.se
Thu Feb 26 21:20:37 EST 2004

ozone at algorithm.com.au wrote:
> I've had an idea stewing in my head to do with per-type function 
> namespaces, .....
> The idea that I've been throwing around is to be able to define a 
> separate namespace for each type; a function can either belong in a 
> "global" (default) namespace, or belong in a particular type's 
> namespace.  So, in the above example, instead of writing "addToFM fm 
> ...", we could instead associate an 'add' function with the FiniteMap 
> type, so we could write "fm.add ..." instead.  Provided that fm's type 
> is monomorphic, it should be possible to call the 'correct' add 
> function; if we defined another 'add' function that's associated with 
> the Set type, that will only get called if the 'x' in "x.add" is of type 
> :: Set.  So, like OO languages which inherently give separate namespaces 
> to their different objects, here we give separate namespaces to 
> different (monomorphic) types.  In this case, if one simply writes "add" 
> instead of "x.add", the compiler throws an error, because there is no 
> 'add' function defined in the default namespace; add is only defined 
> when a programmer writes "x.add" where x :: FiniteMap or x :: Set[1].

Wouldn't something like Koenig Lookup in C++ solve this problem as
well, without the need for a new (strange) syntax?
That is, a function is looked up in the namespaces of its arguments as
well as in the normal places. So "add fm k v" where fm :: FiniteMap,
x :: Int, v :: String would look for "add" in the modules where
FiniteMap, Int and String was defined.

However, both of these methods means that we have to know the types
of the arguments to be able to resolve names, probably forcing
us to write a lot more type signatures than otherwise.
It feels a bit like we're just trading one problem for another..
("lots of qualified names" vs. "lots of type signatures").

But it might be worth it.. Would Koenig lookup (or something similar)
be feasable in Haskell? Or would it just lead to unnecessary complexity?
Name lookup in C++ is not exactly simple, so it might be a bad place
to borrow ideas from.. ;)


More information about the Haskell mailing list