November 2002 - Haskell

Report and web site
by Iavor S. Diatchki 12 Nov '02

12 Nov '02

hi, now that the report is pretty much stable, are there any plans of putting it on the Haskell web site? bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

2 1

HC&A Report: "Haskell 98 Report" copyright
by Ian Lynagh 12 Nov '02

12 Nov '02

Hi all, I note with some sadness the more restrictive license that may be placed on the "Haskell 98 Report", as reported by the HC&A. The great openness/freeness of haskell, both the report and implementations, is, IMO, one of its most important features. I have just grabbed a copy of the latest revised report under the current licence. AIUI I can continue to publish this under the current licence and, assuming I change the name, incorporate any fixes etc (assuming the fixers agree to it). Also, Debian can continue to have a copy in main in the same way. I would really prefer it if such forking wasn't necessary, but if the above is the case (I am not a lawyer, etc etc) then I guess it isn't the end of the world - I must admit to not seeing what CUP would be getting out of it if this is so, though. Ian

4 3

ANNOUNCE: HC&A Report (3rd edition, November 2002)
by C.Reinke 11 Nov '02

11 Nov '02

The many contributors and I are happy to announce that the Haskell Communities and Activities Report (3rd edition, November 2002) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in several formats: in PDF (with working links and index, yet printable) or, for those who have problems with the PDF, in HTML (using John's secret weapon again) and Postscript. A big thanks here to everyone who contributed information to the report! I hope you will find it as interesting to read as we did. For those of you who haven't heard of these reports before: The first edition of the HC&A Report was released in November 2001, with the goal of helping to improve the communication between the various groups, projects, and individuals working on or with Haskell. The idea of these reports is simple: Every six months, a call goes out to all of you to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and well in time for the deadline;-) to the call. I then collect all these into a single report and feed it back to this very mailing list. And when we try for the next update in six months, you might want to add your own work, project, research area or group as well. So, please, put that item into your diary now: End of April 2003: target deadline for contributions to the May 2003 edition of the HC&A Report Enjoy (and communicate;-)! Claus Reinke -- Computing Laboratory University of Kent at Canterbury http://www.cs.ukc.ac.uk/people/staff/cr3/

1 0

New Strafunski packages released
by Ralf Laemmel 10 Nov '02

10 Nov '02

New Strafunski packages released -------------------------------- Strafunski is a Haskell-centred bundle that provides support for generic programming and language processing. Strafunski is based on the notion of a functional strategy --- first-class generic functions that can traverse into terms while mixing uniform and type-specific behaviour. This is the 3rd release of Strafunski with the following improvements: - StrategyLib extended by several themes, e.g., for metrics. - Added Sdf2Haskell package for mapping syntaxes to datatypes. - Cobol, Java, and Haskell meta-programming examples included. - Haskell ATermLib integrated. - Sample code from the following papers integrated: - PADL 2003: A Strafunski application letter - RULE 2002: Towards Generic Refactoring - WRS 2002: The Sketch of a Polymorphic Symphony - DrIFT-Strafunski supports a number of additional models. Documentation, papers, and downloads are now available from: http://www.cs.vu.nl/Strafunski A good entry point for contemporary Strafunski is: A Strafunski Application Letter (PADL 2003) See http://www.cwi.nl/~ralf/padl03/ It demonstrate that typed functional programming in Haskell, augmented with Strafunski's support for generic traversal and external components, is very appropriate for the development of practical language processors. In particular, Strafunski is used for Cobol reverse engineering, Java code metrics, and Haskell re-engineering. Feedback is very much appreciated, and can be directed to the authors: * Ralf Laemmel (ralf(a)cwi.nl) * Joost Visser (Joost.Visser(a)cwi.nl) Have fun!

1 0

Announcement: Alex has a new home
by Chris Dornan 10 Nov '02

10 Nov '02

Announcement: Alex under new license and management. Alex, the Haskell-based scanner-generator, has been relicensed with a BSD-style license (it was under the GPL) in preparation for integration with Happy, the Haskell-based parser generator. Isaac Jones has kindly and heroically undertaken this task of integrating the two packages. As the two packages work quite well as they are it is expected that the first release of the combined packages will do little more than bundle them together, but we have ambitions to go further, and to better adapt the run-time behaviour of Alex-generated scanners to suit the big Haskell compilers such as GHC. Until the integration has been completed the new home for Alex is http://www.syntaxpolice.org/~ijones/alex/ Please email Isaac (ijones(a)syntaxpolice.org) if you have any queries. Cheers, Chris Dornan cdornan(a)arm.com

1 0

want better error msg with Class Read
by Johannes Waldmann 07 Nov '02

07 Nov '02

Dear all, I would welcome some advice on getting better error messages when using read :: Read a => a The problem is, `readsPrec' (the class method) eats the longest feasible input prefix, but when I call `read' (built-in prelude function) on a string that does not parse, but that has a valid prefix, I get this: > Inter> readsPrec 0 "1 ) " :: [(Integer,String)] > [(1," ) ")] > Inter> read "1 )" :: Integer > > Program error: Prelude.read: no parse This is correct, but I would like to show (in the error message) the prefix that *was* parsed as well. If `read' was a class method, I could override it. (Compare class Show, where there is the method `showsPrec', but since H98 (?), `show' is a class method as well.) In my application, the type to parse is not Integer, but some expression type that might contain parentheses. Its Read instance uses the Parsec library, but I think this is irrelevant to the above question. Best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/207 --

4 5

RE: Module re-exportation weekend puzzler
by Simon Peyton-Jones 06 Nov '02

06 Nov '02

Thomas, Iavor, Thanks for your message. | Are you saying that you think the report doesn't fully define the | meaning of the module system, or just that difficult to understand and | needs to be clarified? The former, and hence it ought to be clarified. But after contemplating your message, your fine formal specification, and then looking at the Report again, I conclude that my proposed fix was wrong. (I elaborate below.) The current wording is this: | The form "module M" names the set of all entities whose | unqualified name, e, is in scope, and for which the qualified | name M.e is also in scope and refers to the same entity as e. What is un-clear about this is the phrase "...for which the qualified name M.e is also in scope and refers to e". Unclear because it could be read as saying EITHER: that M.e can refer unambiguously only to this one entity, OR: that e is in scope under the name M.e (but M.e could be ambiguous) Either would make sense, but the latter is both more symmetrical (see Cambridge1 vs Cambridge2 below) and matches your formal spec (from which we should not lightly deviate). So I am happy to adopt your interpretation, but I'd like to clarify the wording. Here's an alternative sentence: The form "module M" names the set of all entities that are in scope with both an unqualified name 'e' and a qualified name 'M.e'. Would that be better? Can you suggest anything else? Simo If anyone else is interested, I'll elaborate Thomas and Iavor's example slightly: | module Cambridge1(module Simon) where | import PJ as Simon | import qualified Marlow as Simon | | module Cambridge2(module Simon) where | import PJ as Simon | import Marlow | | module Cambridge3(module Simon) where | import PJ as Simon | import Marlow as Simon | | module Marlow where | simon = "Simon Marlow" | | module PJ where | simon = "Simon PJ" So in Cambridge1 'simon' is unambiguous 'Simon.simon' is ambiguous But in Cambridge2 'simon' is ambiguous 'Simon.simon' is unambiguous In Cambridge 3 both are ambiguous The spec as it stands says that the export item 'module M' identifies those items x that are in scope both as 'x' and as 'M.x'. In both Cambridge1 and Cambridge2, there is only one such entity, so both are legal. (The fix I proposed yesterday would render Cambridge1 illegal.) In Cambridge3, the rule would specify that both entities "simon from module PJ" and "simon from module Marlow" are identified by 'module Simon'. And that is illegal because of the last clause of 5.2 specifies that one cannot export two entities with the same unqualified name.

2 1

FM03 Call for Papers - Preliminary
by mailinglist-admin＠fmeurope.org 06 Nov '02

06 Nov '02

CALL FOR PAPERS FM 2003 The 12th International FME Symposium Pisa, Italy - September 8-14, 2003 http://fme03.isti.cnr.it FM 2003 is the twelfth in a series of symposia organized by Formal Methods Europe, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. These symposia have been notably successful in bringing together a community of users, researchers, and developers of precise mathematical methods for software development as well as industrial users. Formal methods have been controversial throughout their history, and the realization of their full potential remains, in the eyes of many practitioners, merely a promise. Have they been successful in industry? If so, under which conditions? Has any progress been made in dispelling the skepticism that surrounds them? Are they worth the effort? Which aspects of formal methods have become so well established in the industrial practices to loose the "formal method" label in the meanwhile? FM 2003 aims to answer these questions, by seeking contributions not only from the Formal Methods community but also from outsiders and even from skeptical people who are most welcome to explain, document, and motivate the source of their reluctance. We are confident that a wide spectrum of experiences and a loyal contrasting of opinions will foster a better and deeper understanding, if not a wider adoption of Formal Methods. Far from restricting the focus of the conference, however, FM 2003 also welcomes papers with strong theoretical content that establish a connection with the practice of formal methods. Therefore, FM 2003 welcomes papers in all aspects of formal methods for computer systems, including the following: -introducing formal methods in the practice of industrial processes (technical, organizational, social, psychological aspects) - concerns and risks for potential adopters of formal methods; cost-benefit analysis - reports on practical use and case studies (reporting positive or negative experiences) - formal methods in hardware and system design - reusable domain theories - theoretical foundations (specification and modeling, refining, verification, etc.) - tool support and software engineering - environments for formal methods - method integration Papers Full papers should be submitted electronically via the Web by March 7, 2003. Full submission details will be published on the conference web site. Papers will be evaluated by the Program Committee according to their originality, significance, soundness, quality of presentation and relevance with respect to the main issues of the symposium. Papers should have not been submitted elsewhere for publication. Accepted papers will be published in the symposium proceedings in the LNCS series by Springer Verlag. Papers should not exceed twenty pages, although longer papers will be considered if their content justifies it. LNCS format should be used. Please include a short list of keywords on a separate line at the end of the abstract, beginning with the word "Keywords:" in boldface. Other symposium activities In addition to presentations of submitted papers, the symposium will offer half-day or full-day tutorials, one-day or two-days workshops, invited speakers, and tool demonstrations with presentations. Please send your proposals for tutorials/workshops/tool exhibitions to the related chairs by the deadlines indicated below. For full details of what is required, whom to contact, etc, see the web site http://fme03.isti.cnr.it, or send your query to fme03(a)isti.cnr.it. Submission Deadlines March 7, 2003: Papers (firm deadline) March 7, 2003: Workshop/tutorial proposals May 9, 2003: Tool Exhibition proposals June 8, 2003: Papers' final version Acceptance Notifications March 20, 2003: Tutorials/workshops May 9, 2003: Papers June 8, 2003: Tool Exhibition =========================================================================== Stefania Gnesi IEI-CNR tel: +39 050 3152918 Area della Ricerca CNR mobile: +39 348 8283128 VIA G. MORUZZI, 1 fax: +39 050 3152810 I-56124 PISA (Italy) e-mail: gnesi(a)iei.pi.cnr.it http://matrix.iei.pi.cnr.it/FMT/ http://rep1.iei.pi.cnr.it/~gnesi/ =========================================================================== _______________________________________________ Mailinglist mailing list Mailinglist(a)fmeurope.org http://www.fmeurope.org/mailman/listinfo/mailinglist

1 0

RE: Module re-exportation weekend puzzler
by Simon Marlow 06 Nov '02

06 Nov '02

> The meaning of "module M" in export lists is rather subtle, and the > above reformulation (or the one-word change) seems to make a subtle > change to it. It is not just a clarification. Is that what > you intend?! It depends, I guess, on your interpretation of the report as it stands. It wasn't clear to me whether it is legal to export an entity, using the 'module M' syntax, whose qualified name is ambiguous. Admittedly, if I'd checked your specification I'd have noticed that your interpretation differed from mine, sorry about that. Nevertheless, since there are two interpretations, the report should clarify which one is meant. > A nice aspect of our formal semantics is that the computation of the > exports and inscope relations, which includes fixpoint > iteration to give > meaning to recursive modules, and the error checking can be kept > separate. The change proposed above means that the error > checking has to > be integrated with the fixpoint iteration (or that the fixpoint > iteration has to return more than the resulting inscope/export > relations), and thus complicates the specification. Ok, that sounds like a good reason to prefer your current interpretation. Cheers, Simon

1 0

RTA'03: call for papers
by Femke van Raamsdonk 06 Nov '02

06 Nov '02

The call for papers for RTA'03 might be relevant for the readers of the Haskell lists since papers on applications of rewriting are explicitly invited. ******************************************* ****************************** * * * RTA'03 CALL FOR PAPERS * * * ****************************** http://www.dsic.upv.es/~rdp03/rta The 14th International Conference on Rewriting Techniques and Applications (RTA'03) will be part of the Federated Conference on Rewriting Deduction and Programming (RDP'03). IMPORTANT DATES: * January 15 2003 electronic submission of title + abstract * January 22 2003 electronic submission of papers * March 15 2003 notification of acceptance * April 7 2003 final version of accepted papers * June 9-11 2003 RTA'03 * June 8-14 2003 RPD'03 RTA is the major forum for the presentation of research on all aspects of rewriting. Typical areas of interest include (but are not limited to): * APPLICATIONS: case studies; (rule-based) programming; symbolic and algebraic computation; theorem proving; system synthesis and verification; proof checking. * FOUNDATIONS: matching and unification; completion techniques; strategies; constraint solving; explicit substitutions. * FRAMEWORKS: string, term, and graph rewriting; lambda-calculus and higher-order rewriting; proof nets; constrained rewriting/deduction; categorical and infinitary rewriting. * IMPLEMENTATION: compilation techniques; parallel execution; rewriting tools. * SEMANTICS: equational logic; rewriting logic. RTA'03 PROGRAM COMMITEE: Harald Ganzinger (Max-Planck-Institut) Claude Kirchner (Nancy) Salvador Lucas (Valencia) (Conference Chair) Chris Lynch (Clarkson) Jose Meseguer (Urbana) Robert Nieuwenhuis (Barcelona) (Program Chair) Tobias Nipkow (Munich) Vincent van Oostrom (Utrecht) Christine Paulin (Paris-sud) Frank Pfenning (Carnegie Mellon) Mario Rodriguez-Artalejo (Madrid) Sophie Tison (Lille) Ashish Tiwari (SRI) Andrei Voronkov (Manchester) Hantao Zhang (Iowa) RTA'03 SUBMISSIONS: Submissions must be original and not submitted for publication elsewhere. Submission categories include regular research papers and system descriptions. Also problem sets and submissions decribing interesting applications of rewriting techniques will be very welcome. As usual, accepted papers will appear in the Springer-Verlag Lecture Notes series. More information about paper submission will be available at the RDP'03 web page http://www.dsic.upv.es/~rdp03/

1 0