September 2003 - Haskell

Question about implementation of an "information-passnig" arrow
by Yu Di 16 Sep '03

16 Sep '03

Sorry I just now pressed "send" by mistake when the letter was not finished yet. Please ignore my last mail. Thanks. Following is the correct version of my question. ----- Hi, I want to create an arrow which is essentially data MyArrow a b = MyArrow ((String, a) -> (String, b)) i.e. there is an "information" asscioated with each piece of data (represented by the string), and I want to pass it around. And often the arrow's processing logic will depend on the input information, therefore a monad-style data MyArrow a b = MyArrow (a -> (String, b)) will not work. Now I have a problem with the definition of "pure" and "first". At first, I declared pure f = MyArrow (\(s, x) -> (s, f x)) first (MyArrow f) = MyArrow (\(s, (x, y)) -> let (s', z) = f (s, x) in (s', (z, y))) this seems to work, but then I begin to have problems with the "data-plumbing" pure arrows, e.g. in pure (\x -> (x, x)) >>> first someArrow >>>> pure (\(_, x) -> x) Ideally, this arrow will preserve whatever information I put there for the input, but because "first someArrow" will change the WHOLE information associated with the pair of result, I can't find any way to let "pure (\(_, x)->x)" (which is an extremely generic function) retrieve the PART of information for the second piece in the pair tuple. I thought about this a lot, but it seems to me that the only way to solve this is to somehow make the information "lookupable" from the data itself, not "placed beside" the data, but how I can do that? And can there be some other solution to this? Thanks very much! Di, Yu 9.15 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

Deadline for JFP Special Issue on Parallel FP Postponed
by Phil Trinder 16 Sep '03

16 Sep '03

The submission deadline for the JFP special issue on High-Performance Parallel Programming has been postponed to 31st October 2003, see http://www.macs.hw.ac.uk/~trinder/jfpCFP.htm Phil -------------------------------------------------- Phil Trinder School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E-mail: trinder(a)macs.hw.ac.uk Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.macs.hw.ac.uk/~trinder

1 0

Question about implementation of a " arrow
by Yu Di 15 Sep '03

15 Sep '03

Hi, I want to create an arrow which is essentially data MyArrow a b = MyArrow ((String, a) -> (String, b)) i.e. there is an "information" asscioated with each piece of data (represented by the string), and I want to pass it around. And often the arrow's processing logic will depend on the input information, therefore a monad-style data MyArrow a b = MyArrow (a -> (String, b)) will not work. Now I have a problem with the definition of "pure" and "first". At first, I declared pure f = MyArrow (\(s, x) -> (s, f x)) first (MyArrow f) = MyArrow (\(s, (x, y)) -> let (s', z) = f (s, x) in (s', (z, y))) this seems to work, but then I begin to have problems with the "data-plumbing" pure arrows, e.g. in pure (\x -> (x, x)) >>> first someArrow >>>> pure (\(_, x) -> x) Ideally, this arrow will preserve whatever information I put there for the input, but because "first someArrow" will change the WHOLE information associated with the pair of result, I can't find any way to let "pure (\(_, x)->x)" retrieve the PART of information for the second piece in the pair tuple. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

RE: lexer puzzle
by Simon Marlow 15 Sep '03

15 Sep '03

> I agree with Marcin, > > A... should be split into "A.." and "." > > As I read the (on-line) report the "maximal munch" rule says that you > should read the longest lexeme. It does not say that two > operators have > to be separated by whitespace. > > Because A... is not a lexeme, the longest lexeme you can read from > "A..." is "A.." (qualified dot-operator). Wow! I hadn't noticed that before. This means that for example, 'M.where ' must be interpreted as the two tokens 'M.wher' 'e' This is bound to keep the Obfuscated Haskell programmers happy :-) Cheers, Simon

1 0

RE: lexer puzzle
by Simon Marlow 15 Sep '03

15 Sep '03

Iavor Diatchki writes: > what do people think should be the tokens produced by a haskell lexer > when applied to the following input: > > A... This has been discussed before (a while back, admittedly). See: http://www.mail-archive.com/haskell@haskell.org/msg04054.html GHC (still) gets this wrong. It's a documented bug though. Cheers, Simon

1 0

RE: Circular Instance Declarations
by Simon Peyton-Jones 14 Sep '03

14 Sep '03

OK, I yield! The HEAD now runs this program. It turned out to be a case of interchanging two lines of code, which is the kind of fix I like. Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Ashley Yakeley | Sent: 07 September 2003 06:57 | To: haskell(a)haskell.org | Subject: Circular Instance Declarations | | When -fallow-undecidable-instances is switched on, is there any reason | why circular instances are forbidden? For instance: | | module CircularInsts where | { | data D r = ZeroD | SuccD (r (D r)); | | instance (Eq (r (D r))) => Eq (D r) where | { | ZeroD == ZeroD = True; | (SuccD a) == (SuccD b) = a == b; | _ == _ = False; | }; | | newtype C a = MkC a deriving Eq; | | equalDC :: D C -> D C -> Bool; | equalDC = (==); | } | | When I compile this, I get this: | | $ ghc -fglasgow-exts -fallow-undecidable-instances -c CircularInsts.hs | CircularInsts.hs:2: | Context reduction stack overflow; size = 21 | Use -fcontext-stack20 to increase stack size to (e.g.) 20 | `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16 | `Eq (D C)' arising from use of `==' at CircularInsts.hs:16 | `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16 | `Eq (D C)' arising from use of `==' at CircularInsts.hs:16 | | Would it be reasonable for the compiler to check back through the stack | and allow the circularity? It will just create an ordinary recursive | function. | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

3 2

TACAS 2004 Call For Papers (deadline: October 17)
by AG2 Guest Account 3 13 Sep '03

13 Sep '03

Call for Papers TACAS'04 [http://www.daimi.au.dk/%7Ecpn/tacas04/] Tenth International Conference on Tools and Algorithms for the Construction and Analysis of Systems A member conference of ETAPS 2004 [http://www.lsi.upc.es/etaps04/] European Joint Conferences on Theory and Practice of Software IMPORTANT DATES * October 17, 2003 Submission deadline * December 12, 2003 Notification of authors * January 9, 2004 Camera ready version due * March 29 - April 2, 2004 TACAS 2004 Conference PROGRAM COMMITTEE Jonathan Billington, University of South Australia, Adelaide (Australia) Bernard Boigelot, Université de Liège (Belgium) Ed Brinksma, University of Twente (The Netherlands) Witold Charatonik, University of Wroclaw (Poland) Rance Cleaveland, SUNY Stony Brook (USA) Giorgio Delzanno, Università di Genova (Italy) David L. Dill, Stanford University (USA) Susanna Donatelli, Università degli Studi di Torino (Italy) Javier Esparza, University of Edinburgh (UK) John Hatcliff, Kansas State University (USA) Kurt Jensen (co-chair), University of Aarhus (Denmark) Orna Kupferman, Hebrew University, Jerusalem (Israel) Yassine Lakhnech, Verimag Grenoble (France) Kim Larsen, Aalborg University (Denmark) Anca Muscholl, Université Paris 7 (France) Anna Philippou, University of Cyprus (Cyprus) Andreas Podelski (co-chair), Max-Planck-Institut Saarbrücken (Germany) Jaco van de Pol, CWI Amsterdam (The Netherlands) Jakob Rehof, Microsoft Redmond (USA) Martin C. Rinard, MIT, Cambridge (USA) Bill Roscoe, Oxford University (UK) Bernard Steffen, Universität Dortmund (Germany) Ofer Strichman, Carnegie Mellon University, Pittsburgh (USA) Antti Valmari, Tampere University of Technology (Finland) Andreas Zeller, Universität des Saarlandes (Germany) CONFERENCE DESCRIPTION TACAS is a forum for researchers, developers and users interested in rigorously based tools for the construction and analysis of systems. The conference serves to bridge the gaps between different communities --- including but not limited to those devoted to formal methods, software and hardware verification, static analysis, programming languages, software engineering, real-time systems, and communications protocols --- that share common interests in, and techniques for, tool development. In particular, by providing a venue for the discussion of common problems, heuristics, algorithms, data structures and methodologies, TACAS aims to support researchers in their quest to improve the utility, reliability, flexibility and efficiency of tools for building systems. TACAS is a member conference of the European Joint Conferences on Theory and Practice of Software (ETAPS), which is the primary European forum for academic and industrial researchers working on topics relating to Software Science. ETAPS 2004 [http://www.lsi.upc.es/etaps04/] is the seventh joint conference in this series. The conference is organized by the Technical University of Catalonia (UPC) [http://www.upc.es] Tool descriptions and case studies with a conceptual message and theoretical papers with a clear link to tool construction are all encouraged. The specific topics covered by the conference include, but are not limited to, the following: * Specification and verification techniques * Theorem-proving and model-checking * System construction and transformation techniques * Static and run-time analysis * Compositional and refinement-based methodologies * Testing and test-case generation * Analytical techniques for real-time, hybrid and safety-critical systems * Tool environments and tool architectures * Applications and case studies As TACAS addresses a heterogeneous audience, potential authors are strongly encouraged to write about their ideas in general and jargon-independent, rather than application- and domain-specific, terms. Authors reporting on tools or case studies are strongly encouraged to indicate how their experimental results can be reproduced and confirmed independently. TACAS 2003 received a *record number of submissions*: 140 research papers and 20 tool papers were submitted. The Program Committee selected 35 research papers and 6 tool papers, and invited 2 research paper submissions as tool papers. The average acceptance ratio was 27% (25% for research papers and 30% for tool papers). * Conference program 2003 [http://www.inrialpes.fr/vasy/tacas03/program.html] * On-line proceedings 2003 [http://link.springer.de/link/service/series/0558/tocs/t2619.htm] (available via Springer's LINK service) PROGRAM COMMITTEE CHAIRS Kurt Jensen, University of Aarhus (Denmark) [http://www.daimi.au.dk/~kjensen/] Andreas Podelski, Max-Planck-Institut Saarbrücken (Germany) [http://www.mpi-sb.mpg.de/~podelski] TOOL CHAIR Bernhard Steffen, Universität Dortmund (Germany) [http://ls5-www.cs.uni-dortmund.de/staff/steffen.de.html] INVITED SPEAKER Antti Valmari, Tampere University of Technology (Finland) [http://www.cs.tut.fi/~ava/] ------------------------------------------------------------------------ SUBMISSION GUIDELINES As with other ETAPS conferences, TACAS accepts two types of contributions: *research papers* and *tool demonstration papers*. Both types of contributions will appear in the proceedings and have oral presentations during the conference. Please notice that there are *two different conference services* for submission of papers: * The TACAS 2004 Conference Service is used for submission of research papers. * The TACAS 2004 TOOL Conference Service is used for submission of tool demonstration papers. -- Authors who anticipate possible last minute delays in the submission of a full research paper or a full tool demonstration paper are encouraged to submit a title and abstract well in advance of the deadline. -- Research papers Research papers cover one or more of the topics above, including tool development and case studies from a perspective of scientific research. Research papers are evaluated by the TACAS Program Committee. Submitted research papers *must*: * be in English and have a maximum of 15 pages, * present original research which is unpublished and not submitted elsewhere (conferences or journals) -- in particular, simultaneous submission of the same contribution to multiple ETAPS conferences is forbidden, * use the Springer-Verlag LNCS style [http://www.springer.de/comp/lncs/authors.html] * be submitted electronically in Postscript or PDF form via the TACAS 2004 Conference Service no later than October 17. Submissions deviating from these instructions may be rejected without review. Any questions regarding this policy should be directed to the Program Committee Chairs Kurt Jensen [http://daimi.au.dk/~kjensen/] or Andreas Podelski [http://www.mpi-sb.mpg.de/~podelski] prior to submitting. Tool demonstration papers Tool demonstration papers present tools based on aforementioned technologies (e.g., theorem-proving, model-checking, static analysis, or other formal methods) or fall into the above application areas (e.g., system construction and transformation, testing, analysis of real-time and hybrid systems, etc.). Tool demonstration papers are evaluated by the TACAS Tool Chair with the help of the Program Committee. Submitted tool demonstration papers *must*: * be in English and have a maximum of 4 pages, * have an appendix (not included in the 4 page count) that provides a detailed description of: o how the oral presentation will be conducted, e.g. illustrated by a number of snapshots, o the availability of the tool, the number and types of users, other information which may illustrate the maturity and robustness of the tool, o link to a web-page for the tool (if this exists). The appendix will *not* be included in the proceedings, but during the evaluation of the tool demonstration papers it will be *equally important* as the pages for the proceedings * use the Springer-Verlag LNCS style [http://www.springer.de/comp/lncs/authors.html] * be submitted electronically in Postscript or PDF form via the TACAS 2004 TOOL Conference Service no later than October 17. Submissions deviating from these instructions may be rejected without review. Any questions regarding this policy should be directed to the Tool Chair Bernhard Steffen [http://ls5-www.cs.uni-dortmund.de/staff/steffen.de.html]

1 0

Where are higher-rank and existential types used?
by Ken Shan 13 Sep '03

13 Sep '03

Hello, Norman Ramsey and I are looking for examples of where higher-rank polymorphism and existential types are useful. Can anyone think of uses besides the following? Higher-rank types are used in: - Deforestation Andrew Gill, John Launchbury, and Simon L. Peyton Jones. 1993. A short cut to deforestation. In _Functional programming languages and computer architecture: 6th conference_, 223-232. New York: ACM Press. - Lazy functional state threads John Launchbury and Simon L. Peyton Jones. 1994. Lazy functional state threads. In _PLDI '94: Proceedings of the ACM conference on programming language design and implementation_, vol. 29(6) of _ACM SIGPLAN Notices_, 24-35. New York: ACM Press. - Generic (polytypic) programming Ralf Hinze. 2000. A new approach to generic functional programming. In _POPL '00: Conference record of the annual ACM symposium on principles of programming languages_, 119-132. New York: ACM Press. Ralf Lämmel and Simon L. Peyton Jones. 2003. Scrap your boilerplate: A practical design pattern for generic programming. In _Proceedings of the 2003 ACM SIGPLAN international workshop on types in languages design and implementation_, 26-37. New York: ACM Press. - Data type invariants Chris Okasaki. 1999. From fast exponentiation to square matrices: An adventure in types. In _ICFP '99: Proceedings of the ACM international conference on functional programming_, vol. 34(9) of _ACM SIGPLAN Notices_, 28-35. New York: ACM Press. Ralf Hinze. 2001. Manufacturing datatypes. _Journal of Functional Programming_ 11(5): 493-524. Richard Bird and Ross Paterson. 1999. de Bruijn notation as a nested datatype. _Journal of Functional Programming_ 9(1): 77-91. Existential types are used in: - Object-oriented programming Benjamin C. Pierce and David N. Turner. 1994. Simple type-theoretic foundations for object-oriented programming. _Journal of Functional Programming_ 4(2): 207-247. Konstantin Läufer. 1996. Type classes with existential types. _Journal of Functional Programming_ 6(3): 485-517. - Abstract data types John C. Mitchell and Gordon D. Plotkin. 1988. Abstract types have existential type. _ACM Transactions on Programming Languages and Systems_ 10(3): 470-502. Any pointers or technique descriptions would be highly appreciated! If there are many contributions, I will post an updated version of this list. Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig United Nations Day is 24 October. http://www.un.org/events/unday/ The Lost Voice of Radio Beijing http://www.milinfoserv.net/lvrb.html Write letters! We got half of New Testament that way.

2 1

File reading question
by Gordon James Miller 12 Sep '03

12 Sep '03

Hello all, I believe I have a mental block on some issues related to IO and would really appreciate some help on this. I have a text file that contains two columns of numbers, basically X and Y values. I need a function (or set of functions) that reads this file and returns two arrays, one of the X values and one of the Y. A sample data file might look like. 10.0 20.0 20.0 40.0 30.0 60.0 40.0 80.0 Reading in this file should return two arrays [10.0, 20.0, 30.0, 40.0] and [20.0, 40.0, 60.0, 80.0]. Thanks for any help on this, I just don't seem to get IO in Haskell without reassignments. Gordon James Miller Promisemark, Inc. Senior Computer Scientist gmiller(a)promisemark.com (571)330-9012 The box said "Requires Windows 95 or better." So I installed LINUX

3 2

Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
by Simon Marlow 11 Sep '03

11 Sep '03

> > I also think that having backwards compatability is not much of an > > issue. After all, ghc has introduces a number of not backward > > compatable changes to haskell, and I never heard any complaints. > > Oh no? > > Implicit parameters: I'm sure it is a great thing, but I'd already > used the (?) operator, and need -fglasgow-exts. Now my program > depends on a bunch of well places spaces to compile. > > Template Haskell: really cool new feature, which just happens to use > a syntax that overlaps with the list comprehension syntax. > > And now, let's just screw any backwards compatibility, and re-engineer > the records system¹. We at GHC HQ agree, and for future extensions we'll move to using separate options to enable them rather than lumping everything into -fglasgow-exts. This is starting to happen already: we have -farrows, -fwith, -fffi (currently implied by -fglasgow-exts). Of course, if we change the language that is implied by -fglasgow-exts now, we risk breaking old code :-) Would folk prefer existing syntax extensions be moved into their own flags, or left in -fglasgow-exts for now? I'm thinking of: - implicit parameters - template haskell - FFI - rank-N polymorphism (forall keyword) - recursive 'do' (mdo keyword) Cheers, Simon

8 7