[Haskell-cafe] Avoiding name collisions by using value spaces instead of modules

[Brian Hulley]

----- Original Message ----- 
From: "Cale Gibbard" <cgibbard at gmail.com>
To: "Brian Hulley" <brianh at metamilk.com>
Cc: "Daniel Fischer" <daniel.is.fischer at web.de>; "Haskell-cafe" 
<haskell-cafe at haskell.org>
Sent: Sunday, January 08, 2006 5:54 PM
Subject: Re: [Haskell-cafe] Avoiding name collisions by using value spaces 
instead of modules


>On 08/01/06, Brian Hulley <brianh at metamilk.com> wrote:
>> For example, suppose I'm writing a module M that deals with grammar, 
>> where
>> the elements in a grammar rule are parameterised so that rules can be
>> written using strings but processed as if we'd used ints instead:
>>
>>     data Element a = Terminal a | Nonterminal a | Action a
>>
>>     data Rule a = Rule (Element a) [[Element a]]
>>
>> Now I want to convert elements and rules from a to Int, so at the moment 
>> I
>> have to write:
>>
>>     convertElement :: Element a -> CM (Element Int)
>>     ...
>>
>>     convertRule :: Rule a -> CM (Rule Int)
>>
>> for some appropriate monad CM.
>> Whereas I would have much preferred to use just the word "convert" in 
>> both
>> cases. It is tremendously annoying to have to suffix everything with the
>> type name.

>This is what typeclasses are for.

>class Convert c where
>    convert :: c a -> CM (c Int)

Type classes just seem overkill for this kind of thing. All I want is 
compile time resolution of an overloaded identifier, whereas type classes 
give all the machinery that would be needed if I wanted runtime ad-hoc 
polymorphism, with all the attendant verbosity, just so that the compiler 
can then optimize out the runtime polymorphism behind the scenes for cases 
like the example above.

After all, I just want to write two very simple functions, so the effort to 
factor into a type class + two instances, also having to include the Convert 
c in the context whenever I call one of them just seems really painful. 
Also, the word "Convert" is now used up as well...

Also, when I'm just writing code in an exploratory way, I don't know in 
advance what the common things are that could be factored out into type 
classes (except perhaps in very simple examples like that above), so while 
I'm writing the code for the first time there is still a problem trying to 
think up different names.

Regards,
Brian.