Do you know any document pointing out the rationale behind this decision about modules taken by the Haskell designers? Thanks. -Damodar On Sat, Sep 15, 2012 at 9:30 PM, Karl Voelker wrote:

On Fri, Sep 14, 2012 at 6:23 PM, Christopher Howard wrote:

...

import qualified Plant as P

P.Fruit.Raspberry.jam

Short answer: P.Fruit.Raspberry.jam would work if you said:

import qualified Plant.Fruit.Raspberry as P.Fruit.Raspberry

Long answer:

You can't have exactly what you want because the Haskell module namespace isn't exactly heirarchical. Here's an excerpt from the Haskell 98 report [1]:

"The name-space for modules themselves is flat, with each module being associated with a unique module name (which are Haskell identifiers beginning with a capital letter; i.e. modid)."

Notice that this doesn't allow for dots in module names. A commonly-provided language extension allowed dots in module names, and compilers took these dots as a signal to look for a module's source at a particular place in the directory tree, but the semantics of the language didn't have a heirarchy of modules.

Things haven't changed much in Haskell 2010, other than the existing use of dots being formalized [2]:

"Module names can be thought of as being arranged in a hierarchy in which appending a new component creates a child of the original module name. For example, the module Control.Monad.ST is a child of the Control.Monad sub-hierarchy. This is purely a convention, however, and not part of the language definition; in this report a modid is treated as a single identifier occupying a flat namespace."

In your code snippet, P.Fruit.Raspberry doesn't work because although P refers to the same module as Plant, there isn't anything "inside" P (or Plant) called Fruit.Raspberry.

-Karl

[1] http://www.haskell.org/onlinereport/modules.html [2] http://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-980005

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

A feature being "more complicated" for the users to use or for the implementers to implement cannot be the SOLE reason for that feature to be discarded. If we consider implementation concerns, then we can see that the Haskell designers have included many features that are certainly candidates deserving the title: "very much complicated"; e.g. various constructs from category theory, or support for lazy evaluation, or features being targeted for the "Data Parallel Haskell" and so on In particular, I am interested in knowing whether this feature is in direct conflict with any other features the Haskell has. - Damodar On Sun, Sep 16, 2012 at 5:50 PM, Edward Z. Yang wrote:

Excerpts from damodar kulkarni's message of Sun Sep 16 12:37:41 +0200 2012:

...

Do you know any document pointing out the rationale behind this decision about modules taken by the Haskell designers?

While I don't know about the rationale behind this particular decision, Haskell's module system is purposely quite simple. Languages like ML have more complicated module systems which allow the sort of things that you mentioned (and more!) but while they are more expressive they are also more complicated.

Edward