- Libraries - Haskell.org

RE: Summary of progress
by Simon Marlow 12 Mar '01

12 Mar '01

> On Sun, Mar 11, 2001 at 01:28:38PM +0000, Malcolm Wallace wrote: > > > > Proposal 2b: adopt a "Std." namespace for libraries that > > are common to all implementations. > > > > * There is little agreement here. Simon M, Manuel, and > > others have expressed their doubts that it is workable. > > No-one has defended the idea except me. But then Simon > > posted a hierarchy layout proposal in which "Haskell." > > seemed to take the role of "Std.". So I'm a bit > > confused. I'd like to see some more discussion about > > this. Oh, here's another thought: if we standardise the locations of as many libraries as possible, then it becomes reasonable for a compiler to do this: $ nhc foo.hs nhc: module `Foo' imports `Lang.Concurrent', which is a Haskell language extension not supported by this compiler. $ ghc bar.hs ghc: module `Bar' imports `Graphics.UI.Gtk' which is not installed. It may be obtained from "http://www.foo.bar.com". Cheers, Simon

2 1

Alternative hierarchy proposal.
by Simon Marlow 12 Mar '01

12 Mar '01

Here's my attempt at a library hierarchy. No ASCII art - I've just used indentation to indicate nesting. I've merged my initial sketch with Malcolm's proposal, so some of the subtrees are identical, but I've changed names here and there (eg. Interface --> Console, Encoding --> Codec or Digest). The leaves are all real modules, some of which already exist in some form in hslibs. The non-leaf nodes may also be imported as Haskell modules: more about this later. Note: I haven't addressed the issue of what parts of the tree should be "standard" or not - I've just populated the tree. I've placed most of the tree under "Haskell.". This is roughly equivalent to Malcolm's "Std.", except that my requirements for entry into Haskell are much slacker :-) I'm assuming there is a separate mechanism for deciding which libraries are standard, and a mechansim by which a library specification can be evolved into a standard. I've included the Haskell 98 standard libraries, placed in their correct places in the tree. No doubt the interfaces to these libraries, and even their existence in the new scheme, is now up for debate. The prelude is Haskell.Prelude, and is probably just a re-export of various other parts of the tree. In practice the implementation will be system-specific. I've noticed that the tree gets fairly deep in places ("Haskell.Lang.Foreign.Marshal.Array" ??) so a modification to the language extension to allow shortening of names might be in order, something like Java's "import java.lang.*". System specific libraries live in GHC.*, NHC.*, Hugs.* etc. One problem with this scheme which I haven't quite resolved, is what happens when you import a non-leaf node. I've identified four possible meanings, each of which is useful in certain cases: (a) bring into scope everything below that node (might be nice for eg. Foreign, Foreign.Ptr etc.) (b) bring into scope some things below the node (eg. Foreign exports everything except C.*) (b) get a default module of some description (eg. Pretty vs. Pretty.HughesPJ) (c) import a unique module (eg. Array vs. Array.IArray) Note that no special compiler support is required for importing a non-leaf node, and all of the above schemes can co-exist. Ok, here we go. I've marked optional libraries with (opt), the rest are assumed to have portable implementations, or be implementable in a portable way, for any Haskell compiler with FFI support. Cheers, Simon ------------------------------------------------------------------------ -- Haskell Prelude -- Haskell98 Prelude -- mostly just re-exports other parts of the tree. Lang -- "language support" Foreign Ptr -- should be in Data??? StablePtr -- should be in System.GC??? ForeignPtr -- should be in System.GC??? Storable Marshal Alloc Array Errors Utils C Types Errors Strings Array -- Haskell 98 Array library IArray -- (opt) GHC's overloaded arr libs MArray -- (opt) IOArray -- mutable arrays in the IO/ST monads STArray Monad -- Haskell 98 Monad library ST LazyST Either -- monad libraries State etc. Exception -- (opt) Generics -- (opt) Memo -- (opt) Unique ShowFunctions -- sounds more impressive than it is Dynamic System IO -- H98 + IOExts - IOArray - IORef Directory Select GC Weak -- (opt) StableName -- (opt) Console GetOpt Readline Time -- H98 + extensions Locale CPUTime -- split H98 "System" (too generic) into: Exit Environment (Args, Prog, Env ...) Numeric DSP FFT FIR Noise Oscillator Gaussian Source -- hslibs/hssource AbsSyn Lexer Parser Pretty Concurrent -- as hslibs/concurrent CVar -- (some of these could also go in "Data"). Chan MVar Merge QSem QSemN SampleVar Semaphore Parallel -- as hslibs/concurrent/Parallel Strategies Net -- won't need to be optional (will use FFI only) Socket -- redesign (merge w/ SocketPrim) BSD -- remove?? URI CGI -- one in hslibs is ok? Text Regex -- previously RegexString PackedString -- previously Regex (remove?) Pretty -- default (HughesPJ?) HughesPJ Wadler ... HTML -- HTML combinator lib XML Combinators Parse Pretty Types Parse -- no default Parsec Hutton_Meijer ... Posix -- redesigned, use FFI only Database SQL ODBC Debug Observe Quickcheck Trace Graphics UI Drawing Format -- perhaps should be under Data.Encoding Data Bits Char -- H98 Complex -- H98 Either -- H98 Int Maybe -- H98 List -- H98 PackedString Ratio -- H98 Word IORef STRef Binary -- Haskell binary I/O Digest MD5 ... -- others (CRC ?) Codec Bzip2 Gzip MPEG -- or perhaps Audio/Graphics.Format.MPEG? Structures Trees AVL RedBlack BTree Queue Bankers FIFO Collection Graphs FiniteMap Set Edison -- (opt, uses multi-param type classes) GHC Primitives UnboxedTypes ... -------------------------------------

5 11

Summary of progress
by Malcolm Wallace 11 Mar '01

11 Mar '01

I think this would be a useful point to stand back and summarise where we seem to have reached in discussing my original proposals (posted on 26th February). Shout if you think I've got something wrong here, missed something important out, or if I mark something as 'decided' that you really want to discuss some more. Proposal 1: introduce nested namespaces. * Everyone seems to agree that this is a good idea. * No-one has objected to using the normal dot (.) as the namespace separator character, nor has anyone suggested a different character. * The idea of an implicit import-renaming clause import A.B.C.D [ as D ] received no objections, although some people would like there to be additional implicit renamings import A.B.C.D [ as C.D ] import A.B.C.D [ as B.C.D ] * The original proposal allowed only absolute naming of modules. Others have proposed an additional mechanism for relative naming of modules within the current (or parent) namespace. I don't see agreement here yet. Proposal 2a: adopt a standardised namespace layout * Again, people seem to agree broadly that this is an essential thing. Discussions are still in progress about the detail of the layout, and I expect these to continue. Proposal 2b: adopt a "Std." namespace for libraries that are common to all implementations. * There is little agreement here. Simon M, Manuel, and others have expressed their doubts that it is workable. No-one has defended the idea except me. But then Simon posted a hierarchy layout proposal in which "Haskell." seemed to take the role of "Std.". So I'm a bit confused. I'd like to see some more discussion about this. Proposal 3: develop a social process for adding new libraries to the "standard" set. * Well, this list is the starting point, so there's not much more to be said on that. * The set of criteria by which we as a community might judge whether a library is recognised as "standard" have not really received any comment. Other issues: * We have mentioned briefly that "standard" libraries should be available in all Haskell systems. But Manuel pointed out that many libraries will be developed independently of particular compilers - and so they should be distributed separately, to ensure they remain up-to-date with external software (e.g. C libraries). I think we need to think carefully about how to manage this process. A single repository of compiler-independent and build-system-independent library code would be a good start. But it won't be sufficient. Regards, Malcolm

3 2

RE: Alternative hierarchy proposal.
by Simon Marlow 09 Mar '01

09 Mar '01

> * Win32 > Dunno what would go in here. Possibly OS.Win32 or something would > be better regardless to kep the top level branches to a minimum? Win32 is a complete Haskell binding to the Win32 API, including, but not limited to, the graphics and user interface API. It doesn't really belong under Graphics, but perhaps if we had a subtree for OS APIs, it could go next to POSIX. > In SM: > * System > THis is equivalent to Haskell.Plus.Unsafe I think. Personally I > think this is a good idea as it is not implementable in Haskell. > I'm not sure the Plus distinction is necessary though. Actually I intended the System hierarchy to contain libraries that interact with the outside world and the Haskell runtime system. All IO-related stuff (except for graphics) belongs in there. I wouldn't object strongly to moving "unsafe" functions into a hierarchy of their own, but IMO unsafePerformIO belongs with the IO monad. > * Source > This appears to be parsers etc for Haskell code, and I don't see > why it should be here rather than Text.Haskell next to HTML, XML > etc Text.Haskell sounds good. But this also contains a definition of an abstract syntax datatype for Haskell, and it may in the future contain reference implementations of a static analyser and type checker for Haskell, so perhaps keeping it in a hierarchy of its own would be better. > * Concurrent > I don't know anything about this but it looks fair enough > * Parallel > As the comment is "as hslibs/concurrent/Parallel" should it not go > under Concurrent? Hmm. The parallel API is separate from the Concurrent API, and there exist systems that implement one or the other, as well as both. I think they're separate. Parallel is small, though, and perhaps doesn't warrant its own top-level category. Lang.Parallel and Lang.Concurrent would be fine. > * Prelude > MW has Haskell.Language.CoreSyntax which I think makes more sense I don't understand - Prelude wasn't intended to be the same as Haskell.Language.CoreSyntax, it's just the Haskell98 Prelude that we have now. Perhaps Lang.Prelude would be a better place for it, though. > * GHC > Probably better under Lang.CompilerSpecific.GHC? Maybe. We're going to be writing the Lang.CompilerSpecific.GHC prefix a lot while implementing libraries, though. Remember most of this hierarchy is under Haskell, but I put the compiler specific parts outside of the Haskell hierarchy. It's not very clear from the diagram, sorry. Haskell.{Lang,System,Text etc.} GHC.{UnboxedTypes etc.} > There's also the Std vs Non-std top branch debate. I agree with the > non-std myself. > > The SM trees in general seem a bit better thought out to me too, e.g. > I don't think Bits or MD5 belong under Data.Encoding. > > To summarise I think something like: > > Algebra: As MW > Concurrent: As SM plus Parallel > Data: As SM > Database: As SM and MW > Debug: As SM and MW > Graphics: As MW (more detailed than SM) > Lang: As SM, plus CompilerSpecific.*, Prelude, { System.* > from SM plus POSIX plus BSD } Do you mean System under Lang, or as a top-level category (I think top-level is better, BTW). > Net: As SM (plus a POSIX module if POSIX talks about this) > Numeric: As SM and MW > OSSpecific: As explained > Text: As SM and MW > User: your(a)email.address gets address.email.your.* off of this As a general comment on the subject of hierarchy layouts, it's clear to me that we can never have a "perfect" hierarchy, since some modules will always belong in more than one place and others won't belong anywhere in particular. I think the best we can do is try to come up with something that is as consistent as possible, not too deeply nested, will extend gracefully as we add new libraries, and won't require reorganising as the language changes. Cheers, Simon

3 2

RE: Module versions
by Simon Peyton-Jones 09 Mar '01

09 Mar '01

| In either case, the actual layout in filespace can be handled | with symbolic links, e.g. | | Graphics/UI/Gtk.hs -- symbolic link to Gtk_1_2.hs | Graphics/UI/Gtk_1_2.hs -- the real module | | At the moment, nhc98 will flag a warning (for instance) that | | module Gtk is called Gtk_1_2 in its interface file | | but this is harmless. I don't know how GHC currently copes | with this kind of module/filename conflict? GHC also complains if the filename and module name differ. Except for Main. Simon

1 0

RE: Proposal: module namespaces.
by Simon Marlow 09 Mar '01

09 Mar '01

[ leaving out haskell(a)haskell.org from the recipient list ] > Malcolm Wallace wrote: > > > > Christian writes: > > > What about the module declaration? Should it be: > > > module Text.Xml.Parser where ... > > > or just > > > module Parser where ... -- located in Text/Xml/Parser.hs? > > > > The former. The reason is that a compiler needs to > generate a unique > > linker symbol for each defined function. If the full module name is > > not encoded in the source file, you will need to add a commandline > > option to the compiler, which is the wrong way to go in my opinion. > > What?? The compiler knows the full name of the module without > the module > clause. If it didn't do that, it can't find the modules to > compile! Does > the compiler opens every file on the Internet to check > whether it is the > file to compile? How does the compiler find the file to compile in the > first place? What should the command line option you mentioned do? The compiler finds the file because you tell it what the filename is. That's the way it works now, and if I understand correctly Malcolm isn't suggesting we change that (and I agree). There are really two issues here: * how do you find a module to compile in the first place (not an issue for interpreters, only for batch compilers). Just run the compiler giving it the filename. * when you import a module, how does the compiler find the interface (or source, in the case of an interpreter) for the target. My feeling is that this happens with a small extension to the current scheme: at the moment, the compilers all have a list of search paths in which to find interfaces/sources. The change is that to find a module A.B.C you search in D/A/B/ (for each D in the search path) rather than just D. GHC's package mechanism will actually work pretty much unchanged with this scheme, I believe. Cheers, Simon

5 4

module namespaces
by Johannes Waldmann 08 Mar '01

08 Mar '01

I think the namespace proposal wants to be strictly upward compatible, therefore it's perhaps not the right time to discuss this ... but still I think the question "why should the source text of a module contain its name?" wants an answer. Even if we stick to module headers, I don't really like the idea of `module Fully.Qualified.Name where ..' The proposal mentions the analogy to Java. My knowledge of that is minimal, but in Java, they have `package Foo.Bar.Frobs' (full name required) and `class Frobble' (only last name there). So, a Haskell module corresponds to what? I understand the argument "the compiler needs to generate unique names in the object files" but this is a matter of implementation, about which the programmer (at least theoretically) should not care. I think the underlying design decision here is: how far should the user of a set of modules expect that he can move their source/interface/object files around, and still compile them/link against them correctly. The present proposal seems to imply: not at all. This is a conservative answer. It is easy to implement, and guarantees some consistency. Is it too restrictive? But assume this policy is adopted. Then I am not allowed to move (precompiled) modules around physically. That's why I want some means of renaming them (during importing), and as I wrote earlier, not only for single modules (`import Foo as Bar') but also for complete hierarchies (`import Leipzig.Standard as Standard') A potential problem is that the root of some hierarchy perhaps is just a directory (that contains subdirs and modules) but not itself a module. One would need to write a dummy module that just (qualified-)imports and re-exports all submodules. But this had to be extended whenever a submodule is added. This doesn't feel right. (On the other hand, the libFoo.a file had to be rebuilt anyway on such an occasion.) This leads to another question - during the linking stage: when should the compilation manager look for a single object file, and when should it expect an archive? Anyway I think even the most restricitve form of hierarchical module names would be very helpful. I certainly would start using it. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

2 1

Re: Proposal: module namespaces.
by Christian Brolin 08 Mar '01

08 Mar '01

Marcin 'Qrczak' Kowalczyk wrote: > > Wed, 28 Feb 2001 17:31:13 +0100, Christian Brolin <Christian.Brolin(a)carmen.se> pisze: > > > This dilemma comes from the fact that you don't tell the compiler what > > module to compile, but just give it some Haskell code. You should always > > compile the module with: > > compile A.B.C.D, i.e. tell the compiler which module you want to > > compile, and the compiler will find the source code. > > It must work well with Makefiles. I can imagine that it's doable in > this case, but generally it should work to specify the filename too. If it isn't double, it is not possible to automatically find the files of imported modules! > > > Instead I would let the current directory play as an implicit module > > > root. I.e. you can refer to D2 as D2, and in this case you cannot refer > > > to the global module D2 if it exists (but you can refer to D2.Other > > > if D2 is a global directory and there is no local directory named D2). > > > > I think this is very confusing! And restrictive. > > It may be confusing (but not more than having your own function > called sortBy). sortBy? > It's not restrictive. When you want to use a module, don't provide > a module of the same name - *that* would be confusing when used > (if allowed). You can't import a child module without mention the name of the importing module. > It has an advantage that it's simpler. The compiler has a set of > roots and there is just one form of module paths. I think it is better to explicitly distinguish between absolute and relative addresses of imported modules. It would be easier for a reader (e.g. a compiler) to find the modules. Absolutely imported modules are found by looking in the set of roots, while the others are found relative to the position of the current module. -- Christian Brolin

2 1

Proposal: module namespaces.
by Malcolm Wallace 08 Mar '01

08 Mar '01

This is an annoucement of a new mailing list, and a proposal for three things: * An extended mechanism for module namespaces in Haskell. * A "standard" namespace for new libraries, common across all systems. * A social process for adding new libraries to the "standard" set. A formatted version of this proposal appears on the web at http://www.cs.york.ac.uk/fp/libraries/ The new mailing list is for the discussion of these proposals. Please subscribe if you are interested. Follow-ups set accordingly. Mailing list details -------------------- libraries(a)haskell.org The purpose for this new list is to: (a) discuss an extension to Haskell to provide a richer module namespace, (b) discuss how to partition this namespace and populate it with libraries, (c) discuss how to provide a consistent set of libraries for all compilers, and the setting up of a common library repository. To subscribe: http://haskell.org/mailman/listinfo/libraries/ Introduction ------------ Everyone agrees that Haskell needs good, useful, libraries: lots of them, well-specified, well-implemented, well-documented. A problem is that the current "Standard Libraries" defined by the Haskell'98 Report number only about a dozen. But there are actually many more libraries out there: some are in GHC's hslibs collection, others are linked from haskell.org, even more are used only by their original author and have no public distribution. What is more, there is no Haskell Committee. There is no-one to decide which candidate libraries are worthy to be added to the "Standard" set. This stifles the possible distribution of great libraries, because no-one knows how to get /my/ library "accepted". Furthermore, the existing libraries that people distribute from their own websites often run into problems when used alongside other people's libraries. A library usually consists of several modules, but often the constituent modules have simple names that can easily clash with modules from another library package. This leads people to ad hoc solutions such as prefixing all their modules with a cryptic identifier e.g. HsParse XmlParse HOGLParse THIHParse Just counting the libraries currently available from GHC's hslibs, and haskell.org's links, there are currently over 200 separate modules in semi-"standard" use. As more libraries are written, the possibility of clashes can only increase. Related to this problem, although not identical, is the difficulty of finding a library that provides exactly the functionality you need to help you write a specific application program. How do you go about searching through 200+ modules for interesting-looking datatypes and signatures, starting only from the module names? My View ------- My view is that many of these problems are rooted in Haskell's restriction to a flat module namespace. If we can address that issue adequately, then I believe that many of the difficulties surrounding the provision of good libraries for Haskell will simply fall away. Proposal 1 ---------- Introduce nested namespaces for modules. The key concept here is to map the module namespace into a hierarchical directory-like structure. I propose using the dot as a separator, analogous to Java's usage for namespaces. So for instance, the four example module names above using cryptic prefixes could perhaps be more clearly named Haskell.Language.Parse Text.Xml.Parse Graphics.Drawing.HOpenGL.ConfigFile.Parse TypeSystem.Parse Naming proceeds from the most general category on the left, through more specific subdivisions towards the right. For most compilers and interpreters, this extended module namespace maps directly to a directory/file structure in which the modules are stored. Storing unrelated modules in separate directories (and related modules in the same directory) is a useful and common practice when engineering large systems. (But note that, just as Haskell'98 does not *insist* that modules live in files of the same name, this proposal does not insist on it either. However, we expect most tools to use the close correspondance to their advantage.) There are several issues arising from the particular proposal here. * This is a surface change to the module naming convention. It does not introduce nested /definition/ of modules. * The syntax I propose (a dot separator) is familiar from other languages such as Java, but could in principle be something else, for instance a prime ' or underscore _ or centred dot · or something different again. * Of the choices of separator, dot requires a change to the Haskell'98 lexical syntax, allowing modid -> qconid where currently the syntax is modid -> conid * The use of qualified imports becomes more verbose: for instance import qualified XmlParse ... XmlParse.element f ... becomes import qualified Text.Xml.Parse ... Text.Xml.Parse.element f ... However, I propose that every import have an implicit "as" clause to use as an abbreviation, so in import qualified Text.Xml.Parse [ as Parse ] the clause "as Parse" would be implicit, unless overridden by the programmer with her own "as" clause. The implicit "as" clause always uses the final subdivision of the module name. So for instance, either the fully-qualified or abbreviated-qualified names Text.Xml.Parse.element Parse.element would be accepted and have the same referent, but a partial qualification like Xml.Parse.element would not be accepted. * Another consequence of using the dot as the module namespace separator is that it steals one extremely rare construction from Haskell'98: A.B.C.D in Haskell'98 means the composition of constructor D from module C, with constructor B from module A: (.) A.B C.D No-one so far thinks this is any great loss, and if you really want to say the latter, you still can by simply inserting spaces: A.B . C.D Further down this document, I give more motivation and a rationale for this proposal of nested namespaces. But first, two other proposals which rest on the first one. Proposal 2 ---------- Adopt a standardised namespace layout to help those looking for or writing libraries, and a "Std" namespace prefix for genuinely standard libraries. (These are two different things.) The hslibs collection of modules is a great starting place for finding common libraries that could become standards. I propose that we adopt a "standardised" namespace hierarchy, based on the current hslibs layout, into which Haskell programmers can plug their own libraries relatively easily (whether they intend to release them or not). The aim is to make it clear where to place a new module, and where to search for a possible existing module. For instance, in ASCII art, here is a small part of a suggested tree. + Data + Structures + Trees + AVL | | | + RedBlack | | | | | + Queue + Bankers | | + FIFO | + Encoding + Binary | + MD5 | + Graphics + UI + Gtk + Widget | | | + Pane | | | + Text | | | | | + FranTk | | | + Drawing + HOpenGL + .... | | + Vector | | | + Format + Jpeg | + PPM + Haskell + .... | A fuller proposed layout appears on the web at http://www.cs.york.ac.uk/fp/libraries/layout.html In addition to a standardised hierarchy layout, I propose a truly Standard-with-a-capital-S namespace. A separate discussion is needed on what exactly would consitute "Standard" quality, but by analogy with Java where everything beginning "java." is sanctioned by Sun, I propose that every module name beginning "Std." is in some sense sanctioned by the whole Haskell community. So for instance, an experimental, or not-quite-complete, library could be called Text.Xml but only a guaranteed-to-be-stable, complete, library could be called Std.Text.Xml The implication of the Std. namespace is that all such "standard" libraries will be distributed with all Haskell systems. In other words, you can rely on a standard library always being there, and always having the same interface on all systems. Proposal 3 ---------- Develop a process by which candidate libraries can be proposed to enter the Std namespace. Since Haskell'98 is fixed, and there is no longer a Haskell Committee, there is no official body capable of deciding new standards for libraries. However, we do have a Haskell community which will use or not use libraries, depending on their quality. So libraries will become standards by a de-facto process, rather than de-jure. Apart from the Haskell compiler implementers, we wanted a means to encourage the whole community to be involved in recognising de facto "standard" libraries. The mailing list 'libraries(a)haskell.org' is one contribution. We hope this will work on the same model as the FFI mailing list, which has been pretty successful at allowing a community of designers and implementers to explore their FFI needs and solidify a design that is common across at least three Haskell systems. On top of this discussion however, some final decisions will have to be made on which libraries achieve entry to the "Std." namespace. The Haskell implementers have collectively proposed a ruling troika, one representing each of the three main Haskell systems (Hugs,ghc,nhc98). These are Simon Marlow, representing ghc, and current keeper of the hslibs collection; Malcolm Wallace, representing nhc98; and Andy Gill, representing Hugs users. Some obvious criteria for entry to the "Std." namespace would be: * The interface is stable and unlikely to change significantly; * The library is written in pure Haskell'98. This criterion is likely to be the most contentious, so perhaps a better idea would be that ... * ... an implementation exists for at least the three Haskell systems Hugs, ghc, and nhc98; * The library is already in current use, so bugs in its coding and design have been ironed out; * The Haskell community recognises it as solving a common task, or encapsulating a common programming idiom. These suggested criteria need some discussion and improvement. After the initial period of deciding what belongs in the "Std." namespace, I would expect any further candidate libraries that are proposed for standardisation to spend some time in another part of the namespace hierarchy whilst they gain stability and common acceptance, before being moved to "Std.". Rationale and Motivation for Proposal 1 (nested namespaces) ----------------------------------------------------------- Scenario 1 ---------- Imagine you have just written a new library of, say, Pretty-printing combinators. You want to release it to the Haskell public. So what do you call it? module Pretty -- already taken (several times) module UU_Pretty -- also taken module PrettyLib -- already exists as well Ok, so lacking any further inspiration, you end up deciding to call it module MyPretty -- ! Surely there must be a better solution. Of course there is - namespaces. Let's classify libraries that do similar jobs together: module Text.PrettyPrinter.Hughes -- the original Hughes design module Text.PrettyPrinter.HughesPJ -- later modified by Simon PJ module Text.PrettyPrinter.UU -- the Utrecht design module Text.PrettyPrinter.Chitil -- Olaf's new design These are exactly the same Pretty libs as before, but named more sensibly. It is still clear that each is a pretty-printing library, but it is also clear that they are different. Incidentally, have you ever tried to write your own module called Pretty? You may have discovered with GHC (which has a Pretty already in the hslibs collection), that you get strange errors. This is because sometimes the compiler can be confused into reading one Pretty.hi interface file (i.e. yours), yet linking the other Pretty.o object file (i.e. from hslibs), ending in a core dump. With proper module namespaces, this confusion should never happen again. Scenario 2 ---------- You are writing a complex library that has a couple of layers of abstraction. For some users, you want to expose just a small high-level set of types and functions. Other users will need more detailed access to lower-level stuff. With namespaces, you can use the directory-like structure to make these kinds of access explicit. For instance, imagine a socket library: module Network.Socket It exports an /abstract/ type Socket for ordinary users - they only need to know its name. More advanced hackers however can play with the details of the type, because you also have: module Network.Socket.Types which exports the Socket type non-abstractly i.e. Socket(..). And of course this abstraction is easy for the library-writer to manage, because the implementation of the more abstract layer simply imports and re-exports a careful selection of the more detailed layers. Don't forget that, in terms of the actual filesystem layout, it is perfectly OK to have e.g. file Network/Socket.hs dir NetWork/Socket file Network/Socket/Types.hs Scenario 3 ---------- You are managing a software engineering project. Several people are working more-or-less independently on different sections of the program. To avoid mistakes with files, you give each one a separate directory to place their code in. But in Haskell'98 this is not enough to ensure that they invent module names that do not clash with other developers' modules. So you insist that everyone also uses a prefix-naming scheme for each appropriate sub-task. For instance, here is a sketch of the layout of the Galois Connection team's entry in the ICFP 2000 programming contest: dir CSG -- constructive solid geometry file CSG/CSG.hs file CSG/CSGConstruct.hs file CSG/CSGGeometry.hs file CSG/CSGInterval.hs dir Fran -- Fran-style animation file Fran/FranLite.hs file Fran/FranCSG.hs dir GML -- interpreter for little language file GML/GMLData.hs file GML/GMLParse.hs file GML/GMLPrimitives.hs So now the problem is that to actually build the software, you need to write a Makefile that descends into these directories. Or maybe you use 'hmake' like so: hmake examples/chess.hs -ICSG -IFran -IGML -IRayTrace -package text Note how many sub-directories you must remember to add to the command line (this applies equally for compiler options in Makefiles). Note also the inconsistency between compiling and linking /my/ modules, against using and linking a "standard" hslibs module from package text. Isn't there a simpler way? Yes. Namespaces. Prefix naming is no longer needed inside directories, because the directory name is /part/ of the module name: file CSG.hs -- re-exports everything from the CSG dir dir CSG file CSG/Construct.hs file CSG/Geometry.hs file CSG/Interval.hs dir Fran file Fran/Lite.hs file Fran/CSG.hs -- does not conflict with top-level CSG.hs dir GML file GML/Data.hs file GML/Parse.hs file GML/Primitives.hs And now, the commandline to 'hmake' (or compiler options in a Makefile) becomes simply: hmake examples/chess.hs -I. You only need to specify the root of the module tree (-I.), and all modules in all subdirectories can be found via their full namespace path as used in the source files. Note also that, whereas previously we needed to specify a package for whatever hslibs modules were used, now the compiler/hmake already knows the root of the installed hslibs tree and can use the same mechanism to find and link "standard" modules as for user modules. >From this example it should be clear that the use of module namespaces is of benefit to ordinary programs that may never become public, quite aside from any benefits we expect to derive in managing publically-distributed library code. What now? --------- Ok, so that's my proposal. The implementers of some of the main Haskell systems have seen a presentation of these ideas, and seemed to like them. Namespaces are already implemented in nhc98 (v1.02) and hmake (v2.02) if you want to play with them. I expect some discussion to refine this proposal on the 'libraries(a)haskell.org' list, to which everyone interested is invited. Once we have nailed down the precise design, we need to get matching implementations in all systems. I have rashly volunteered to implement the lexical/parsing/module-search changes in any Haskell system that no-one else volunteers for (probably ghc, Hugs, possibly hbc). But after that we will still have many more decisions to take about individual libraries, precise naming, build systems, and so on, not to mention actually writing the libraries. Get involved. Contribute. Regards, Malcolm

8 15

qualified exports?
by Johannes Waldmann 05 Mar '01

05 Mar '01

While thinking of top-level modules for libraries (packages), I thought it would be uesful if the module could export indentifiers from submodules, but with their qualified names. The effect would be that after module Top ( module Foo , module Bar ) where import qualified Foo import qualified Bar one could just write `import Top' and then use the names `Foo.frobs' etc. What does the languages standard say about the above example? Section 5.2.5 only mentions "The set of all entities brought into scope from a module m by one or more unqualified import declarations ..." Best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

1 0