- Haskell - Haskell.org

Functional Programming Languages in Education disappeared
by Olaf Chitil 12 Dec '01

12 Dec '01

Christopher Milton informed me that the link from haskell.org to http://www.cs.kun.nl/fple/, the pages on Functional Programming Languages in Education is broken. In fact, the pages seem to have disappeared completely. I think that this is a pity. I believe the pages have not been updated already for a few years. I suppose the maintainers didn't get much feedback from users and hence finally gave up. I wonder if the maintainers would like to comment on this. Didn't the pages have quite a collection of teaching materials? Maybe there are volunteers who would keep this site going? Ciao, Olaf -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767

1 0

RE: Another question about sharing
by Simon Marlow 12 Dec '01

12 Dec '01

> > You can't rely on adding dummy arguments to cause re-evaluation: > > full-laziness (enabled when optimisation is on in GHC) will do the > > opposite transformation. > > Well in this case, you may find it harder to claim that the full > laziness transformation constitutes an `optimisation'. Maybe the > GHC manual should have a section on "Flags for worsening the space > behaviour of programs". :-) > > Seriously, would it be difficult to detect when performing this > `optimisation' would introduce a CAF and perhaps back it out > appropriately? The problem isn't restricted to CAFs - full laziness always trades space for time. We found that it can be a large win in some cases: if repeated computation is replaced by sharing in an inner loop, then the gains can be dramatic. We didn't meet any cases where it caused space problems, so you get it by default[1] when optimisation is turned on in GHC. You can always disable it with -fno-full-laziness. Cheers, Simon [1] Actually what you get is almost-full-laziness: GHC won't split adjacent lambda abstractions if it finds it can float an expression past some of the lambdas but not all.

2 1

ANN: GHC 5.02.1 RPMs including xlib and HGL packages
by Manuel M. T. Chakravarty 12 Dec '01

12 Dec '01

The following might be of special interest to people who are using Paul Hudak's Haskell textbook for teaching and or study and would like to run the SOE graphics examples with GHC - or if you simply want to have an X-based graphics library for an application. GHC's source distribution contains the two library packages `xlib' and `HGL' (Alastair Reid's Haskell Graphics Library) as part of hslibs, which are not by default built and installed. For our local teaching needs at the University of New South Wales, we have produced a patched version of GHC 5.02.1 that includes the aforementioned libraries in a working form. Haskell modules can be compiled or linked against these libraries, by providing the command line options `-package xlib' and `-package HGL', respectively (or you can specify them using the :s command in the interpreter). RPM packages for x86 GNU/Linux based on glibc 2.2 (eg, RedHat 7.x) containing GHC 5.02.1 including the xlib and HGL packages are available as ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.02.1-graphics.1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.02.1-graphics.1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-doc-5.02.1-graphics.1.i386.rpm with the source RPM at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.02.1-graphics.1.src.rpm The source RPM contains a patched source tar ball and build instructions in the form of an RPM .spec that may be used to build the packages for other Linux distributions and on other Unix systems. (NB: GreenCard need not be installed to build this package, as a throw-away version of GreenCard is included in the tar ball - ie, it is used in the build process, but not installed.) Cheers, Manuel

1 0

haxml
by David Smallwood 12 Dec '01

12 Dec '01

Does anyone know of a mirror site where I can download the latest version of HaXml. (Connection to York is - and has been for a while - apparently down: ftp://ftp.cs.york.ac.uk/pub/haskell/HaXml/HaXml-1.02.tar.gz, that is) Many thanks d. -- David Smallwood Dept. of Computing Science De Montfort University The Gateway Leicester LE1 9BH, UK drs(a)dmu.ac.uk

2 1

Layout rule (again)
by Ian Lynagh 11 Dec '01

11 Dec '01

I'm afraid it doesn't seem to be quite right yet :-( Consider instance Foo Maybe where foo = 5 => {4}instance Foo Maybe where {4}foo = 5 => {instance Foo Maybe where {}}foo = 5 The second {4} has meant there is no <4> to cause an implicit semicolon to be inserted. This can be fixed by changing L ({n}:ts) (m:ms) = { : (L ts (n:m:ms)) if n > m, (Note 1) = { : } : (L ts (m:ms)) otherwise to L ({n}:ts) (m:ms) = { : (L ts (n:m:ms)) if n > m, (Note 1) = { : } : (L (<n>:ts) (m:ms)) otherwise Thanks Ian, having a bad day, predominantly due to the layout rule :-(

1 0

gcd 0 0
by George Russell 11 Dec '01

11 Dec '01

S.D.Mechveliani wrote > Does the Report specify that gcd 0 0 is not defined? Yes. The Report definition says gcd :: (Integral a) => a -> a -> a gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined" gcd x y = gcd' (abs x) (abs y) where gcd' x 0 = x gcd' x y = gcd' y (x `rem` y) On reflection, this is quite right. a divides b <=> there is an integer n with na = b. Thus any integer divides 0, and so the "greatest common divisor" would have to be the greatest integer, which is nonsense. Of course if you adopt Stephan Kahrs definition of "greatest", taken with respect to the partial order a<=b <=> a divides b, then gcd 0 0 = 0, because 0 is indeed the greatest integer in this ordering. Mathematically this makes sense, but it's not necessarily what people expect.

3 2

Re: GCD
by S.M.Kahrs 11 Dec '01

11 Dec '01

The natural reading of 'greatest' is, of course, the greatest in the divisibility preorder (it's partial order on natural numbers but only a preorder on integers). Thus, gcd 0 0 = 0. 3 and -3 are equivalent in that preoder. Thus, an additional comment may be in order. Stefan

2 1

gcd 0 0
by S.D.Mechveliani 11 Dec '01

11 Dec '01

People write about the Report definition of gcd x y as of greatest integer that divides x and y, and mention > gcd 0 0 = 0 But 2 also divides 0, because 2*0 = 0. Does the Report specify that gcd 0 0 is not defined? For an occasion: probably, it is better to specify this. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Instance declarations and class exports
by Simon Peyton-Jones 11 Dec '01

11 Dec '01

| > 1. "subordinate" names in export lists are always | unqualified Thus, | > we can have M.Ix( index ), but not M.Ix( T.index ). | | I don't see a compelling reason to outlaw the latter. We can | permit the subordinate name to be unqualified, but why should | we enforce it? Ditto for method names in instance decls. Allowing qualified names on the *lhs* of instance decls involves two new productions (qfunlhs, etc) that I have only just nuked. I sent mail about that some while ago, to see if anyone really thought we should keep it. Then, for export lists, the argument becomes one of uniformity (with instance decls) and simplicity. It seems compelling enough to me. Thanks for your wording suggestions. Simon

1 0

GCD
by Simon Peyton-Jones 11 Dec '01

11 Dec '01

About the GCD operator, the Haskell Report currently says: "gcd x y is the greatest integer that divides both x and y. lcm x y is the smallest positive integer that both x and y divide." Why does 'lcm' say 'positive' while 'gcd' does not? What is gcd -3 -6 Presumably 3, not -3. You could say that is obvious, since 3 > -3. So I propose to add "positive" to the gcd spec: gcd x y is the greatest POSITIVE integer that divides both x and y. I don't think that changes the specification in fact, but experience has led me to always check these things! Simon

4 3