January 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

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

binary files in haskell
by Timmy Douglas 06 Feb '01

06 Feb '01

I was wondering if anyone here has a solution for writing binary files that works in hugs and ghc that doesn't require getting libs. I looked at this page: http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html and the haskell.org libraries page and I didn't see anything. the ghc documentation didn't provide any examples so I was unable to figure out how to write a binary file.

3 4

MD5 in Haskell
by Ian Lynagh 03 Feb '01

03 Feb '01

I apologise if this is off topic for this list - I haven't been here long. Someone recently mentioned that the MD5 function in GHC uses C code to do the work so returns an IO String rather than a String. I have written an MD5 implementation in pure Haskell code (following the RFC - I don't know if a better optimised version could be written although I may look into this). I've put the code at http://c93.keble.ox.ac.uk/~ian/md5/ License is GPL. Ian

2 2

What does "Compiled code too complex" error message of Hugs mean?
by Laaser Christian 31 Jan '01

31 Jan '01

When loading some Haskell files with Hugs, I get the error message "Compiled code too complex". However, the compilation with GHC 4.08.1 succeeds. What does this message mean? What can I do about it? Christian

2 1

Problems with GHC-4.08.1 on Windows 2000 Professional
by Eugene Nonko 30 Jan '01

30 Jan '01

Dear Colleagues, I've encountered some problems after ghc-4.08.1 installation on by w2kpro. When I'm trying to compile simple 'Hello world!' program (ghc main.hs -o main.exe), linker outputs messages: === gcc: D:/ghc/lib/Main.dll_o: No such file or directory gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory === When I'm trying to compile it with -static command line switch (ghc main.hs -o main.exe -static), it compiles, but resulting .exe does nothing (it doesn't displays message). What's the problem, can someone explain me? PS. Just in case, this is full source code of this 'Hello world!' program. ;) === module Main (main) where main = putStrLn "Hello, world!" === Best regards, Eugene Nonko Novosoft Inc.

2 1

RE: Problems with GHC-4.08.1 on Windows 2000 Professional
by Simon Peyton-Jones 30 Jan '01

30 Jan '01

You have to compile with the flag -static, I'm afraid. 4.08.2 will have this built in. Simon | -----Original Message----- | From: Eugene Nonko [mailto:cm@pochta.net] | Sent: 30 January 2001 12:30 | To: haskell(a)haskell.org | Subject: Problems with GHC-4.08.1 on Windows 2000 Professional | | | Dear Colleagues, | | I've encountered some problems after ghc-4.08.1 installation | on by w2kpro. | When I'm trying to compile simple 'Hello world!' program (ghc | main.hs -o | main.exe), linker outputs messages: | === | gcc: D:/ghc/lib/Main.dll_o: No such file or directory | gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory | === | | When I'm trying to compile it with -static command line switch (ghc | main.hs -o main.exe -static), it compiles, but resulting .exe | does nothing | (it doesn't displays message). | | What's the problem, can someone explain me? | | PS. Just in case, this is full source code of this 'Hello | world!' program. | ;) | === | module Main (main) where | | main = putStrLn "Hello, world!" | === | | Best regards, | Eugene Nonko | Novosoft Inc. | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell |

1 0

FW: Consortium Caml
by Simon Peyton-Jones 29 Jan '01

29 Jan '01

Here's an interesting model for collaboration which the Caml folk are taking up. Simon -----Original Message----- From: Michel Mauny [mailto:Michel.Mauny@inria.fr] Sent: 26 January 2001 21:38 To: caml-list(a)inria.fr Subject: Consortium Caml -- [ English version below ] --- Dear Colleagues, We are pleased to announce the creation of the Caml Consortium, whose aim is to federate the design and development efforts around the Caml programming language. The Caml Consortium will therefore try to bring together, around the language development team, industries, research centres and educational establishments interested in contributing their support to the design and development of the language and related tools. Comprising a group of highly-motivated users, the Consortium will be the place where the members can identify their common requirements, exchange their experiences and solutions, and co-operate to propose a particular development of general interest. One of the Consortium's roles is therefore to be a place where users of the language can meet and exchange information. It is here that a true community will be created with the specific intention of assisting in the development of the language and to provide it with such a visibility that this community will expand by itself. The motivation and industrial importance of its members will also attract companies to the Consortium which want to be present on the Caml applications and training market. Another role of the Consortium will therefore be to attract new members, whether they are users of the language or service providers. Finally, the Consortium will provide a response to the question on the language's continuity. The essential elements for the continuity of a programming language are the continuity of its compilers (or their free availability), its user base, and the volume of existing (stable) codes. The success of the Caml Consortium will make it possible to measure the user base and the volume of the existing Caml code. As for the availability and development of the Caml compilers, these are already freely distributed with their sources. If INRIA decides at some point to withdraw from Caml development, and therefore to dissolve the Caml Consortium as it presently stands, the members of the Consortium will be sufficiently numerous, they will have sufficiently diversified profiles, and the market for the language will be such that the members of the Consortium will have no difficulty in continuing the existence and development of the language. INRIA will facilitate this transition, which is in the general interest. For more information, I suggest that you consult http://caml.inria.fr/consortium/ Best regards, -- Michel Mauny

2 1