- Haskell - Haskell.org

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 16 Jan '01

16 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

Re: O'Haskell OOP Polymorphic Functions
by Johan Nordlander 16 Jan '01

16 Jan '01

Ashley Yakeley wrote: > > At 2001-01-16 14:04, Tom Pledger wrote: > > >The subtyping (struct Derived < Base ...) makes the two instances > >overlap, with 'instance TheValue Derived' being strictly more specific > >than 'instance TheValue Base'. If the system preferred the less > >specific one, the more specific one would never be used. > > > >This is quite similar to the way overlapping instances are handled > >when they occur via substitutions for type variables (e.g. 'instance C > >[Char]' is strictly more specific than 'instance C [a]') in > >implementations which support than language extension. > > Subtyping-overlapping is quite different from type-substitution > overlapping. > > Consider: > > struct B > > struct D1 < Base = > a1 :: Int > > struct D2 < Base = > a2 :: Int > > class TheValue a where theValue :: a -> Int > instance TheValue B where theValue _ = 0 > instance TheValue D1 where theValue _ = 1 > instance TheValue D2 where theValue _ = 2 > > struct M < D1,D2 > > m = struct > a1 = 0 > a2 = 0 > > f = theValue m > > What's the value of f? This program is rejected on the grounds that it lacks an instance delaration for TheValue M. Declare one and you will be fine. Or (when the upcoming release becomes available) remove the instance decl for either D1 or D2 and the remaining one will be chosen. -- Johan

1 0

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

16 Jan '01

At 2001-01-16 13:18, Magnus Carlsson wrote: >f1 = Just 3 >f2 = f3 = f4 = Nothing So I've declared b = d, but 'theValue b' and 'theValue d' are different because theValue is looking at the static type of its argument? What's to stop 'instance TheValue Base' applying in 'theValue d'? -- Ashley Yakeley, Seattle WA

1 0

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

16 Jan '01

At 2001-01-16 10:23, Magnus Carlsson wrote: >You can use overloading for the definition of theValue instead: > > class TheValue a where theValue :: a -> Maybe Int > > instance TheValue Base where theValue _ = Nothing > instance TheValue Derived where theValue x = Just (x.value) Doesn't this imply that run-time type information is kept with the structs? Consider: d :: Derived d = struct value = 3 b :: Base b = d idb :: Base -> Base idb x = x f1 = theValue d f2 = theValue b f3 = theValue (idb d) f4 = theValue (idb b) What are the values of f1, f2, f3 & f4? -- Ashley Yakeley, Seattle WA

2 1

ANNOUNCE: GHood (updated pre-release)
by C.Reinke 16 Jan '01

16 Jan '01

Ever wanted to see what your Haskell program is doing?-) ----------------------------------------------------------------- GHood (pre-release, 11 January 2001) "Graphical Hood" -- a Java-based graphical observation event viewer, as a back-end for Andy Gill's Hood (Haskell Object Observation Debugger). Currently, GHood comes in two files: a drop-in replacement for the Hugs98 variant of Hood (only minimal changes, same interface) and a Java class file archive for the graphical viewer itself. To find the two files, please visit my Haskell corner at: http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/#GHood ----------------------------------------------------------------- The GHood pre-release has been updated. The main change (apart from single-stepping through the observation event stream, which you might have been missing in the previous version): GHood can now be used as an applet (requires Java 2/Swing-capable browser or a suitable Java plug-in). This means that GHood animations can now be used to enrich webpages. If you ever wanted to discuss the behaviour of Haskell programs on your webpages, you can now add applets to those pages that visualise and animate the issues you describe. If you never dared to write about program behaviour for lack of illustrations, you might now consider adding such discussions to your webpages. Potential uses: - educators: as part of your functional programming course webpages, - programmers: as part of the description of a clever functional algorithm, or to document problems in a misbehaving functional program - GHood implementors (me;-): show examples of GHood animations online. I would be interested to learn about example problems from practice for which GHood has been found helpful. Please let me know, too, if you create websites that use GHood as an applet. Enjoy, Claus -- Claus Reinke, http://www.cs.ukc.ac.uk/people/staff/cr3/ Computing Lab, University of Kent at Canterbury

1 0