February 2002 - Haskell

ANNOUNCE: GHC 5.03.20020204 snapshot release
by Julian Seward (Intl Vendor) 08 Feb '02

08 Feb '02

There have been a number of significant improvements made to GHC since the 5.02 sources were branched off the main GHC development tree, but we're not quite ready to make a full 5.04 release yet. However, we're keen to get feedback on the new features from people that don't have easy access to CVS or don't have the time & patience to build GHC from scratch, so we're making a snapshot release of the current GHC, in source and binary form. There are NO GUARANTEES as to the stability of this release, although we do know it has passed our basic three-stage bootstrap test and run the regression tests successfully. In some cases the documentation hasn't been fully updated to reflect the new features yet. Briefly, the changes relative to 5.02.2 are: - The type system now supports arbitrary rank polymorphism, given appropriate type annotations. - Heap profiling has had a major overhaul and now supports retainer profiling and biographical profiling ala nhc98. - Major improvements to the native code generators. You can now compile any and all code through them, including the Prelude. - The FFI syntax has been updated to match the latest version of the FFI Haskell 98 Addendum. - newtypes support deriving *any* class for which the underlying type is also an instance. - Linear implicit parameters: a highly experimental feature. - GHCi has several new commands: - ':show bindings' to list the bindings made on the command line, - ':show modules' to show which modules are loaded, - ':module' has been enhanced as per the discussion on the mailing list (syntax is still experimental - feedback welcome). - ':browse' similar to Hugs' :browse command. And many other minor changes & bugfixes. At the moment there is just the sources and a binary build for x86-linux available. We may add builds for other if they become available. You can get it from http://haskell.cs.yale.edu/ghc/download_ghc_snapshot.html Enjoy! The GHC Development Team.

2 1

Final CfP: Calculemus 2002
by Calculemus 2002 08 Feb '02

08 Feb '02

--------------------------------------------------------------- We apologize if you receive multiple copies of this message. --------------------------------------------------------------- CALCULEMUS 2002 10^th Symposium on the Integration of Symbolic Computation Systems and Mechanized Reasoning In conjunction with AISC 2002 Marseille, France -- July 1th-5th, 2002 http://www.ags.uni-sb.de/~calculemus2002 About this conference series This is the tenth symposium in a series which started with three meetings in year 1996, two meetings in 1997 and then turned to a yearly event in 1998. It has become tradition to hold the meeting jointly with an event in either symbolic computation or automated deduction. This year's symposium is in conjunction with the AISC'2002 conference in Artificial Intelligence and Symbolic Computation. The aim of the symposium is to bring together researchers interested in both symbolic computation and mechanized reasoning. It has been recognized that the integration of computing and deduction would enhance the power of mathematical software systems. However it is not yet clear which is the right way to achieve such an integration. The symposium provides a forum for discussing and investigating the various approaches possible including integration of reasoning into computer algebra systems, integration of efficient computations in theorem provers, and frameworks, languages, or protocols for integrating both symbolic computation and mechanized reasoning. Other topics of interest include the integration of constraint solving techniques into both theorem provers and computer algebra systems, environments for hybrid mathematical systems and systems for explorative mathematics. Topics * Integration of Computer Algebra Systems and Automated Theorem Provers * Symbolic Computation Aspects in Mechanized Reasoning * Mechanized Reasoning Aspects of Symbolic Computation Systems * Combination of Logical and Formal Methods with Computer Algebra * Connections between formal and informal approaches to mathematics * Mathematical Software Buses and Protocols * Design Issues for Logic and Symbolic Computing Systems * Architectures and environments for integration of software components * Heterogenous reasoning/computing frameworks * Constraint Solving Aspects in ATP/CAS * Explorative Systems for doing Mathematics * Case studies and applications Papers on other topics with strong links to those described above will also be considered. Authors that wish to present material relating other AI techniques and symbolic computation should consider submitting with AISC. Authors are also encouraged to submit different material to both AISC and CALCULEMUS. Organizers of AISC'2002 / CALCULEMUS'2002 Both AISC'2002 and CALCULEMUS'2002 are organized by the three Universities of Marseille: L'universite de Provence (Aix-Marseille I), L'universite de la Miditerrannée (Aix-Marseille II), la Faculté des sciences de Saint-Jerome (Aix-Marseille III) and the LSIS laboratory. PROGRAM CHAIRS Olga Caprotti (RISC-Linz, Austria) Volker Sorge (Birmingham, United Kingdom) PROGRAM COMMITTEE Alessandro Armando (Genova, Italy) Christoph Benzmueller (Saarbruecken, Germany) Jacques Calmet (Karlsruhe, Germany) Alessandro Coglio (Kestrel Institute, United States) Arjeh Cohen (Eindhoven, The Netherlands) Simon Colton (Edinburgh, Scotland) James Davenport (Bath, United Kingdom) William M. Farmer (McMaster U., Canada) Therese Hardin (Paris VI, France) Hoon Hong (North Carolina State, United States) Manfred Kerber (Birmingham, United Kingdom) Michael Kohlhase (CMU, United States) Steve Linton (St. Andrews, Scotland) Ursula Martin (St. Andrews, Scotland) Julian Richardson (Heriot-Watt, Scotland) Renaud Rioboo (Paris VI, France) Roberto Sebastiani (Trento, Italy) Andrew Solomon (Sidney, Australia) Andrzej Trybulec (Bialystok, Poland) V. Weisspfenning (Passau, Germany) Wolfgang Windsteiger (RISC-Linz, Austria) LOCAL ORGANIZING COMMITTEE Gilles Audemard (Univ. de Provence, Aix-Marseille I) Belaid Benhamou (Chairman) (Univ. de Provence, Aix-Marseille I) Philippe Jegou (Univ. de Saint Jerome, Aix-Marseille III) Laurent Henocque(Chairman) (Univ. de la miditerrannée, Aix-Marseille II) Pierre Siegel (Univ. de Provence,Aix-Marseille I) Eric Wurbel (Univ. du Var, Toulon) SUBMISSION DETAILS Authors are invited to submit papers in the following categories: - Full research papers up to 12 pages describing original theoretical or applied research that has not been published elsewhere. - System descriptions of up to 5 pages describing new systems or significant upgrades of existing ones, especially including experiments. - Work in progess papers or position papers up to 12 pages. Submitted papers should be prepared following the LNCS guidelines (see http://www.springer.de/comp/lncs/authors.html) and submitted electronically by sending an e-mail to calculemus2001(a)ags.uni-sb.de, with header "CALCULEMUS-2002 SUBMISSION", containing as attachments the file of the paper (in either postscript of pdf format) and a compiled submission form. Please see the webpage for further details. We strongly encourage the author(s) to use LaTeX. Authors of accepted papers and system descriptions are expected to present their contribution at the symposium. Authors of system descriptions are expected to demonstrate their systems. DEADLINES Deadline for submission: February 22, 2002 Notification of acceptance: April 2, 2002 Camera-ready papers due: April 19, 2002 PROCEEDINGS Papers submitted to the symposium undergo a standard review process. Accepted research papers and system descriptions will be published in the Symposium's formal proceedings, which will be joint proceedings with AISC and published by Springer-Verlag. The work in progress and position papers will be published as informal proceedings in a technical report of the Saarland University. Both formal and informal proceedings will be available at the conference. The full paper versions of the very best papers will appear in a special issue of the Journal of Symbolic Computation. Addresses e-mail: calculemus2002(a)ags.uni-sb.de URL: http://www.ags.uni-sb.de/~calculemus2002 Surface mail: CALCULEMUS'2002 Volker Sorge School of Computer Science The University of Birmingham Birmingham, B15 2TT UK Phone number: +44-121-414-4769 Fax number: +44-121-414-4281

1 0

RE: Specifying Kinds of Types
by Simon Peyton-Jones 08 Feb '02

08 Feb '02

Yes. GHC already does this in interface files, and it'd be rather easy to make it do so in source programs too. It seems like the Right Thing to do. I'll do it. (John suggests going to kind polymorphism, but that would raise a bunch of new issues in GHC's impls so I won't do that. Yet.) Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 08 February 2002 11:26 | To: Haskell List | Subject: Specifying Kinds of Types | | | I'd like to be able to declare the kinds of new types and synonyms, | because sometimes Haskell can't infer them. For instance: | | data CMap0 p q = MkCMap0; | | Without evidence, Haskell assumes that p and q have kind '*' | (as per sec. | 4.6), and therefore CMap0 has kind '* -> * -> *'. Actually, I | wanted p | and q to both have kind '* -> *', giving CMap0 kind '(* -> *) | -> (* -> *) | -> *'. | | Here's another example: | | type Composer c = forall x y z. (c y z) -> (c x y) -> (c x z); | | Haskell gives x, y and z all the kind '*'. But I wanted them | to have kind | '* -> *', giving c the kind '(* -> *) -> (* -> *) -> *' and | Composer the | kind '(* -> *) -> (* -> *) -> * -> *'. | | It's not currently possible to specify kinds, is it? Actually I think | polymorphic kinds would be nice, but I can't say I | desperately need them. | I'd just like to be able to specify kinds somehow. For instance: | | data CMap0 (p ::: * -> *) (q ::: * -> *) = MkCMap0; | | ...or perhaps | | data ({* -> *} p,{* -> *} q) => CMap0 p q = MkCMap0; | | ...or whatever. | | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

Re: Specifying Kinds of Types
by John Hughes 08 Feb '02

08 Feb '02

Ashley Yakeley wrote: I'd like to be able to declare the kinds of new types and synonyms, because sometimes Haskell can't infer them. For instance: data CMap0 p q = MkCMap0; Without evidence, Haskell assumes that p and q have kind '*' (as per sec. 4.6), and therefore CMap0 has kind '* -> * -> *'. Actually, I wanted p and q to both have kind '* -> *', giving CMap0 kind '(* -> *) -> (* -> *) -> *'. I'll second that! I've had to use the likes of data CMap0 p q = MkCMap0 | forall a. Unused (p (q a)) in the past, but this is ugly and doesn't work for type or newtype. And of course, next time you have to call the constructor Unused2 or UnusedCMap0 or whatever to avoid a name clash... It's not currently possible to specify kinds, is it? Actually I think polymorphic kinds would be nice, but I can't say I desperately need them. The nicest thing about polymorphic kinds would be that we wouldn't NEED to specify them: kind inference would produce the principal kind, and you can't do better than that. I assume it will be a while before we start wanting rank-2 polykindism! Compilers already do kind inference, and presumably explicitly set uninstantiated kind variables to * at some stage. Maybe generalising them instead would be a simple modification and language extension that would solve this kind of problem. John Hughes

1 0

Specifying Kinds of Types
by Ashley Yakeley 08 Feb '02

08 Feb '02

I'd like to be able to declare the kinds of new types and synonyms, because sometimes Haskell can't infer them. For instance: data CMap0 p q = MkCMap0; Without evidence, Haskell assumes that p and q have kind '*' (as per sec. 4.6), and therefore CMap0 has kind '* -> * -> *'. Actually, I wanted p and q to both have kind '* -> *', giving CMap0 kind '(* -> *) -> (* -> *) -> *'. Here's another example: type Composer c = forall x y z. (c y z) -> (c x y) -> (c x z); Haskell gives x, y and z all the kind '*'. But I wanted them to have kind '* -> *', giving c the kind '(* -> *) -> (* -> *) -> *' and Composer the kind '(* -> *) -> (* -> *) -> * -> *'. It's not currently possible to specify kinds, is it? Actually I think polymorphic kinds would be nice, but I can't say I desperately need them. I'd just like to be able to specify kinds somehow. For instance: data CMap0 (p ::: * -> *) (q ::: * -> *) = MkCMap0; ...or perhaps data ({* -> *} p,{* -> *} q) => CMap0 p q = MkCMap0; ...or whatever. -- Ashley Yakeley, Seattle WA

5 4

Re: Specifying Kinds of Types
by Lennart Augustsson 08 Feb '02

08 Feb '02

> data CMap0 (p ::: * -> *) (q ::: * -> *) = MkCMap0; Or data (CMap0 :: (* -> *) -> (* -> *) -> *) = MkCMap0 -- Lennart

1 0

Re: type inference
by Ashley Yakeley 08 Feb '02

08 Feb '02

At 2002-02-07 15:39, ilje wrote: >Question: >For what reason we need the "Type inference" if we can enforce "Type >constraints" ????? I think it just makes it easier for the programmer if they don't have to write type signatures everywhere. Of course sometimes Haskell can't infer types and then you have to put them in. -- Ashley Yakeley, Seattle WA

1 0

Jan Skibinski's lhs modules ?
by Wilhelm B. Kloke 08 Feb '02

08 Feb '02

As the site www.numeric-quest.com does not respond to my queries, I would like to ask the community, where I can find a collection of the modules QuantumVector.lhs etc. ? -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

1 0

String manipulation.
by DK 08 Feb '02

08 Feb '02

Hello. First of all I am a beginner in Haskell, and I must confess I do not yet fully understand it. I need to write a program in Haskell, though, and I am having some difficulties... What I would like to ask, is how can I take a string from a list, and manipulate it, in order to convert it to an integer. Any help would be very appreciated. Thank you very much, Dimitris

3 2

type inference
by ilje 08 Feb '02

08 Feb '02

Hi Question: For what reason we need the "Type inference" if we can enforce "Type constraints" ????? Thanks in advance.

1 0