[Haskell-cafe] Avoiding name collisions by using value spaces
instead of modules
brianh at metamilk.com
Tue Jan 17 16:44:52 EST 2006
Tomasz Zielonka wrote:
> On Sun, Jan 08, 2006 at 01:06:18PM -0000, Brian Hulley wrote:
>> 5) We can get all the advantages of automatic namespace management
>> the OOP programmers take for granted, in functional programming, by
>> using value spaces as the analogue of objects, and can thereby get
>> rid of complicated import/export directives
> There is nothing complicated in Haskell's module system. It's very
> simple, explicit, independent from the type system and therefore easy
> to understand.
There are many concepts that one needs to understand ie importing/exporting,
qualified/unqualified, hiding, selecting, and a strange syntax that looks
like tuples but isn't anything to do with tuples.
> "Verbose" or "low-level" would be better accusations.
I agree with those as well.
> It seems that you want to introduce some kind of C++'s Koenig's lookup
> to Haskell. Is it your inspiration?
First argument lookup works well in C++, but perhaps wouldn't work nearly so
well in Haskell due to the presence of polymorphism/higher order functions.
Another source of inspiration was Smalltalk, where instead of thinking in
terms of files (modules) one just thinks in terms of objects(types) and
methods(functions) and enters new types/functions via a browser instead of a
My real purpose is to try to find a way to be able to concentrate on
values/types without having to worry about where to put them. Just as we
take garbage collection (or other memory management) for granted, I'm trying
to find some way of automatically managing the "storage" of value/type
In C# and Java, every class must be stored in a file of that name, and most
C++ programmers follow this rule as a convention. Whereas in Haskell (or
ML), where there are lots of small data declarations, I don't see any simple
rule for where to put stuff. It is all too easy to end up with a gigantic
module where one type has been converted into another and another etc etc
and soon it is very difficult to think up different names for
functions/variants/fields, and remember even where the functions are defined
within the file, leading to much scrolling and search operations when
> For me, C++ doesn't seem to be a
> source of good ideas for programming language design ;-)
Certainly C++ has its problems, but I think some rather clever ideas can be
salvaged from it (eg the use of traits in template programming) :-)
More information about the Haskell-Cafe