[Haskell] Per-type function namespaces (was: Data.Set whishes)

[ozone at algorithm.com.au]

On 27/02/2004, at 8:28 AM, Abraham Egnor wrote:

> I think that this is a problem that can be solved with a simple 
> convention
> change, rather than a language extension - instead of appending type
> names, I think it would be much better if modules simply used the 
> short,
> convenient, common names and expected the user to import them qualified
> where overlap is a problem - in short, do exactly what DData does.  
> It's
> slightly more verbose than OO-style: "Map.add map key value" instead of
> "map.add(key, value);" but I don't think that "what OO does" is a good
> language design target.

This is exactly what was discussed in the thread before I barged in 
with per-type function namespaces, and it's not a good solution because 
of what Alastair has mentioned.  It's also not a good solution because 
I still have to type "Map.add map" instead of "map.add": the type 
system already knows that map of type Map, so why should I have to 
qualify it even more by sticking a module name in front, and also 
encode the type name into my function because the module/namespace 
system isn't good enough to deal with this issue?

I also agree that "what OO does" is not a good language design target, 
but I do think that "leverage type system to make programming nicer for 
you" is a good design target :).  We're using a form of hungarian 
notation for function names, which is necessary because of a global 
namespace; OO people abolished this a long time ago.

> Another random thought: what you describe sounds awfully similar to
> typeclasses, just with a single function in each typeclass.

It's not the same as a single-function type class, for the reasons that 
I pointed out to Keith Wansbrough in an earlier email.


-- 
% Andre Pang : trust.in.love.to.save