Brian Hulley wrote:
David Menendez wrote:
Brian Hulley writes:
4) Would it be worth reconsidering the rules for top level names so
that class methods could always be local to their class (ditto for
value constructors and field names being local to their type
constructor).
Qualified module imports are the way to go, here. Do you really want
to start writing "if x Eq/== y Num/+ 1 then ... "?
I'm beginning to see that qualified module imports are indeed the
only way to go,
One reason I forgot: Suppose person A writes ClassA which uses "foo" as a
method name, and somewhere else, person B writes ClassB which also uses
"foo" as a method name, and both classes become widely used for several
years.
Now the problem is that person C may come along and notice that there is a
useful abstraction to be made by inheriting both from ClassA and ClassB. But
both of these define "foo" and there is no mechanism in the language to
resolve this.
The language C#, which was designed from the outset for programming in the
large, already had a solution in the very first release of C#, namely that
the interface name could be used to qualify a method name in cases of
ambiguity, so transposing this to Haskell, you'd have something like:
class ClassA a where
foo :: a -> Int
class classB a where
foo :: a -> String
class (ClassA a, ClassB a) => ClassC a where
bar :: a -> (Int, String)
bar x = (ClassA#foo x, ClassB#foo x)
As I see it, Haskell, great and innovative as it is, is still stuck in
"programming in the small" and some of the mechanisms needed for programming
in the large are not yet available - it is as impossible to ensure that
there will never be conflicts between names of class methods as it is to
ensure that there will never be conflicts between module names in packages
written by different groups of people, and languages like Java and C# solved
these problems right at the beginning but Haskell for some reason has
ignored the issues, only recently just starting to address the package
module name conflict problem for example even though the language has been
around for more than a decade.
I'm also wondering if it would be a good idea to be able to declare some
class methods as final, so they don't clutter up the dictionary at runtime,
and so that we could end the dubious practice of declaring some functions
which are conceptually part of a class as top level functions outside the
class just to save space/time in the dictionary and therefore needing the
physical module to create the conceptual grouping instead of using the
language level grouping provided by the class name.
Anyway these are probably more long term ideas but I mentioned them now just
to hopefully start the ball rolling (the above should not be taken as a
criticism of Haskell, I'm just saying that at some point we need all the
normal mechanisms that everyone else (Java, C#) takes for granted because
there's no point waiting till we encounter the same well-known software
engineering problems that already have well established good solutions).
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
