January 2001 - Haskell

RE: Finding primes using a primes map with Haskell and Hugs98
by Simon Peyton-Jones 17 Jan '01

17 Jan '01

| Another way to do this is to compute the final array directly, | instead of computing successive versions of the array: | | import Array | primes n = [ i | i <- [2 ..n], not (primesMap ! i)] where | primesMap = accumArray (||) False (2,n) multList | multList = [(m,True) | j <- [2 .. n `div` 2], m <- | multiples j] | multiples j = takeWhile (n>=) [k*j | k <- [2..]] This style is definitely the way to go. Haskell does badly if you update an array one index at a time. Remember that arrays can be recursive. Here's a definition of Fibonacci for example; you can probably adapt it for primes fibs :: Int -> Array Int Int -- If a = fibs n, then a!i is fib(i), for i<=n. fibs n = a where a = array (1,n) ([(1,1),(2,1)] ++ [(i,a!(i-1) + a!(i-2) | i <- [3..n]]) -- Notice that a is recursive Simon

4 3

Re: O'Haskell OOP Polymorphic Functions
by Ashley Yakeley 17 Jan '01

17 Jan '01

OK, I've figured it out. In this O'Haskell statement, > struct Derived < Base = > value :: Int ...Derived is not, in fact, a subtype of Base. Derived and Base are disjoint types, but an implicit map of type "Derived -> Base" has been defined. -- Ashley Yakeley, Seattle WA

1 0

FME2001 Call for Participation
by Pamela Zave 17 Jan '01

17 Jan '01

To learn about Formal Methods Europe 2001, to be held in Berlin 12-16 March, please visit the symposium website at: www.informatik.hu-berlin.de/top/fme2001 Registration and hotel reservation are available on the website. The deadline for early registration is 9 February. Please register now so we can look forward to seeing you in Berlin!

1 0

Research assistant positions in Bremen
by Till Mossakowski 17 Jan '01

17 Jan '01

The following two research assistant positions are available at the University of Bremen, Germany. The Bremen Institute of Safe Systems in the Center for Computing Technologies at the University of Bremen hosts the research projects "Multi-logic systems as a basis for heterogeneous specification and development" (MULTIPLE) and "Algebraic specification + functional programming = environment for formal software development" (HasCASL) funded by the Deutsche Forschungsgemeinschaft (DFG). Within the framework of each of these projects, one position in the working group of Prof. Dr. Krieg-Brückner is to be immediately filled for at least two years (additional option for another two years), subject to availability of funds: Research Assistant Verg. Gr. IIa BAT (full time) In addition to successful university studies in computer science, experience and skills in functional programming (e.g. Haskell, ML) are expected. Familiarity with at least one of formal specification methods (like CoFI/CASL), theorem proving or category theory is desirable. Applicants with a PhD are welcome. However, there will also be the oppurtunity to prepare a PhD thesis in connection with the research project. In case of essentially equal qualification in the subject and personal suitability, severely handicapped applicants will be preferred. The University of Bremen intends to increase the share of women in scientific activities and does therefore strongly encourage women to apply for these positions. More detailed information about the projects can be found under http://www.tzi.de/cofi/projects/multiple.html http://www.tzi.de/cofi/projects/hascasl.html Please address your application with the usual documents and the reference number A164/00 (MULTIPLE) resp. A165/00 (HasCASL) before 01.02.2001 to: UNIVERSITÄT BREMEN Prof. Dr. B. Krieg-Brückner Fachbereich 3 Postfach 33 04 40 28334 Bremen e-Mail: cofi(a)tzi.de -- Till Mossakowski Phone: +49-421-218-4683, monday: +49-4252-1859 Dept. of Computer Science Fax: +49-421-218-3054 University of Bremen EMail: till(a)tzi.de P.O.Box 330440, D-28334 Bremen WWW: http://www.tzi.de/~till

1 0

RE: An Haskell compilation server
by Simon Marlow 17 Jan '01

17 Jan '01

> How about turning ghc into a compilation server ? > It would run as a daemon waiting for network > connections, retrieve source files (through the > same network socket, or nfs, or cvs, ...), compile > them locally, and send back the result. > This would prevent having to reload the compiler > for each file - as the executable is quite large, this > may already speed up compilation a bit. > It could also cache .hi files, which would remove > the need to parse them. > It would also enable distributed compilation, on a > properly configured site. That would be easy to do > with hmake. > There are many details to think about (should the > parsing be made locally by the driver, or remotely...). > How does it sound ? Funny you should say that. The next version of GHC (5.00 - to be released soon) will have hmake-like functionality enabling it to compile multiple modules without exiting, caching .hi files between compilations. This speeds up compilations by as much as a factor of 2 for large programs. Cheers, Simon

2 1

Re: An Haskell compilation server
by Michael Hanus 17 Jan '01

17 Jan '01

Sebastien Carlier wrote: > How about turning ghc into a compilation server ? > It would run as a daemon waiting for network > connections, retrieve source files (through the > same network socket, or nfs, or cvs, ...), compile > them locally, and send back the result. > This would prevent having to reload the compiler > for each file - as the executable is quite large, this > may already speed up compilation a bit. > It could also cache .hi files, which would remove > the need to parse them. > It would also enable distributed compilation, on a > properly configured site. That would be easy to do > with hmake. > There are many details to think about (should the > parsing be made locally by the driver, or remotely...). > How does it sound ? This is a good idea. We have done this for our Curry implementation (http://www.informatik.uni-kiel.de/~pakcs) (Curry is an extension of Haskell to deal with logic and concurrent programming features) and made very good experiences with it, in particular, there was a considerably speed-up when recompiling larger applications. Michael

1 0

Re: An Haskell compilation server
by Sebastien Carlier 17 Jan '01

17 Jan '01

John Meacham wrote: > the benefits may not be as great as you suppose, modern operating > systems keep a buffer cache which contains all recently used data in > memory including executables, if your machine is not memory limited > (such that the OS would have to throw away your ghc pages to make room > for something else) then probably most of ghc's pages will already be > resident in RAM for subsequent runs. Even if the executable file is cached, there is still dynamic linking to be done. Are pages of the executable memory mapped, or does the binary file format get in the way and force the code segment to be copied ? (this is architecture dependent, it would be interesting to find out for the most common ones) Even if the loading time is only slightly shorter, I think more interesting speed-ups can be achieved by removing any work which is duplicated by the compiler at each run. This probably includes parsing .hi files. Where does the compiler spend most of its time ? > if you wish to distribute the make over several machines that can be > done easily by using 'ssh' or 'rsh' to start jobs on remote machines > and share the results via nfs or smb or some other remote filesystem. This would be very difficult without analysing the dependencies between modules, I think the compilation has to be globally coordinated. Also, you probably want to use only compilers for the sate architecture, although you might have compilation servers for several. They should register themselves to a central coordination server, which could also balance the workload between servers. I do not think this would be efficiently done with shell scripts. > there are also certain versions of make such as 'pmake' which > specialize in distributing building across clusters of machines... > modifying 'hmake' to distribute the builds automagically might be > an interesting and useful project though. This would indeed be nice for universities and large sites. And rebuilding ghc would be a breeze :) > -- > -------------------------------------------------------------- > John Meacham http://www.ugcs.caltech.edu/~john/ > California Institute of Technology, Alum. john(a)foo.net > --------------------------------------------------------------

1 0

An Haskell compilation server
by Sebastien Carlier 17 Jan '01

17 Jan '01

How about turning ghc into a compilation server ? It would run as a daemon waiting for network connections, retrieve source files (through the same network socket, or nfs, or cvs, ...), compile them locally, and send back the result. This would prevent having to reload the compiler for each file - as the executable is quite large, this may already speed up compilation a bit. It could also cache .hi files, which would remove the need to parse them. It would also enable distributed compilation, on a properly configured site. That would be easy to do with hmake. There are many details to think about (should the parsing be made locally by the driver, or remotely...). How does it sound ? -- Sebastien Carlier EPITA, Posse42

2 1

A Regular Expression Library for Haskell
by Shlomi Fish 17 Jan '01

17 Jan '01

Does such a thing exists? Is it part of Happy? Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)techie.com The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.

2 1

RE: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
by Simon Marlow 16 Jan '01

16 Jan '01

> What should be the preferred way of marking correspondence to source > positions after some preprocessing? > > Here is what is currently supported: > > | {-# LINE 100 "Foo.hs #-} | # > 100 "Foo.hs" > ------------------------+------------------------------+------ > ---------- > Released ghc, no -cpp | understand | error > Released ghc, with -cpp | understand | understand > Developed ghc | understand | understand > hbc | understand (ignore filename) | > understand (warning) > Hugs | ignore | error > Released nhc98 | error | understand > Developed nhc98 | ignore | understand > > I would choose LINE pragma. In this case nhc98 should be taught > about it. CPP generates the '# 100 "Foo.hs"' form, which is why GHC understands them. We used to convert these into LINE pragmas automatically before feeding to the compiler, but this required an extra script and preprocessing step (hscpp), so we don't do that anymore. The preferred way should presumably be LINE pragmas. Cheers, Simon

2 1