March 2003 - Haskell - Haskell.org

clueless GHCI user wishes to load QuickCheck
by nr＠eecs.harvard.edu 13 Mar '03

13 Mar '03

Can anyone help me figure out how to load QuickCheck into GHCI? QuickCheck is included in my Debian package, but my attempts at loading it are bootless: Prelude> :load QuickCheck can't find module `QuickCheck' Prelude> :load util/QuickCheck can't find module `util/QuickCheck' Prelude> :info syntax: `:i <thing-you-want-info-about>' Prelude> :load util/QuickCheck.hi can't find module `util/QuickCheck.hi' Prelude> :load /usr/lib/ghc-5.02.2/imports/util/QuickCheck.hi can't find module `/usr/lib/ghc-5.02.2/imports/util/QuickCheck.hi' Prelude> :load /usr/lib/ghc-5.02.2/imports/util/QuickCheck can't find module `/usr/lib/ghc-5.02.2/imports/util/QuickCheck' Prelude> Any advice, anyone? Norman

6 8

ANNOUNCE: buddha 0.5
by Bernard James POPE 13 Mar '03

13 Mar '03

Announcing the release of buddha 0.5 ------------------------------------ buddha is a declarative debugger for Haskell 98 http://www.cs.mu.oz.au/~bjpop/buddha/ What's new in this release: - a browsing facility - (optional) re-evaluation to improve space usage - better support for exceptions - accurate line numbers - minor interface improvements - many more interesting examples - and of course a swag of bug fixes Requirements: - ghc 5.04 or greater with libraries built for profiling (not tested with 5.04.3 yet) - a unix-ish environment (not tested on windows) Cheers, Bernie

1 0

Learning Haskell, update
by Arjan van IJzendoorn 13 Mar '03

13 Mar '03

Hi all, I've removed the frequently asked questions box at the bottom. It was unused. Fritz Ruehr made a nice Learning Haskell logo. Thank you, Fritz! NHC is compilable under Windows now, so the remark "no windows version" has been removed. Is there someone who wants to make a more decent language comparison table? If not, I'm thinking of removing it. Many things are said about it already in the comp.lang.functional FAQ. Greetings, Arjan

1 0

ANNOUNCE: hugs98.NET March 2003 snapshot
by Sigbjorn Finne 13 Mar '03

13 Mar '03

A new version of Hugs98.NET is now available, sporting the following: * A version of the popular Haskell interpreter, Hugs98 (http://haskell.org/hugs) targetted at the Microsoft .NET platform. * .NET interop integrated via the Haskell FFI. * Support for wrapping up Haskell functions as .NET classes / delegators, providing any .NET language with the ability to call and use Haskell. The distribution comes with documentation and examples demonstrating how to access and interact with .NET -- all available via the Hugs98.NET homepage: http://galois.com/~sof/hugs98.net/ Feedback, contributions, suggestions for improvements, bug reports etc. are most welcome -- please e-mail these to the author: sof(a)galois.com ----------------------------------------------------------------------- The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, the Yale Haskell Group, and the Oregon Graduate Institute of Science and Technology, 1994-2001, All rights reserved. It is distributed as free software under the license in the file "License", which is included in the distribution. The .NET extension is Copyright (c) Sigbjorn Finne, 2002-2003, All rights reserved. It is distributed as free software under the license in the file "License.net", which is included in the distribution. -----------------------------------------------------------------------

1 0

recursive modules in Haskell
by Elke Kasimir 12 Mar '03

12 Mar '03

Hi all! I've just got one of the rare chances to do a somewhat bigger piece of software development in Haskell. After having set up a design (with much use of multi-parameter-classes) I was very excited. However, to extent that implementation proceeded I had to recognize many unforeseen implementation dependencies between instance. A standard situation is: file A.hs: instance Foo A f :: -- implementation requires A and B to be an instance of Foo file B.hs: instance Foo B f :: -- implementation requires A and B to be an instance of Foo The mutual dependencies increase if one uses class constraints to enforce semantic wellformedness, that is if one writes given Bar A => class Foo A whenever this makes sense from the view of the application logic - as I did. No Problem at all for Haskell, but a problem for certain often-used Haskell compilers and interpreters... Factoring out "the common part" does not work in examples like above, so the only way is to collapse everything, and to reduce class constraints as much as is possible - something which hurts deep inside! That the problems appear step-by-step in the course of implementation or even debugging, adds to the pain. So I have put onto my personal Haskell whish-list that certain compilers and interpreters shall either ultimately converged against the language they intend to support, or else provide some suitable alternative. Thinking in the first direction, a precompiler appears before my inner eye which is able to collapse mutually dependent modules into one bigger module. Even if this led to incorrect line numbers in error messages and the like, I would definitely use such a precompiler. A step in the second direction was a slight modification of Haskell such that instance declaration and instance implementation can be provided in separate modules. Elke. -- Elke Kasimir EsPresto AG ----------------------------------------------------------------- - Software Development- Breite Str. 30-31 Tel/Fax: +49-30-90 226-750/-760 10178 Berlin/Germany

2 1

RE: Problem with hierarchical libraries.
by Simon Marlow 12 Mar '03

12 Mar '03

> > IIRC, something very similar was suggested a while back on > the libraries > > list, except that the form beginning with a dot was the > relative module > > name (actually I think I prefer it that way). > > this seems exactly the opposite of what all file systems do. i know > lateral thinking is great, but why do we have to be backwards > all the time? Because it seems strange to have to add the prefix dot to all of our existing imports ('import Prelude' becomes 'import .Prelude'). Besides, I like the idea that the prefix dot is an indication that the current module name has been omitted. > > Personally, I've been using the hierarchical module names > for a while > > and I really don't mind writing out the whole name each > time. It means > > you have less context to think about when reading the source. > oh come on :-) most of the time you don't get to see the > module name > at all -- you have to keep scrolling to the top of the file. > virtually > every editor can tell you what is the name of the file you are > editing... (:f in vim). and tools like haddoc can display > the name of > the module anyways. I think you misunderstand me - my point was that currently, an import declaration means the same regardless of what the current module name is. With relative imports, that's not true any more (but you're right that the editor usually helps by showing the filename). It's a minor point I grant you, but simplicity at the expense of a bit of extra typing is sometimes a good thing. > > This arises because the meaning of a module is defined > independently of > > the mapping between modules and filenames. > > the meaning of modules can still be independent of the > mapping between > modules and filesnames. all that has to be specified is how > to compute this mapping. And that's exactly what we don't want to do (IMO). Filesystems are too different - what about filesystems that don't have directories? What if I want to store my source code in a database or on the web? What about non-case-sensitive filesystems, or ones with restrictions on the length of filenames? > and one has to do that anyways, even if the haskell > report pretends that this can be ommited. Yes, but the point is that it is done by the compiler, not the language specification, so compilers are free to implement different policies, and the spec doesn't have to acquire any platform-specific warts. The mapping between filenames and module names in GHC is rather complicated, see recent discussions on glasgow-haskell-users(a)haskell.org. The mapping in Hugs is different - more liberal in some ways, but less complicated because of the lack of interface files. [snip] > in fact if one decides to ignore this mapping, > all that the "hirarchical modules" proposal does is allow one > to write "." in a module name. Bingo :-) Cheers, Simon

1 0

MoChArt-03 submission deadline extended to March 17
by Charles Pecheur 12 Mar '03

12 Mar '03

[Apologies if you receive more than one copy of this message. -- The Organizers.] ===================================================================== **************************************************** *** EXTENDED Submission deadline: March 17, 2003 *** **************************************************** CALL FOR PAPERS & PARTICIPATION *************************************** SECOND WORKSHOP ON MODEL CHECKING AND ARTIFICIAL INTELLIGENCE (MoChArt-03) August 10, 2003, Acapulco, Mexico IJCAI-03 Workshop Program http://mochart03.na.infn.it/ ===================================================================== Model checking (MC) is the name given to the process of determining whether or not a formula of some logic is satisfied by a model for the logic. Model checking is limited by its exponential complexity with respect to the size of the system being verified. Nevertheless, MC procedures for many classes of models and logics of interest have been efficiently automated and successfully applied to a broad range of real-size applications in the last decade. These recent advances have lead to a growth of interest in the use of the technology in Artificial Intelligence (AI). In the meantime, state space exploration is a central aspect of AI, and the AI community has a long and impressive line of research in developing and improving search algorithms over very large state spaces under a broad range of assumptions. MC researchers are showing a growing interest in this vast body of knowledge, as a way to mitigate the state-space explosion problem. Under a slightly different perspective there is growing interest in the use of model checking techniques for verifying and validating AI applications (as opposed to inside these applications themselves). This is becoming a critical issue, as AI techniques are increasingly considered for safety-critical applications such as space missions. AI software typically features unconventional architectures and requirements that ask for specific verification solutions. These solutions will only emerge from a sustained dialogue between the AI and V&V communities, through forums such as this one. The purpose of the Second MoChArt workshop is therefore to bring together researchers with an interest in both MC and AI. The goals are to tease out common themes and differences, identify common problems and their solutions, share experiences with the applicability of techniques from one field to problems from the other, and to identify the key issues to be addressed in increasing the convergence between MC and AI. The workshop will welcome submissions on all ideas, research, experiments and tools that relate to both MC and AI fields. Topics of interest include: - Foundations - Comparisons between MC and AI problems, approaches and algorithms. - Model checking for combined modal/temporal logics - Model checking for logics of common sense reasoning - Model checking approaches to AI - Planning via model checking - Model checking for multi-agent systems - Model checking for diagnosis - Model checking for games - Using concurrency models in AI (Process Algebras, Petri Nets, Statecharts,...) - AI approaches to model checking - AI approaches to the state explosion problem - Heuristics for model checking - AI approaches to automatic abstraction - Model checking for verification of AI systems - Requirements/specifications/properties for AI systems - Automated verification of AI systems - Model checking of multi-agent systems - Model checking of model-based systems - Model checking of knowledge-based systems - Tools related to any of these topics - Case studies related to any of these topics SUBMISSION The workshop notes will include original material. Archived material will also be considered for presentation but will not appear in the proceedings. Shorter papers are encouraged, particularly those exposing novel ideas or work in progress. Authors are invited to submit papers (11pt, letter or A4, no more than 12 pages long) in PostScript format or Adobe PDF by March 7, 2003 to the following e-mail address: mochart03(a)na.infn.it. The first page of each submission should carry the contact details of a nominated contact person, including email address. PARTICIPATION Participation will be by invitation. Potentially interested participants must submit a *short* position statement, indicating the reasons for their interest in the topics of the workshop to the e-mail address mochart03(a)na.infn.it, by April 1, 2003 IMPORTANT DATES AND DEADLINES - Deadline for the submission of papers: March 17, 2003. - Notification of acceptance/rejection of papers: March 30, 2003. - Deadline for the posotion statement: April 1, 2003 - Deadline for the receipt of camera-ready papers: May 15, 2003. ORGANIZING COMMITEE Massimo Benerecetti Dipartimento di Scienze Fisiche Universita di Napoli ``Federico II'' Via Cintia, Complesso Monte S. Angelo I-80126 Napoli, Italy e-mail: bene(a)na.infn.it http://people.na.infn.it/~bene/ Charles Pecheur RIACS / ASE Group NASA Ames Research Center, M/S 269-2 Moffett Field, CA 94035, U.S.A. e-mail: pecheur(a)ptolemy.arc.nasa.gov http://ase.arc.nasa.gov/pecheur ===================================================================== _______________________________________________________________________ Charles Pecheur RIACS / ASE Group NASA Ames Research Center, M/S 269-2 Bldg N-269, Rm 230 Moffett Field, CA 94035, U.S.A. http://ase.arc.nasa.gov/pecheur Phone : +1-650-604-3588 mailto:pecheur@ptolemy.arc.nasa.gov Fax : +1-650-604-3594 Home phone : +1-650-967-5918

1 0

Conway's Life
by Abraham Egnor 12 Mar '03

12 Mar '03

I'm implementing Conway's Life in Haskell; my basic implementation is attached. Does anyone have suggestions for optimizations (or alternative representations)? It's interesting to note that the difference between this with no ghc optimization, -O, and -O2 is pretty striking; on my computer, it's about seven seconds, two seconds, and one second runtime, respectively. Abe module Main where import Data.Array.IArray import Data.Array.Unboxed import Data.Ix import System.Random type Grid = UArray (Int, Int) Int randomGrid :: (RandomGen g) => g -> Int -> Grid randomGrid g s = listArray b $ map (\x -> if x then 1 else 0) $ take (rangeSize b) $ randoms g where b = ((0,0),(s-1,s-1)) getCell :: Grid -> (Int, Int) -> Int getCell g c@(x,y) = if (x < xmin) || (x > xmax) || (y < ymin) || (y >= ymax) then 0 else g ! c where ((xmin, ymin), (xmax, ymax)) = bounds g update :: Grid -> Grid update g = array (bounds g) $ map aux $ assocs g where aux (c@(x,y),e) = let around = map (getCell g) $ filter (/= (x,y)) $ range ((x-1,y-1),(x+1,y+1)) in (c,rule (sum around) e) rule 2 e = e rule 3 e = 1 rule _ _ = 0 printGrid :: Grid -> IO () printGrid g = do let ((xmin, ymin), (xmax, ymax)) = bounds g mapM_ aux $ map (\x -> range ((x,ymin),(x,ymax))) [xmin..xmax] putStrLn "" where aux ixs = do mapM_ (putStr . show) $ map (g!) ixs putStrLn "" main :: IO () main = printGrid $ (iterate update (randomGrid (mkStdGen 0) 50)) !! 100

1 1

Re: Problem with hierarchical libraries.
by Iavor S. Diatchki 11 Mar '03

11 Mar '03

hi, sorry for moving this back to the haskell mailing list, but i think the module system is part of the language and is not a library. Simon Marlow wrote: > [ moved to libraries(a)haskell.org ] > > >>why not fix the design to take this into account? one can >>have two ways >>to refer to modules - relative and absolute (just like in the file >>system, which years of experience show works pretty well). >> >>import .Test.A -- refers to an absolute path >> -- (relative to a user specified root) >> -- i.e. $HS_PATH/Test/A.hs >>import Test.A -- is a path relative to the location of >> -- the current module, i.e. >> -- [location of module]/Test/A.hs > > > IIRC, something very similar was suggested a while back on the libraries > list, except that the form beginning with a dot was the relative module > name (actually I think I prefer it that way). this seems exactly the opposite of what all file systems do. i know lateral thinking is great, but why do we have to be backwards all the time? > Personally, I've been using the hierarchical module names for a while > and I really don't mind writing out the whole name each time. It means > you have less context to think about when reading the source. oh come on :-) most of the time you don't get to see the module name at all -- you have to keep scrolling to the top of the file. virtually every editor can tell you what is the name of the file you are editing... (:f in vim). and tools like haddoc can display the name of the module anyways. >>i also have another question about the hirarchical modules >>design -- why >>does one have to duplicate the path to a particular file >>inside the file >>itself? i.e. what is the point of the module name within the file? >>it seems that all haskell implementations assume that the module name >>and file name are the same (and this seems perfectly reasonable), and >>with the hirarchical name space this is even more the case. and for >>example C programers never specify the name of the current >>file within >>the file. why do we want to do it? > > > This arises because the meaning of a module is defined independently of > the mapping between modules and filenames. the meaning of modules can still be independent of the mapping between modules and filesnames. all that has to be specified is how to compute this mapping. and one has to do that anyways, even if the haskell report pretends that this can be ommited. in fact this is exactly what the initial poster was asking. this whole issue about realtive/absoulte paths is part of specifying the mapping between module names and file names. in fact if one decides to ignore this mapping, all that the "hirarchical modules" proposal does is allow one to write "." in a module name. if one wants to keep modules and file names comletely independent it seems that one should introduce some notion of a "project" or something, which specifies the above mentioned mapping. however i am not sure that the additional flexibility of such an approach would be useful, and i would be perfectly happy with a single fixed way to compute the maping between modules and files. > I agree that this leads to some redundancy, and it can be annoying that > moving modules from one place in the hierarchy to another requires > editing the source. > > Building knowledge of the filesystem into the spec is the wrong thing to > do, given that filesystems tend to have platform-specific differences > (eg. single quote is allowed in a module name - is it allowed in a > filename? on which operating systems?). making them the same seems wrong. the one being an abstraction of the other does not seem all that bad. for the particular problem you raise there are at least two more or less obvious choices: * disallow single quotes in module names (but not necessarily module name aliases) * say what should single quote be mapped to in the file system (e.g. _) i like the first one better. what does GHC do in this situation? bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

1 0

ANNOUNCE: GHC vesrion 5.04.3 released
by Simon Marlow 11 Mar '03

11 Mar '03

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 5.04.3 ============================================================== We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.04.3. This is a bugfix-only release. For all the changes since 5.02.3, see the release notes: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-5-04.htm l How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in InstallShield form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (MacOS/X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

1 0