February 2002 - 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

MPC 2002: Deadline extended until 11 February
by mpc02 15 May '02

15 May '02

[Apologies for multiple copies] The deadline for MPC 2002, 6th International Conference on MATHEMATICS OF PROGRAM CONSTRUCTION, 8-10 July, Dagstuhl, Germany (see http://www.cs.ukc.ac.uk/conf/mpc2002/ for a full CFP) has been extended until 11 February 2002. Full papers should be submitted in Postscript or pdf format by e-mail to mpc02(a)ukc.ac.uk. -- Mathematics of Program Construction '02 at Dagstuhl Eerke Boiten, Computing Laboratory, University of Kent at Canterbury, UK +44.1227.827615 (fax 762811)

1 1

multiparameter generic classes
by Hal Daume III 03 Mar '02

03 Mar '02

are there any papers/webpages/implementations/etc. of using multiparameter classes in a generic framework, with or without dependencies? thanks! - hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

use of undefined type
by Andre W B Furtado 28 Feb '02

28 Feb '02

I'm developing a tool that will help game programmers to develop games in Haskell. To create a game object, the programmer must call the function *object* as follows: object name_of_object position_of_object speed_of_object I would like also to add another param to this function, which type would be anyone defined by the programmer. Unfortunately, as Haskell does not allow things like: type Game = (Name,Position,Speed,t) where t is an undefined type, I'm forced to add "t" to the left side of the type synonym (type Game t = ...). But this is realling doing a mess in my code, since I have to pass this "t" all around. That's why I ask if anyone knows another idea to solve this problem... Thanks a lot, -- Andre W

2 1

FW: Haskell 98 lexical syntax again
by Simon Peyton-Jones 28 Feb '02

28 Feb '02

Folks, Two small matters of lexical syntax for Haskell 98. (As ever, I'm posting this to the whole list because I feel I shouldn't fiddle with the Report without telling you all. Partly because many eyeballs is good for debugging, partly because there might be an objection in principle that I don't know of.) 1. Ian Lynagh pointed out the following problem: | The report says | | whitechar -> newline | return | linefeed | vertab | formfeed | | space | tab | uniWhite | newline -> a newline (system dependent) | return -> a carriage return | linefeed -> a line feed | | so, if your system defines a newline to be a line feed, an | implementation is free to choose whether to lex a line feed | as a whitechar or a newline, which makes quite a difference | when you consider the layout rule! I propose to solve this as follows: whitechar -> newline | vertab | space | tab | uniWhite newline -> return linefeed | return | linefeed | formfeed return -> a carriage return linefeed -> a line feed This means that CR, LF, or CRLF, are all valid 'newline' separators, and the same sequence of characters should therefore work on any Haskell implementation. 2. As a separate matter, I propose to replace the production for ANY by ANY -> graphic | whitechar This seems nicely dual to any -> graphic | space | tab The existing production for ANY is: ANY -> any | newline | vertab | formfeed | return | linefeed | uniWhite which simply repeats whitechar + space + tab. Simon

1 0

SBLP'2002 deadline extension --> March 7
by Carlos Camarao de Figueiredo 28 Feb '02

28 Feb '02

The deadline for submissions to SBLP'2002 has been extended to March 7, 2002. The full updated call for papers is included below. =============================================== SBLP'2002 VI Brazilian Symposium on Programming Languages http://www.inf.puc-rio.br/sblp Departamento de Informática PUC-Rio Rio de Janeiro, RJ, Brazil June 05-07, 2002 =============================================== Final Call for Papers --------------------- The VI Brazilian Symposium on Programming Languages (SBLP'2002) will be held at Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) in Rio de Janeiro, Brazil, on June 05-07, 2002. The symposium is sponsored by the Brazilian Computer Society (SBC) andg aims to provide a forum where researchers, educators, and practitioners present and discuss the latest theoretical and practical work on programming languages. We invite authors to contribute to SBLP'2002 with the following kinds of submission: * Technical research papers introducing original research results on topics such as (but not limited to): - Programming language design and implementation - Formal semantics of programming languages - Domain-specific programming languages - Visual programming languages - Programming languages for mobile, WWW, and network computing - Script languages - Design and implementation of programming tools and environments - New programming models - Theoretical foundations of programming languages - Teaching programming languages * Experience reports on the use of programming languages, tools, and environments. The reports should clearly state the problems and difficulties identified on using those programming languages or technologies on projects, possibly giving solutions to those problems or hints to avoid them. * Tutorial proposals on subjects related to programming languages, APIs, tools, environments or theories. There will be also invited lectures, tutorials, panels, and working meetings to closely group together professionals interested on specific research topics. Important dates --------------- Deadline for submissions: March 7, 2002 Notification of acceptance: April 8, 2002 Camera-ready version: May 15, 2002 Conference chair ---------------- Edward Hermann Haeusler Departamento de Informática Pontifícia Universidade Católica do Rio de Janeiro Tel.: +55 (21) 3114-1500 R: 4345 email: hermann(a)inf.puc-rio.br Program Chair ------------- Carlos Camarão Departamento de Ciência da Computação Universidade Federal de Minas Gerais Tel: +55 (31) 3499 5889 email: camarao(a)dcc.ufmg.br Submission details ------------------- Contributions can be written in Portuguese, English or Spanish. Those written in English can be selected for publication elsewhere (probably Elsevier Electronic Notes in Theoretical Computer Science). All papers and experience reports will be published in the conference proceedings. Papers should have at most 14 pages and experience reports at most 8 pages. ---- Tutorials will be published in a separate proceedings. They should cover material of postgraduate level. The tutorial submission may be only a proposal, containing: - title - author names - motivation, describing the relevance of the subject in the area of programming languages - abstract - description of the presentation (optional) Tutorial proposals will be selected according to i) its technical quality and ii) expected relevance and interest from the community. The final tutorial should contain at most 30 pages. ---- Contributions should use the standard format of SBC (Brazilian Computer Society). They are available in: - LaTeX: http://www.sbc.org.br/templates/sbc-template-latex.zip - PDF/Adobe Acrobat: http://www.sbc.org.br/templates/sbc-template-pdf.zip - Word: http://www.sbc.org.br/templates/sbc-template-dot.zip Use of LaTeX is preferred. Examples of the use of the SBC format can be found in these zip files. (You can also obtain them by visiting the site http://www.sbc.org.br and following the links *eventos* and, afterwards, *Informações úteis*.) For submission of contributions, fill out the required information at http://www.dcc.ufmg.br/~camarao/sblp/forms/authpaper_reg.html ======================================================================

1 0

RE: Behavior of fromInteger on out-of-range arguments
by Simon Peyton-Jones 28 Feb '02

28 Feb '02

| By the way, the report says: "Class Enum defines operations | on sequentially | ordered types." I think the "sequentially" means that | multiple applications | of succ to a value shall not result in the same value. That's | why I think | that succ (maxBound :: Int) should be an error and not | minBound :: Int. | Because i + 1 should be equal to succ i for every Int value | i, (maxBound :: | Int) + 1 should also be an error and so should every | arithmetic operation | that overflows or underflows. The revised version of the report http://research.microsoft.com/~simonpj/haskell98-revised says that succ maxBound is an error for any Bounded type. So I think this is covered already. Simon

1 0

ANN: IDoc - A Haskell Interface Documentation System
by Manuel M. T. Chakravarty 28 Feb '02

28 Feb '02

I am pleased to announce the initial release (version 0.2.5) of the new interface documentation system IDoc. It extracts both interface comments and declarations from library modules and formats them in HTML, thus supporting the automatic generation of library documentation from Haskell source code. http://www.cse.unsw.edu.au/~chak/haskell/idoc/ The striking features of IDoc are simplicity and interface comment annotations that are non-imposing when the Haskell source is displayed in a text editor: * The implementation is essentially a single Haskell module abiding by Haskell 98. No complicated build and installation procedure and no weird language extensions that require you to build a special Haskell compiler before installing the tool. * Interface comments are identified by a single extra character and simple formatting (such as the present ASCII itemisation) is sufficient to produce HTML displays. * Most annotations are similar to common ASCII formatting idioms. * Haskell's layout rule is used to determine the extent of interface declarations. Cheers, Manuel

1 0

Sockets and firewalls
by Till Mossakowski 28 Feb '02

28 Feb '02

Hello, I have seen that there are several Haskell libraries for cgi scripts and the like. Is there also a possibiliy to deal with sockets and firewalls? Till Mossakowski -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till(a)tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till

2 1