--- On Sat, 8/16/08, Andrew Coppin <[EMAIL PROTECTED]> wrote:
> > Although it is possible to hide packages by GHC options, we should not
> > do this, because several libraries might use different Hash tables and
> > it would not be possible to write a program which uses many of these
> > libraries. It's better to add a distinguishing part to the module
> > name, like Data.HashTable.Coppin or so.
>
> This is more the sort of thing I had in mind, yes.
This seems to be a common approach, but it runs counter to the objective of
separating 'provenance' from module naming. 'Coppin' is (part of, sans
version) the provenance of the hashtable implementation, so I'm not sure how
this sort of scheme is better than just shoving the unique prefix at the front
of the module, e.g.
Coppin.Data.Hashtable
Though embedding the provenance down in the hierarchy is a common pattern, I
think it is can be pretty messy. For example, the Parsec package exposes many
modules, including "Text.Parsec.String" and
"Text.ParserCombinators.Parsec.Token" -- the provenance appears at different
levels in the hierarchy. If you're going to shove the package name in there,
it seems simpler to me to just shove it at the front:
Parsec.Text.ParserCombinators.Token. The package mounting scheme might solve
this (though it seems to me that it requires that source for packages be kept
around. I may be wrong).
> (As I already pointed out, there's at least 3 packages called "bianry", >
> which is just confusing.)
On hackage? I only see one with that the exact name "binary".
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
