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.. ;)
/Peter
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
