February 2001 - Haskell

tuple component functions
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

S.D.Mechveliani writes: > As Haskell has the standard functions fst, snd to decompose (a,b), > maybe, it worths to provide also > tuple31, tuple31, tuple31, > ... > tuple51, tuple52, tuple53, tuple54, tuple55 > > for the tuples of n = 3,4,5 ? I've found some of these useful, except I named them differently: > fst3 :: (a,b,c) -> a > fst3 (x,_,_) = x > snd3 :: (a,b,c) -> b > snd3 (_,x,_) = x > thd3 :: (a,b,c) -> c > thd3 (_,_,x) = x .... never got around to quadruples etc. I also defined (some of these may be untested): > tripl :: a -> (a,a,a) > tripl x = (x,x,x) > curry3 :: ((a, b, c) -> d) -> a -> b -> c -> d > curry3 f x y z = f (x, y, z) > uncurry3 :: (a -> b -> c -> d) -> ((a, b, c) -> d) > uncurry3 f t = f (fst3 t) (snd3 t) (thd3 t) > applyTriple :: (a -> b, a -> c, a -> d) -> a -> (b,c,d) > applyTriple (f,g,h) x = (f x, g x, h x) > cross3 :: (a -> b, c -> d, e -> f) -> (a,c,e) -> (b,d,f) > cross3 (f,g,h) (x,y,z) = (f x, g y, h z) > mapTriple :: (a -> b) -> (a, a, a) -> (b, b, b) > mapTriple = cross3 . tripl > applyFst3 :: (a -> b) -> (a, c, d) -> (b, c, d) > applyFst3 f = applyTriple (f . fst3, snd3, thd3) > applySnd3 :: (a -> b) -> (c, a, d) -> (c, b, d) > applySnd3 f = applyTriple (fst3, f . snd3, thd3) > applyThd3 :: (a -> b) -> (c, d, a) -> (c, d, b) > applyThd3 f = applyTriple (fst3, snd3, f . thd3) > applyArgs3 :: (a -> b) -> (c -> d) -> (e -> f) -> (b -> d -> f -> g) -> (a -> c -> e -> g) > applyArgs3 af1 af2 af3 f = \x y z -> f (af1 x) (af2 y) (af3 z) > rotl :: (a -> b -> c -> d) -> (b -> c -> a -> d) > rotl f y z x = f x y z > rotr :: (a -> b -> c -> d) -> (c -> a -> b -> d) > rotr f z x y = f x y z > rotl4 :: (a -> b -> c -> d -> e) -> (b -> c -> d -> a -> e) > rotl4 f y z t x = f x y z t > rotr4 :: (a -> b -> c -> d -> e) -> (d -> a -> b -> c -> e) > rotr4 f t x y z = f x y z t Some more combinators (only for pairs so far): > twin :: a -> (a,a) > twin x = (x,x) > swap :: (a,b) -> (b,a) > swap (x,y) = (y,x) -- apply a pair of functions to one argument > applyPair :: (a -> b, a -> c) -> a -> (b, c) > applyPair (f, g) x = (f x, g x) -- apply a pair of functions to a pair > cross :: (a -> b, c -> d) -> (a, c) -> (b, d) > cross (f, g) = applyPair (f . fst, g . snd) -- compose a pair of functions onto one function > dotPair :: (a -> b, a -> c) -> (d -> a) -> (d -> b, d -> c) > dotPair (f, g) h = (f . h, g . h) -- compose a pair of functions onto a pair of functions > dotCross :: (a -> b, c -> d) -> (e -> a, f -> c) -> (e -> b, f -> d) > dotCross (f, g) (h, i) = (f . h, g . i) > mapPair :: (a -> b) -> (a, a) -> (b, b) > mapPair = cross . twin > applyFst :: (a -> b) -> (a, c) -> (b, c) > applyFst f = applyPair (f . fst, snd) > applySnd :: (a -> b) -> (c, a) -> (c, b) > applySnd f = applyPair (fst, f . snd) > applyArgs :: (a -> b) -> (c -> d) -> (b -> d -> e) -> (a -> c -> e) > applyArgs af1 af2 f = \x y -> f (af1 x) (af2 y) > betweenFst :: (a -> b -> c) -> (a, d) -> (b, e) -> c > betweenFst = applyArgs fst fst > betweenSnd :: (a -> b -> c) -> (d, a) -> (e, b) -> c > betweenSnd = applyArgs snd snd I find these combinators useful, and probably other people have their own versions - it would be nice to get them standardised, so we all speak the same language. By standardised, I mean a prominent version that will be adopted by users, not necessarily a committee process. Tim

3 2

ICFP programming contest
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

Michael Hobbs writes: > Just took a look at the results for the ICFP contest. Am I correct in > assuming that "LA" stands for Lennart Augustsson and that "Si^3" stands > for Simon Marlow, Simon Peyton-Jones, Sigbjorn Finne? Is there a URL for the results ? Tim

2 1

CFP: JFP on SAIG
by Walid Taha 08 Jul '01

08 Jul '01

CALL FOR PAPERS A Special Issue of JFP on Semantics, Applications, and Implementation of Program Generation http://cs-www.cs.yale.edu/~taha/saig/jfp.html Program generation has the prospect of being an integral part of a wide range of software development processes. Recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now support program generation and manipulation. These languages can have different goals, use different different implementation techniques, and target different applications. In this context, a PLI workshop dedicated to this theme (SAIG'00) was held this year. Following on from this workshop, a special issue of the Journal of Functional Programming will be devoted to the same theme. Full-length, archival-quality submissions are solicited on topics including both theoretical and practical models and tools for building program generation systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. Contributors to SAIG'00 are encouraged to submit, but submission is open to everyone. Papers will be reviewed as regular JFP submissions, and acceptance in the special issue will be based on relevance to the theme. The special issue also welcomes high-quality survey and position papers that would benefit a wide audience. Accepted papers exceeding the space restrictions will be published as regular JFP papers. Submissions should be sent to the guest editor (address below), with a copy to Nasreen Ahmad (nasreen(a)dcs.gla.ac.uk) Submitted articles should be sent in postscript format, preferably gzipped and uuencoded. In addition, please send, as plain text, title, abstract, and contact information. The submission deadline is February 1st, 2001. For other submission details, please consult an issue of the Journal of Functional Programming or see the Journal's web page at http://www.dcs.gla.ac.uk/jfp/. Guest Editor Editor in Chief Walid Taha Department of Computer Science Philip Wadler Yale University Avaya Labs P.O. Box 208285 700 Mountain Ave, Room 2T-402, New Haven, CT 06520-8285, Murray Hill, NJ 07974-0636, USA. USA. Email: taha(a)cs.yale.edu Email: wadler(a)avaya.com Phone: +1 203 432 6496 Phone: +1 908 582 4004 Fax : +1 203 432 0593 Fax: +1 908 582 5857

1 5

A GUI toolkit looking for a friend
by Simon Peyton-Jones 31 Mar '01

31 Mar '01

Gentle Haskellers This message is to invite offers to complete a promising port of the Clean Object I/O library to Haskell. As you know, there are quite a few GUI toolkits for Haskell, but none of them has become a de-facto standard. One confusing aspect is that there are different "levels": (see http://haskell.org/libraries/#guigs) * Low-level veneers on top of existing libraries. HOpenGL, GTK, TclHaskell, the Win32 library, all fall into this category. They are rich, but hard to use because you have to adopt the programming model of the library, which is usually very imperative. * Very high-level systems, such as Fudgets, Haggis, FranTk. These are rather sophisticated and (esp Fudgets, FranTk) attempt to break with the imperative programming model. But I don't think any of them has been acclaimed as The Right Way To Do It. We're still looking! * Strangely, there are very few "in the middle" systems. One might hope for an interface that was somewhat independent of the low-level library, and somewhat more Haskell friendly, than the low-level veneers, but not as ambitious as the high-level systems. On top of that, some libraries deal in graphical user interfaces (buttons, menus..) and some deal in graphics (pictures, lines, shading). I think we should encourage the development of more "in the middle" systems. One example is Koen Claessen's Yahu system, http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/yahu.html However, there is another functional language that has put years of development into a GUI library: Clean. The Clean Object I/O library is well-documented and the Clean team have had a lot of experience in using it. It runs on both Windows and Mac, but not currently on Unix. http://www.cs.kun.nl/~clean/About_Clean/page_modified/page_modified.html Maybe we should build on their experience! Peter Achten, its author, spent a few weeks in Cambridge, porting the Clean library to Haskell. The results are very promising. The main ideas come over fine, translating unique-types to IO monad actions, and the type structure gets a bit simpler. So what we need now is to complete the port. Peter didn't have time to bring over all the widgets, nor did he have time to clean up the Haskell/C interface. (Clean's FFI is not as well-developed as Haskell's, so the interface can be made much nicer.) The other significant piece of work would be to make it work on Unix, perhaps by re-mapping it to GTK or TkHaskell or something. So the main burden of this message is: Would anyone be interested in completing the port? Fame (if not fortune) await you! The prototype that Peter developed in is the hslibs/ CVS repository, and the GHC team would be happy to work with you to support your work. (The more compiler-independent we can make the library, the better.) Peter Achten is willing to play consultant too. The Clean team are happy for the code to be open source -- indeed, all the hslibs/ code is BSD-licensed. It would not be the work of a moment. There are subtle issues involved (especially involving concurrency), and the design is not complete, so it isn't just boring hacking. So it should fun. Anyone interested? Maybe more than one person could work on it together. [And are there any other "in-the-middle" libraries I've overlooked?] Simon

3 2

RE: FixIO/ Tackling Awkward Squad
by Simon Peyton-Jones 31 Mar '01

31 Mar '01

| Dear Haskellers, | After enjoying "Tackling the Awkward Squad" (Simon | Peyton Jones), I wonder what other elements of the | squad can be tackled in a simular way? Right now I am | thinking about FixIO. This little bugger seems to show | up in a lot of code! Can we give it an operational | semantics a la Tackling the awkward squad? I am quite | stumped on this one, so i wont event post my meager | attempts, but rather hope someone brighter then me | will :) We need to add a new Value "FixIO N"... I'd be inclined to do it like this: fixIO m = do { v <- newEmptyMVar ; result <- m (unsafePerformIO (takeMVar v)) ; putMVar v result ; return result } Of course, this just begs the question of what exactly unsafePerformIO might mean, and we can only really answer that when we give an operational semantics to the functional part of the language as well as the imperative part. But perhaps the meaning of fixIO becomes clearer with the above. (Of course an implementation is free to implement it some other way too.) Simon

6 12

Disjoint type classes
by Jose Emilio Labra Gayo 05 Mar '01

05 Mar '01

I have a large program where I would like to include disjoint type classes into a new type class. My problem can be reduced to the following example (taken from [1]): > class Num a => Dividable a > where dividedBy :: a -> a -> a > instance Fractional a => Dividable a where > dividedBy = (/) > instance Integral a => Dividable a where > dividedBy = div Which doesn't work because Haskell doesn't detect that "Integral" and "Fractional" are disjoint. Is there a way to implement these type classes with current Haskell implementations? [1] K. Glynn, M. Sulzmann, P.J. Stuckey Type Classes and Constraint Handling Rules http://www.cs.mu.oz.au/tr_submit/test/cover_db/mu_TR_2000_7.html Best regards, Jose Labra

2 1

Re: Proposal: module namespaces.
by Christian Brolin 28 Feb '01

28 Feb '01

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? > Why is e.g. Parser.f not sufficient as a unique symbol for > Text.Xml.Parser.f? Well, what if you also have Text.Html.Parser.f? > You really need the full thing. Of course, see above. > > I would also like to import modules using relative addresses, e.g. the > > file: > > My/Small/Test/Xml/Parser.hs > > contains: > > import .Lexer -- Relative path to the module: My.Small.Test.Xml.Lexer > > import ..Data -- Relative path to the module: My.Small.Test.Xml.Parser.Data > > import Text.ParserCombinators.HuttonMeijer -- Absolute address > > I'm sorry, I don't entirely follow what the differing numbers of > initial dots mean. They are used to specify relative addresses to other modules. Relative addresses is a very important concept, but You missed it in your proposal. The dots was just my suggestion of a syntax for relative addresses. One dot: Relative to the parent of this module. Two dots: Relative to this module. E.g. module A.B.C.D1 where import A.B.C.D1.E1 import A.B.C.D1.E1.F import A.B.C.D1.E2 import A.B.C.D2 import X.Y.Z would be the same as (delete 'A.B.C'): module A.B.C.D1 where import .D1.E1 import .D1.E1.F import .D1.E2 import .D2 import X.Y.Z would be the same as (delete 'D1'): module A.B.C.D1 where import ..E1 import ..E1.F import ..E2 import .D2 import X.Y.Z Move the package of modules (A.B.C.*) to (Std.AAA.BBB.CCC.*) and rename D1 to DDD: module Std.AAA.BBB.CCC.DDD where import ..E1 import ..E1.F import ..E2 import .D2 import X.Y.Z The only thing that needs to be changed is the module clause. Which of course would be unnecessary if the module clause was dropped. > > When the world realize that this is the XML parser, they won't accept > > the name and I refuse to change my implementation. The only thing that > > is needed to rename (an unused) module hierarchy is to move it. > > If you refuse to change your implementation, someone else will change > it for you! You can't have closed standards. It is not necessary to modify the modules if the module system supports relative addresses!!! The steering wheel of my car is positioned relative to my car, so it is NOT necessary to change that position when I move the car. -- Christian Brolin

4 6

Re: Proposal: module namespaces.
by Ashley Yakeley 27 Feb '01

27 Feb '01

At 2001-02-26 09:59, Malcolm Wallace wrote: >Proposal 2 >---------- >Adopt a standardised namespace layout to help those looking for or >writing libraries, I'm a big fan of the Java reversed DNS style. Whatever, I think it's important that anyone with a domain name should be able to obtain a unique namespace without any further bureaucracy. In fact, whatever you decide it's likely to happen anyway, since people will decide that for instance "Com.Microsoft.Research.MyModule" is unlikely to clash with anyone outside the appropriate domains and subdivisions. I'm assuming that module name components have enforced capitalisation, like all other Haskell identifiers. >and a "Std" namespace prefix for genuinely >standard libraries. (These are two different things.) Eeesh, let's hope ICANN doesn't register a 'std' TLD. I would prefer "Standard" for this reason and also because the abbreviation seems pretty pointless. >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. Do you have any kind of guarantees of copyright openness in mind? In Java, everything under java.* is supposed to be owned by Sun. Will it be standard practice for versions of Standard be included with Haskell compilers? Could the Prelude make use of Standard? Could Standard become an alternative to the Prelude? If answers to these last three are all "no", an alternative would be to put it under "Org.Haskell.Standard". -- Ashley Yakeley, Seattle WA

1 0

Proposal: module namespaces.
by Malcolm Wallace 27 Feb '01

27 Feb '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

4 4

CALL FOR REGISTRATION: ESSLLI 2001 (Helsinki, Finland)
by Ahti Pietarinen 27 Feb '01

27 Feb '01

- Apologies for multiple copies - If you want to receive detailed information including the ESSLLI 2001 poster please send us (esslli(a)helsinki.fi) your complete address. !!!!!!!!!!!!!!!!!!!!!!!!!! CALL FOR REGISTRATION !!!!!!!!!!!!!!!!!!!!!!!! 13th European Summer School in Logic, Language and Information ESSLLI 2001 University of Helsinki FINLAND August 13-24, 2001 http://www.helsinki.fi/esslli ** Early registration deadline: 30 April 2001 ** GENERAL INFORMATION The 13th European Summer School in Logic, Language and Information (ESSLLI'01) will take place at the University of Helsinki, Helsinki, Finland, during two weeks in August, from August 13 until 24. The ESSLLI Summer Schools are organised under the auspices of FoLLI (http://www.folli.uva.nl) the European Association for Logic, Language and Information. The main focus of the European Summer Schools is the interface between linguistics, logic and computation. Foundational, introductory and advanced courses, workshops and special events cover a wide variety of topics within six areas of interest: * Logic * Language * Computation * Logic and Language * Logic and Computation * Language and Computation The number of courses offered is over 50. Previous summer schools have been highly successful, attracting around 500 students from Europe and elsewhere. The school has developed into an important meeting place and forum for discussion for students, researchers and IT professionals interested in the interdisciplinary study of Logic, Language and Information. In addition to courses, workshops and evening lectures there will be a Student Session and a social program. COURSE PROGRAM The full scientific program can be found at our home page. Evening Lectures are given by * Edward L. Keenan "Spinoza Lecture" (UCLA) * Yannis Moschovakis "Vienna Circle Lecture" (UCLA) * Keith Devlin (Saint Mary's College, California) * Jaakko Hintikka (Boston & Helsinki) * Bonnie Webber (Edinburgh) WORKSHOPS There are currently several Calls for Workshop Papers. Please visit our home page for detailed information. TRAVEL AND LOCAL INFORMATION By plane to Helsinki airport and then a 30-minute nonstop coach or taxi service to the main railway station. From the railway station 5-minute walk to the university. A gateway between East and West, the city of Helsinki (population 1M) is the capital of Finland and one of the nine European Cities of Culture for the millennium. It is located at the warm and sunny south coast of Finland, within an easy reach from the main airports worldwide, or inside Europe by car or regular train services, or using the ferry services operating within the Baltic region. The scientific program of ESSLLI'01 will be held in the University Main Building, located on the University city campus at the very centre of Helsinki. The accommodation will be arranged at the University Summer Hotel close to the city campus. The accommodation includes sauna and breakfast. REGISTRATION ESSLLI 2001 is now open for registration. The registration fee for students is just ECU 190, for scholars ECU 350, and for industrial affiliates ECU 600. Please visit our home page for the on-line registration form and detailed instructions. ** Early registration deadline: 30 April 2001 ** All participants will get a letter of invitation to facilitate the procedure of getting a visa. GRANTS There will be a limited number of grants available, to partially support travel, registration and accommodation for ESSLLI'01. Instructions for grant applications are found at our home page. ** Deadline for grant applications: 31 May 2001 ** SPEACIAL EVENTS During ESSLLI, special "Finnish for Foreigners" language courses will be organised, as well as various excursions and other social events. Helsinki Summer School (http://summerschool.helsinki.fi) will offer special deals for ESSLLI participants who want to choose some of their courses and earn credits. SATELLITE EVENTS The Association for the Mathematics of Language will stage its annual meeting (MoL7) in conjunction with ESSLLI'01 in Helsinki, in the weekend preceding ESSLLI in August 10-12, and the affiliated Formal Grammar Conference will be held in conjunction with the Mathematics of Language Conference. ESSLLI participants are entitled to reduced registration fees. PROGRAM COMMITTEE Marcus Kracht (Chair) <kracht(a)math.fu-berlin.de> Jouko Väänänen (Logic) Bonnie Webber (Language) Claude Kirchner (Computation) Michael Moortgat (Logic and Language) Steffen Hölldobler (Computation and Logic) Claire Gardent (Language and Computation) CONTACT ADDRESSES Please visit ESSLLI'01 Home Page http://www.helsinki.fi/esslli for updated information concerning the scientific program, registration fees and procedures, grants, accommodation, satellite events, and other practical information. For further enquiries concerning ESSLLI'01, please contact the Organising Committee at <esslli(a)helsinki.fi>, or write to ESSLLI 2001 Secretariat C/o Department of Philosophy P.O. Box 24 00014 Helsinki University Finland ESSLLI'01 is organised by the Department of Philosophy (coordinator), the Department of Mathematics, the Department of General Linguistics, and the Department of Computer Science at the University of Helsinki. ORGANISING COMMITTEE Gabriel Sandu (Chair, Philosophy) Jouko Väänänen (Mathematics) Fred Karlsson (General Linguistics) Ilkka Niiniluoto (Philosophy) Martti Tienari (Computer Science) Ahti Pietarinen (Philosophy, secretariat) <esslli(a)helsinki.fi> ================================================================================

1 0