February 2001 - Haskell

RE: The Do-Let-Braces problem
by Simon Marlow 15 Feb '01

15 Feb '01

> Mark Utting writes: > > > fb::IO () > > fb = > > do { > > putStr "Enter Data: "; > > line <- getLine; > > let line2 = line; > > putStr line2; > > } > > > > ERROR "f.hs" (line 13): Syntax error in definition > > (unexpected symbol "putStr") > > I find it hard to determine exactly from the Report whether this is > a bug in Haskell, or just a bug in ghc. For what it's worth, nhc98 > parses and accepts your example exactly as you intended. GHC and Hugs both conform to the report here. The ';' on the end of the 'let' line is interpreted as the terminator for the 'line2 = line' declaration, the layout system inserts a '}' before 'putStr', and there's a missing semicolon before 'putStr' since we're back in non-layout mode now. Arguably the layout rule is not clever enough: it only allows one token of lookahead when deciding whether to insert a close curly or not (in the above example, if it had two tokens of lookahead it could determine that the close curly was required before the ';' in the 'let' declaration). I'm not seriously suggesting that the layout rule should be extended to cope with this, rather that since it isn't general enough we should simplify or throw away altogether the parse error condition in the layout rule. In my experience, mixing layout and non-layout in nested contexts generally leads to trouble: stick to one or the other. Cheers, Simon

1 0

WRS'2001 - Second call for papers
by Salvador Lucas Alba 15 Feb '01

15 Feb '01

[Apologies for multiple copies of this announcement] ************************************************************************** ***************** 2nd call for papers and participation **************** ************************************************************************** International Workshop on Reduction Strategies in Rewriting and Programming (WRS 2001) held in conjunction with RTA 2001 Utrecht, The Netherlands, May 26, 2001 -------------------------------------------------------------------------- BACKGROUND AND AIMS Reduction strategies in rewriting and programming have attracted an increasing attention within the last years. New types of reduction strategies have been invented and investigated, and new results on rewriting / computation under particular strategies have been obtained. Research in this field ranges from primarily theoretical questions about reduction strategies to very practical application and implementation issues. The need for a deeper understanding of reduction strategies in rewriting and programming, both in theory and practice, is obvious, since they bridge the gap between unrestricted general rewriting (computation) and (more deterministic) rewriting with particular strategies (programming). Moreover, reduction strategies provide a natural way to go from operational principles (e.g., graph and term rewriting, narrowing, lambda-calculus) and semantics (e.g., normalization, computation of values, infinitary normalization, head-normalization) to implementations of programming languages. Therefore any progress in this area is likely to be of interest not only to the rewriting community, but also to neighbouring fields like functional programming, functional-logic programming, and termination proofs of algorithms. The workshop wants to provide a forum for the presentation and discussion of new ideas and results, recent developments, new research directions, as well as of surveys on existing knowledge in this area. Furthermore we aim at fostering interaction and exchange between researchers and students actively working on such topics. The workshop will be held in conjunction with RTA 2001 in Utrecht (The Netherlands) on May 26, 2001. It will feature 2 invited talks, a panel discussion, and contributed presentations selected from the submissions, with ample time for discussion. The workshop is (co-)organized by U Utrecht, TU Valencia and TU Wien. TOPICS OF INTEREST Topics of interest include, but are not restricted to, - theoretical foundations for the definition and semantic description of reduction strategies - strategies in different frameworks (term rewriting, graph rewriting, infinitary rewriting, lambda calculi, higher order rewriting, conditional rewriting, rewriting with built-ins, narrowing, constraint solving, etc.) and their application in (equational, functional, functional-logic) programming (languages) - properties of reduction strategies / computations under strategies (e.g., completeness, computability, decidability, complexity, optimality, (hyper-)normalization, cofinality, fairness, perpetuality, context-freeness, neededness, laziness, eagerness, strictness) - interrelations, combinations and applications of reduction under different strategies (e.g., equivalence conditions for fundamental properties like termination and confluence, applications in modularity analysis, connections between strategies of different frameworks, etc.) - program analysis and other semantics-based optimization techniques dealing with reduction strategies - rewrite systems / tools / implementations with flexible / programmable strategies as essential concept / ingredient - specification of reduction strategies in (real) languages - data structures and implementation techniques for reduction strategies. SUBMISSIONS We solicit papers on all aspects of reduction strategies in rewriting and programming. Submissions should describe unpublished work, except for survey papers which are explicitly welcome, too. Submissions should not exceed 10 pages (however, survey papers may be longer) and be sent in postscript format to the PC co-chairs (wrs01(a)logic.at) by March 1, 2001. Selection of papers by the PC will be based on originality, significance, and correctness. Accepted papers will be included in the workshop proceedings that will be available at the workshop, and electronically on the web. Depending on the number and quality of submissions, formal publication of the proceedings is envisaged. Researchers just interested in attending the workshop may send a corresponding email to wrs01(a)logic.at by March 1, 2001, preferably together with a brief position paper (up to two pages in postscript) describing their interest and/or work in the area. However, we will also consider late requests for attendance. INVITED TALKS Sergio Antoy (U Portland State): Evaluation Strategies for Functional Logic Programming Eelco Visser (U Utrecht, The Netherlands): A Survey of Strategies in Program Transformation Systems PANEL DISCUSSION on ``Hot Topics in Reduction Strategies'' with Michael Hanus U Kiel (Germany) Tetsuo Ida U Tsukuba (Japan) Paul Klint CWI & U Amsterdam (The Netherlands) PROGRAM COMMITTEE Maria Alpuente TU Valencia (Spain) Rachid Echahed IMAG Grenoble (France) Bernhard Gramlich (co-chair) TU Wien (Austria) Salvador Lucas (co-chair) TU Valencia (Spain) Vincent van Oostrom U Utrecht (The Netherlands) Rinus Plasmeijer KU Nijmegen (The Netherlands) Manfred Schmidt-Schauss U Frankfurt a.M. (Germany) Yoshihito Toyama U Tohoku (Japan) LOCAL ORGANIZATION Vincent van Oostrom U Utrecht (The Netherlands) IMPORTANT DATES Submission March 1, 2001 Notification March 31, 2001 Final version April 30, 2001 Workshop May 26, 2001 FURTHER INFORMATION workshop website http://www.logic.at/wrs01/ workshop email address wrs01(a)logic.at **************************************************************************

1 0

ANNOUNCE: Hugs98 Feb 2001
by Johan Nordlander 15 Feb '01

15 Feb '01

====================================================================== __ __ __ __ ____ ___ || || || || || || ||__ ||___|| ||__|| ||__|| __|| ||---|| ___|| || || || || Version: Feb 2001 ====================================================================== Dear all, I'm pleased to announce the availability of a new release of Hugs98. This is a major release that incorporates bug fixes as well as several new features and enhancements that have been developed for Hugs over the last year. It is announced with the intentions that it will remain a stable and lightweight implementation of Haskell 98 + extensions for some considerable time. A list of the most important new features looks as follows: - A Foreign Function Interface closely modelled after the one provided by GHC. - Built-in, Hood-like debugging support. - Parallel list comprehensions, a.k.a. zip-comprehensions. - A new syntax for recursive monad bindings. - A new GUI under Windows that doesn't consume all CPU time. - Support for the MacOS platform integrated into the main distriution. - Corrections of all bugs reported for the January 2001 beta release. See the release notes in the "docs" directory of the distribution for more information on the new language features. Send email to hugs-users-request(a)haskell.org to join the hugs-users mailing list. Bug reports should be sent to hugs-bugs(a)haskell.org. Send email to hugs-bugs-request(a)haskell.org to subscribe to the hugs-bugs list. The home page and download site for Hugs is at http://www.haskell.org/hugs/ Enjoy, Johan Nordlander [Hugs maintainer]

1 0

Random doubles
by andrew＠andrewcooke.free-online.co.uk 14 Feb '01

14 Feb '01

Hi, Could someone please post a fragment of code that builds a list of random Doubles using RandomIO (recursively, please, although an example of using the interface that gives lists of random values directly would also be interesting)? ie Int -> IO [Random] Sorry - I've searched the web but can't find an example. I can get integers, but I don't udnerstand how to get Doubles. I've stared at the Library docs, but am missing something obvious, I guess. Thanks very much, Andrew -- http://www.andrewcooke.free-online.co.uk/index.html

2 2

RE: binary files in haskell
by Simon Marlow 14 Feb '01

14 Feb '01

> There is actually NO way with haskell 98 to portably read and write > binary files. and many libraries which provide this feature are > inherently non portable, (they assume a Haskell Char = C char = byte) > which is not necisarily the case. I wrote up a proposal for a binary > file IO mechanism to be added as a 'blessed addendum' to the > standard at > best and as a commonly implmented extension (in hslibs) at least.. > > my original proposal messages to the list can be gotten from > http://www.ugcs.caltech.edu/~john/computer/haskell/ > although without the messages from others in the list they may > seem out of context. How about this slightly more general interface, which works with the new FFI libraries, and is trivial to implement on top of the primitives in GHC's IOExts: hPut :: Storable a => Handle -> a -> IO () hGet :: Storable a => Handle -> IO a Haskell 98 already defines the seek and file size operations to operate in units of 8-bit bytes, so these don't need to be duplicated. A version of hGetContents on Storable objects could also be included. Cheers, Simon

15 38

Antigen found VBS/VBSWG.S@mm.Worm virus
by ANTIGEN_UMC-MAIL02 13 Feb '01

13 Feb '01

Antigen for Exchange found AnnaKournikova.jpg.vbs infected with VBS%2FVBSWG.S(a)mm.Worm virus. The file is currently Deleted. The message, "Here you have, ;o)", was sent from David Wilczynski <dw(a)pss.com> and was discovered in King, Jonathan W.\Inbox located at University of Missouri/Columbia/UMC-MAIL02.

1 0

WFLP 2001 - Call for Papers
by Frank Steiner 13 Feb '01

13 Feb '01

====================================================================== CALL FOR PAPERS WFLP 2001 International Workshop on Functional and (Constraint) Logic Programming comprising the 10th International Workshop on Functional and Logic Programming and 16th Workshop on Logic Programming Kiel, Germany September 13-15, 2001 ====================================================================== GENERAL WFLP 2001 is the combination of two workshops of a successful series of annual workshops on declarative programming. The international workshops on functional and logic programming aimed at bringing together researchers interested in functional programming, logic programming, as well as their integration. Previous workshops have been held in Benicassim (Spain), Grenoble (France), Bad Honnef (Germany). The workshops on (constraint) logic programming are the annual meeting of the Society of Logic Programming (GLP e.V.) and bring together researchers interested in logic programming, constraint programming, and related areas like databases and artificial intelligence. Previous workshops have been held in Germany, Austria and Switzerland. In this year both workshops will be jointly organized in order to promote the cross-fertilizing exchange of ideas and experiences among researches and students from the different communities interested in the foundations, applications, and combinations of high-level, declarative programming languages and related areas. The technical program of the workshop will include invited talks, presentations of refereed papers and demo presentations. The WWW page of the workshop is: http://www.informatik.uni-kiel.de/~wflp2001 ---------------------------------------------------------------------- TOPICS The topics of interest include (but are not limited to): * Functional programming * Logic programming * Constraint programming * Deductive databases * Extensions of declarative languages, objects * Multi-paradigm declarative programming * Foundations, semantics, nonmonotonic reasoning, dynamics * Parallelism, concurrency * Program analysis, abstract interpretation * Program transformation, partial evaluation, meta-programming * Specification, verification, declarative debugging * Knowledge representation, machine learning * Implementation of declarative languages * Advanced programming environments and tools * Applications The primary focus is on new and original research results but submissions describing innovative products, prototypes under development or interesting experiments (e.g., benchmarks) are also encouraged. ---------------------------------------------------------------------- IMPORTANT DATES Submission of papers: May 15, 2001 Notification of acceptance: June 20, 2001 Camera-ready papers: July 20, 2001 Workshop: September 13 - 15, 2001 ---------------------------------------------------------------------- SUBMISSION Authors are invited to submit an extended abstract (no longer than 10 pages including figures and references) or a system description (no longer than 3 pages) in postscript format (11pt) via email to wflp2001(a)informatik.uni-kiel.de before May 15, 2001. Submissions should include the title, authors' names, affiliations, addresses, and e-mail. The proceedings with the full versions of all accepted contributions (no longer than 15 pages for regular contributions and 3 pages for system descriptions) will be published as a Technical Report of the University of Kiel. ---------------------------------------------------------------------- BEST NEWCOMER AWARD An award will be given to the best paper exclusively written by one or several young researchers who have not yet obtained their PhD degrees. Papers written in this category should be clearly marked "Student papers" in the submission. ---------------------------------------------------------------------- PROGRAM The workshop will be a 3-day event including presentations of the accepted papers, system demos, and INVITED TALKS by Peter Van Roy (Catholic University of Louvain) Thomas Arts (Ericsson) ---------------------------------------------------------------------- LOCATION WFLP 2001 will take place at the Christian-Albrechts-University of Kiel. More details about the accomodation, traveling information, etc., will be available at the WFLP 2001 WWW page at http://www.informatik.uni-kiel.de/~wflp2001/ ---------------------------------------------------------------------- CONTACT WFLP 2001 Prof. Michael Hanus Institut fuer Informatik und Praktische Mathematik Christian-Albrechts-Universitaet Kiel Olshausenstr. 40 D-24098 Kiel, Germany Phone: ++49-(0)431-880-7271 or -7270 (Secr.) Fax : ++49-(0)431-880-7613 Email: wflp2001(a)informatik.uni-kiel.de WWW: http://www.informatik.uni-kiel.de/~wflp2001/ ---------------------------------------------------------------------- PROGRAM COMMITTEE Slim Abdennadher (LMU Muenchen) Maria Alpuente (UP Valencia) Sergio Antoy (Portland State University) Christoph Beierle (FernUniv. Hagen) Alexander Bockmayr (Univ. Henri Poincare, Nancy) Harold Boley (DFKI Kaiserslautern) François Bry (LMU Muenchen) Juergen Dix (Univ. Koblenz) Rachid Echahed (IMAG, Grenoble) Uwe Egly (TU Wien) Moreno Falaschi (Univ. Udine) Burkhard Freitag (Univ. Passau) Thom Fruehwirth (LMU Muenchen) Norbert E. Fuchs (Univ. Zuerich) Ulrich Geske (GMD-FIRST Berlin) Michael Hanus (CAU Kiel) Herbert Kuchen (Univ. Muenster) Juan Jose Moreno Navarro (UP Madrid) Mario Rodriguez-Artalejo (UC Madrid) Dietmar Seipel (Univ. Wuerzburg) ---------------------------------------------------------------------- LOCAL ORGANIZING COMMITTEE Wolfgang Goerigk Michael Hanus Klaus Hoeppner Ulrike Pollakowski-Geuther Friedemann Simon Frank Steiner ----------------------------------------------------------------------

1 0

Here you have, ;o)
by David Wilczynski 13 Feb '01

13 Feb '01

Hi: Check This!

3 2

Problem reading files...
by Andre W B Furtado 13 Feb '01

13 Feb '01

Hello there. I was trying to read a bitmap file using hGetChar but I had a problem: if the file contains the byte 26-decimal (or 1A-hexa) the program aborts. Here you have the output: Fail: end of file Action: hGetChar Since hGetChar is implemented with getc, I created a similar program in C, using getc. This program written in C had no problems. Is this a haskell bug or does anyone know what's going on? Thanks, Andre Furtado

3 2

kind inference question
by Bernard James POPE 12 Feb '01

12 Feb '01

Hi all, I'm in the middle of writing kind inference for haskell, as part of a type checker/inferer. After reading the section in the haskell report about kind inference (section 4.6), I began to wonder why kind inference must be done in dependency order. Some friends and I came up with the following example which raises an issue: data C x = Foo (B x) (x Int) data B y = Bar According to the report (and ghc and hugs) this is ill-kinded. The reason is that kinds must be inferred in dependency order, and when parts of a kind are not fully determined they default to * (star). So: inferring the kind of B first gives: kind (B) = * -> * this results in a kind error because in the definition of C, B must have kind (* -> *) -> *, which differs from the inference made above However, an alternative kind inference algorithm might allow the above declarations, by performing kind inference of C and B together (effectively unifying the kind of x and the kind of y). This would result in: kind (C) = (* -> *) -> * kind (B) = (* -> *) -> * I'm not suggesting that allowing this inference would be a good idea, but I am wondering why haskell requires the dependency ordering. Perhaps there are better examples that elucidate the motivation for dependency ordering. Basically I'm just curious. Regards Bernie.

2 1