On Fri, Jul 15, 2005 at 10:48:04AM +0200, Henning Thielemann wrote:
On Thu, 14 Jul 2005, Andrew Pimlott wrote:
2) enshrining one-type-per-module in the naming convention is not IMO justified, and may prove limiting;
Other languages like Modula-3 and Oberon do it with great success. The limit in Haskell is that most compilers don't conform to the Haskell 98 report which allows mutually recursive modules. But I think the compilers should allow them instead of forcing users to put many type and class definitions into one module.
Even given an ideal implementation (I would add that it should allow multiple modules in one file), I don't find one type or class per module preferable. I think it's usually a false division. For one, there will be functions that operate on multiple types, so where do you put those? For another, the user will probably have to import several modules, and remember which which module contains a function that operates on multiple types. That said, my point is not that this style of choosing module boundaries is always wrong, or that you can't answer the above objections in many cases. It's that you shouldn't build a general naming convention around it, especially one that some will find confusing or awkward, and when it has only small practical advantages (and some disadvantages). But I'm not going to push this any further: If people still like it, it's not that big a deal to me. :-)
Vector.T is just the consequence of removing type-related prefixes from all identifiers.
I interpreted the style as removing anything that is redundant in the context of the module. In math, when you're talking about vector spaces, you say "add" and "multiply", but you don't say "thing" or "one"--you still say "vector".
If you stick to qualified naming you only need to import the module once. Otherwise you must import a module twice.
import LinearAlgebra.Vector (Vector) import qualified LinearAlgebra.Vector as V
I don't think I understand what you're saying with this example. If you export the type as "Vector", the user could "import LinearAlgebra.Vector as Vector" and then refer to both "Vector" and "Vector.add". Or "import LinearAlgebra.Vector as V" and then refer to "Vector" (or "V.Vector") and "V.Add". Andrew