- Haskell - Haskell.org

AVIS'01: LAST Call for Abstracts
by Ramesh Bharadwaj 15 Feb '01

15 Feb '01

First International Workshop on Automated Verification of Infinite-State Systems (AVIS'01) http://www.informatik.hu-berlin.de/top/fme2001/html/workshops.html Co-located with FME 2001 in Berlin, Germany 12th March 2001 This workshop is a forum for researchers, students, and practitioners interested in the application of formal methods and tools for the auomatic verification of large practical systems. Formal methods, in particular model checking, is increasingly being used in industry to automatically establish the correctness of (and to find flaws in) finite-state systems, such as descriptions of hardware and protocols. However, model checking is limited in scope due to the state explosion problem. Most practical system descriptions, notably that of software, are therefore not directly amenable to finite-state verification methods since they have very large or infinite state spaces. For such systems, theorem proving -- a process that requires manual effort and mathematical sophistication to use -- has so far been the only viable alternative. More recently, we have seen the emergence of hybrid techniques that combine the ease-of-use of model checkers with the power of theorem provers. Tools based on these techniques afford users with full automation, and are less sensitive to the size of the state space (which may be infinite or arbitrarily large). There is a growing body of knowledge in this field which has a very exciting future. The intention of this workshop is to build a forum for exchanging ideas and experiences by bringing together theoreticians, tool builders, as well as practitioners who are interested in this emerging area of research in formal verification. The Workshop The workshop will be co-located with FORMAL METHODS EUROPE 2001 "Formal Methods for Increasing Software Productivity" 12-16 March 2001, Humboldt-Uinversitaet zu Berlin, Germany. The workshop will be held on 12th March. Submission You are invited to submit a 2-4 page abstract on related research or case study. We invite both completed work as well as work in progress; the aim of the workshop is to stimulate discussion and bring together people with varying backgrounds from disparate communities. Submission should be made electronically to ramesh(a)itd.nrl.navy.mil We accept plain text, pdf, or postscript submissions. Authors of accepted abstracts will be expected to give a 20 minute presentation at the workshop. Important Dates 16th February 2001 Submission of abstracts 2nd March 2001 Notification of acceptance 12th March 2001 Workshop 15th June 2001 Camera-ready copies due Workshop Organizers Dr. Ramesh Bharadwaj Center for High Assurance Computing Systems Naval Research Laboratory Washington DC 20375 ramesh(a)itd.nrl.navy.mil +1-202-767-7210 Dr. Steve Sims Chief Technology Officer -- Reactive Systems, Inc. http://www.reactive-systems.com sims(a)reactive-systems.com +1-703-534-6458 Publication The accepted papers will be published as a Naval Research Laboratory Technical Memorandum. Authors of selected papers may be invited to submit full and revised papers for a special journal issue after presentation at the workshop.

1 0

Haskell threads & pipes & UNIX processes
by Michael Marte 15 Feb '01

15 Feb '01

Hello *, I need to compress the output of my Hakell program. To avoid the creation of huge files, I want to compress before writing by means of gzip or bzip2. However, this seems to be quite involved. I decided to run the compressor with runProcess :: FilePath -- Command -> [String] -- Arguments -> Maybe [(String, String)] -- Environment(Nothing -> Inherited) -> Maybe FilePath -- Working directory (Nothing -> inherited) -> Maybe Handle -- stdin (Nothing -> inherited) -> Maybe Handle -- stdout (Nothing -> inherited) -> Maybe Handle -- stderr (Nothing -> inherited) -> IO () First I wanted to use Posix.createPipe to connect to the compressor but Posix.createPipe returns a Fd. So this does not fit. I ended up with using Posix.createNamedPipe. This creates a named pipe that can be openend with IO.openFile (which again yields the Handle needed for runProcess). At this point, it turned out that the pipe has to be opened for reading before it can be opened for writing (ghc-4.08.1). This seems to be a bug. (In a shell, the order does not matter; the processes are suspended as expected.) Then, as expected, the problem occured that writing to the pipe and compressing cannot be sequenced. If the producer is started first, the producer blocks because there is no consumer. If the consumer is started first, the consumer blocks because there is no input. So I played around with threads. If both consumer and producer are executed as threads, the program terminates immediately without any output. There seems to be no need to start executing any of the threads. If either the producer or the compressor are executed in a thread, the compressor bails out complaining that some resource is not available. So what's going on? How can the goal be achieved? Thank you, Michael

1 0

The Do-Let-Braces problem
by Mark Utting 15 Feb '01

15 Feb '01

Summary: Haskell layout has problems within 'do' (see below). Can we change Haskell to improve it? We teach Haskell to all our second-year students, and we like to teach the OPTION of using explicit braces and ;'s. (If students write nested do constructs, even though we discourage this, they often have trouble with the layout rules.) We would like to be able to teach this: "To use explicit structuring, instead of layout, you can just put braces around all the statements in a 'do' block, plus semicolons at the end of each statement. (like in C++/Java!)." But this does not work. For example, the first definition below parses, but the second does not. fa::IO () fa = do putStr "Enter Data: " line <- getLine let line2 = line putStr line2 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") Fix 1: Put explicit braces around the body of the 'let': let {line2 = line}; This is ugly and a nuisance to teach. It would be much nicer to be able to teach 'let pattern = expr' as a simple statement, and avoid mentioning the possibility of multiple definitions within a single 'let'. (Which is rarely needed within 'do' syntax anyway, because you can usually use several separate let statements instead. Mutually recursive definitions is probably the only reason.) Fix 2: an alternative fix is to move the semicolon at the end of the let to the beginning of the next line, but this is ugly! f2 = do { putStr "Enter Data: "; line <- getLine; let line2 = line ;putStr line2 } Fix 3: I might be happy to put ALL the semicolons at the beginning of lines, which also works, but you are not allowed a semicolon at the beginning of the first brace, so this looks asymmetric. f3 = do { putStr "Enter Data: " ;line <- getLine ;let line2 = line ;putStr line2 } Question: Is it possible to change the layout handling of Haskell slightly so that f1 is legal? Perhaps the explicit semicolon at the end of the let line could terminate the (implicit) layout of the let statement? Mark. Dr Mark Utting, Senior Lecturer Department of Computer Science School of Computing and Mathematical Sciences The University of Waikato Tel: +64 7 838 4791 Private Bag 3105 Fax: +64 7 858 5095 Hamilton Email: marku(a)cs.waikato.ac.nz New Zealand Web: http://www.cs.waikato.ac.nz/~marku It is a time-proven principle of software engineering to try and strengthen the static description of systems as much as possible. [Clemens Szyperski]

5 4

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