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

[Brian Hulley]

Brian Hulley wrote:
> Cale Gibbard wrote:
>>> Unifying these two under a single operation is certainly trickier,
>>> and it's a little more questionable that it should be done at all,
>>> given that their types are so different -- below is the closest I
>>> could come to it off-hand.
>>> <snip>
>
> Thanks! I'm impressed. Obviously there is a lot more power in type
> classes than I'd thought.

Of course, this still doesn't solve the original problem I was trying to 
address, namely that I want identifier bindings to be pulled into scope by 
their typed context (ie value type or return type + arg types) so that 
functional programmers could get the same advantages (in fact even more 
advantages) than OOP programmers.

With type classes, every use of any specific identifier, within the whole 
program, would have to be declared an instance of a single global type 
class, which would then be imported unqualified into the module so that you 
could write insert (1,2) m etc without having to qualify the word "insert". 
(Because if these type classes/instances were imported qualified we'd just 
swap "Set.insert" for "Collection.insert")

With the ty-tuple idea, all functions in a module are automatically 
organised into sub-modules and brought into scope only when needed, so every 
function in a program could be typed into a single file thus freeing the 
programmer from the onerous burden of having to work out where to put them 
manually. (The programmer would still put data declarations into different 
modules)

I must admit my thinking is strongly influenced by years of C++ programming, 
but so far I haven't seen any description of how one decides what module a 
function should be placed in in functional programming, and the existing 
module system seems like a pauper's alternative to static class methods in 
C++, C#, or Java, since in Haskell, you need to use the same name for the 
module and the type (for Data.Set etc) yet this choice of same name is not 
enforced by the language even though the user thinks of them as being "the 
same", and in fact two import directives are needed to maintain the illusion 
that they are the same so you can write Set a and Set.insert etc...

Regards,
Brian Hulley