Robert Greayer wrote:
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).
Yeah, as I said, it's not immediately obvious exactly what the best
solution is. Maybe we just need to get everybody to come up with more
inventive names than just "hashtable" or "binary". (E.g., We have
several parsers already, but they all have distinctive names that are
unlikely to clash. Maybe we just need to do that for everything? IDK.)
(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".
OK, that's interesting. Apparently something has changed. Last time I
looked, there was "binary", "old-binary", "new-binary", "alt-binary" and
so forth. (It seems there is now a "binary-strict", but it's pretty
obvious how that relates to the normal "binary" package.) Obviously,
having this profusion of nearly identical names is just confusing.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
