- Haskell - Haskell.org

RE: Fixity declarations
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

Current wording is "A fixity declaration may appear anywhere that a type signature appears and, like a type signature, declares a property of a particular operator. Also like a type signature, a fixity declaration can only occur in the same declaration group as the declaration of the operator itself, and at most one fixity declaration may be given for any operator." Indeed, you can't give either a type signature or a fixity declaration for a pattern-bound variable. (By pattern-bound I include case expressions, function left hand sides etc.) Would it really help to say that you can't give a fixity for a pattern-bound variable? (After all, there are many other things you can't do.) If so, should we not say the same about type signatures? Are there other things that you can't do that should be identified? Simon | -----Original Message----- | From: Koen Claessen [mailto:koen@cs.chalmers.se] | Sent: 12 July 2001 17:00 | To: The Haskell Mailing List | Subject: Fixity declarations | | | Hi all, | | The topic is fixity declarations for operators. | | The report says: | | "Fixity is a property of a particular entity (constructor | or variable), just like its type; fixity is not a | property of that entity's name." | | It is possible to define fixities for locally declared | bindings: | | f x y z = x # y # z | where | infixr 4 # | a # b = a `div` b | | The use of (#) in the body of g is right associative. | | However, it is not possible to define the fixity of an | operator which is an argument to a function. If I define: | | foldr4 :: (a -> b -> b) -> b -> (a,a,a,a) -> b | foldr4 (#) z (a,b,c,d) = a # b # c # d # z | | I will have to put in parentheses explicitly, because it is | not possible to define the fixity of that entity (namely the | argument (#) to foldr4). | | In this case, (#) gets the default fixity, namely infixl 9. | | Apart from the fact if we want to allow this or not, I think | the report should be clear about that it is not possible to | define the fixities of locally bound operator names in this way. | | /Koen. | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

RE: Another question wrt hiding imports
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

See Section 4.4.2, after the table. Does that answer the qestion? Simon | -----Original Message----- | From: S. Alexander Jacobson [mailto:alex@shop.com] | Sent: 12 July 2001 15:03 | To: wlux(a)uni-muenster.de | Cc: haskell(a)haskell.org | Subject: Re: Another question wrt hiding imports | | | I asked this a while ago and never got an answer. Asking | again in better context: | | How do you control importing operator precedence? | | Suppose that you have: | f x = 2 + 2 * x | | And an imported module increases the precedence of (+). | You end up getting mangled. | | My assumption is that the only way to protect yourself from | this is to import qualified so A.+ has a different precedence from +. | | But I don't think the report promises this. The report just | promises that A.+ has the same precedence as (+) inside module A. | | -Alex- | | ___________________________________________________________________ | S. Alexander Jacobson Shop.Com | 1-646-638-2300 voice The Easiest Way To Shop (sm) | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

Re: Another question wrt hiding imports
by Wolfgang Lux 12 Jul '01

12 Jul '01

"Simon Peyton-Jones" wrote > | For instance if a have > | > | module A where > | data T = A | B > | > | which entities are imported when I include the declaration > | > | import A hiding(T) > | > | in a module? The report is not clear about this but I would > | expect that > | this imports data constructors A and B into the current > | module but not > | the type constructor T > > Yes, that's right. Why is the report not clear? More precisely, how > could I improve it? I find it a little bit counterintuitive to be able to hide a type constructor but not its data constructors (in particular) because one cannot import a data constructor by simply giving its name in an import specification. Maybe a single sentence which explicates the fact that hiding(T) only hides the type constructor T but not any of the data constructors of T (except if T is also a data constructor in this or any another data type) is sufficient to make this clear. (But maybe I was particularly dumb in this case). Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux(a)uni-muenster.de

1 0

RE: Another question wrt hiding imports
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

| For instance if a have | | module A where | data T = A | B | | which entities are imported when I include the declaration | | import A hiding(T) | | in a module? The report is not clear about this but I would | expect that | this imports data constructors A and B into the current | module but not | the type constructor T Yes, that's right. Why is the report not clear? More precisely, how could I improve it? | However, if this is true it is possible to export data constructors | without their type via | | module B(module A) where | import A hiding(T) Indeed so. | which contradicts the statement in section 5.2 on p.64, that the form | module m is equivalent to listing all entities imported from that | module, because I cannot list a data constructor (without its | type) in an export specification. Well I suppose I could add "if possible" to the statement that it's equivalent to listing all the entities. Yes it's a little strange, but it's a very dark corner and I don't propose to poke in it! I suspect it may be more confusing than helpful to elaborate the exception in 5.2. Simon

1 0

RE: infelicity in module imports
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

| The behaviour I think you're describing seems by far the most | useful thing do and the description in the report is now very | clear, so this isn't an issue with anything you're proposing, | just a observation that 'GHC implements it' isn't yet quite true. True -- I'm fixing that as we speak. Simon

1 0

RE: infelicity in module imports
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

| I have often tried, but never succeeded, to understand what | the report says and at the same time unify it with what the | particular compiler I was using actually implemented. Could I ask you to try one more time, with the current draft report? available at http://research.microsoft.com/~simonpj/haskell98-revised I have tried hard to make it easy to understand. I am sure the result is not perfect. If it is not fairly easy to answer your questions below by reading the text, then I would like to improve the text. Can you suggest ways in which it could be made clearer? I've filled in the answers to each of your examples. Simon | Namely what happens in each of the following cases: | Where A is a module exporting the names x, y, p, q, v, w. | import A x, y, p, q, v, w A.x, A.y, A.p, A.q, A.v, A.w | import A() nothing is imported, except instance declarations | import A(x,y) x, y, A.x, A.y | import qualified A A.x, A.y, A.p, A.q, A.v, A.w | import qualified A() nothing is imported, except instance declarations | import qualified A(x,y) A.x A,y | import A hiding () same as import A | import A() hiding () syntactically illegal | import A(x,y) hiding () syntactically illegal | import A hiding (p,q) x, y, v, w A.x, A.y, A.v, A.w | import A() hiding (p,q) syntactically illegal | import A(x,y) hiding (p,q) syntactically illegal | import qualified A hiding () same as import qualified A | import qualified A() hiding () syntactically illegal | import qualified A(x,y) hiding () syntactically illegal | import qualified A hiding (p,q) A.x, A.y, A.v, A.w | import qualified A() hiding (p,q) syntactically illegal | import qualified A(x,y) hiding (p,q) syntactically illegal | | Honestly, in some of these case I do not understand if 1) it | is legal syntax, and if so, 2) what happens, and, if not so, | 3) why not.

2 1

CFP ESSLLI02 (Trento, Italy)
by Claire Gardent 12 Jul '01

12 Jul '01

[An HTML version of the Call for Proposals is available via the FoLLI page <http://www.folli.uva.nl/Esslli/2002/cfp.txt>. Usual apologies apply if you receive multiple copies of this message.] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Fourteenth European Summer School in Logic, Language and Information ESSLLI-2002 August 4-17, 2002, Trento, Italy %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% THIRD CALL FOR PROPOSALS ------------------------ **** Deadline for submission: 22 July 2001 ***** The main focus of the European Summer Schools in Logic, Language and Information is on the interface between linguistics, logic and computation. Foundational, introductory and advanced courses together with workshops cover a wide variety of topics within the three areas of interest: Language and Computation, Language and Logic, and Logic and Computation. Previous summer schools have been highly successful, attracting up to 500 students from Europe and elsewhere. The school has developed into an important meeting place and forum for discussion for students and researchers interested in the interdisciplinary study of Logic, Language and Information. ESSLLI-2002 is organised under the auspices of the European Association for Logic, Language and Information (FoLLI). The ESSLLI-2002 Programme Committee invites proposals for foundational, introductory, and advanced courses, and for workshops for the 14th annual Summer School on a wide range of topics in the following fields: LANGUAGE & COMPUTATION LANGUAGE & LOGIC LOGIC & COMPUTATION In addition to courses and workshops there will be a Student Session. A Call for Papers for the Student Session will be distributed separately. PROPOSAL SUBMISSION: Proposals should be submitted through a web form located at <http://www.folli.uva.nl/Esslli/2002/submission.html> All proposals should be submitted no later than July 22, 2001. Authors of proposals will be notified of the committee's decision no later than September 17, 2001. Proposers should follow the guidelines below while preparing their submissions; proposals that deviate can not be considered. GUIDELINES FOR SUBMISSION: Anyone interested in lecturing or organising a workshop during ESSLLI-2002, please read the following information carefully. ALL COURSES: Courses are taught by 1 or max. 2 lecturers. They typically consist of five sessions (a one-week course) or ten sessions (a two-week course). Each session lasts 90 minutes. Timetable for Course Proposal Submission: Jul 22, 2001: Proposal Submission Deadline Sep 17, 2001: Notification Nov 15, 2001: Deadline for receipt of title, abstract, lecturer(s) information, course description and prerequisites Jun 1, 2002: Deadline for receipt of camera-ready course material FOUNDATIONAL COURSES: These are really elementary courses not assuming any background knowledge. They are intended for people to get acquainted with the problems and techniques of areas new to them. Ideally, they should allow researchers from other fields to acquire the key competences of neighbouring disciplines, thus encouraging the development of a truly interdisciplinary research community. Foundational courses may presuppose some experience with scientific methods in general, so as to be able to concentrate on the issues that are germane to the area of the course. INTRODUCTORY COURSES: Introductory courses are central to the activities of the Summer School. They are intended to equip students and young researchers with a good understanding of a field's basic methods and techniques. Introductory courses in, for instance, Language and Computation, can build on some knowledge of the component fields; e.g., an introductory course in computational linguistics should address an audience which is familiar with the basics of linguistics and computation. Proposals for introductory courses should indicate the level of the course as compared to standard texts in the area. ADVANCED COURSES: Advanced courses should be pitched at an audience of advanced Masters or PhD students. Proposals for advanced courses should specify the prerequisites in some detail. WORKSHOPS: The aim of the workshops is to provide a forum for advanced Ph.D. students and other researchers to present and discuss their work. A workshop has a theme. At most one organiser is paid. The organisers should be specialists in the theme of the workshop and give a general introduction in the first session. They are also responsible for the programme of the workshop, i.e., for finding speakers. Each workshop organiser will be responsible for producing a Call for Papers for the workshop by November 15, 2001. The call must make it clear that the workshop is open to all members of the LLI community. It should also note that all workshop contributors must register for the Summer School. A workshop consists of five sessions (a one-week workshop) or ten sessions (a two-week workshop). Sessions are normally 90 minutes. Timetable for Workshop Proposal Submissions Jul 22, 2001: Proposal Submission Deadline Sep 15, 2001: Notification Nov 15, 2001: Deadline for receipt of Call for Papers Dec 1, 2001: Send out Call for Papers Mar 15, 2002: Deadline for Papers (suggested) May 1, 2002: Notification of Workshop Contributors (suggested) May 15, 2002: Deadline for Provisional Workshop Programme Jun 1, 2002: Deadline for receipt of camera-ready copy of Workshop notes Jun 1, 2002: Deadline for Final Workshop Programme FORMAT FOR PROPOSALS: The web-based form for submitting course and workshop proposals is accessible at <http://www.folli.uva.nl/Esslli/2002/submission.html>. You will be required to submit the following information: * Name (name(s) of proposed lecturer(s)/organiser) * Address (contact addresses of proposed lecturer(s)/organiser; where possible, please include phone and fax numbers) * Title (title of proposed course/workshop) * Type (is this a workshop, a foundational course, an introductory course, or an advanced course?) * Section (does your proposal fit in Language & Computation, Language & Logic or Logic & Computation? name only one) * Description (describe the proposed contents in at most 150 words) * External funding (will you be able to find external funding to help fund your travel and accommodation expenses? if so, how?) * Further particulars (any further information that is required by the above guidelines should be included here) FINANCIAL ASPECTS: Prospective lecturers and workshop organisers should be aware that all teaching and organising at the summer schools is done on a voluntary basis in order to keep the participants fees as low as possible. Lecturers and organisers are not paid for their contribution, but are reimbursed for travel and accommodation. Please note the following: In case a course is to be taught by two lecturers, a lump sum is paid to cover travel and accommodation expenses. The splitting of the sum is up to the lecturers. However, please note that the organisers highly appreciate it if, whenever possible, lecturers and workshop organisers find alternative funding to cover travel and accommodation expenses. Workshop speakers are required to register for the Summer School; however, workshop speakers will be able to register at a reduced rate to be determined by the Organising Committee. Finally, it should be stressed that while proposals from all over the world are welcomed, the Summer School can in general guarantee only to reimburse travel costs for travel from destinations within Europe to Trento. Exceptions will be made depending on the financial situation. PROGRAM COMMITTEE: Claire Gardent (chair) Attn: ESSLLI-2002 LORIA BP 239 Campus Scientifique 54506 Vandoeuvre-les-Nancy (France) Tel: +33-3-83-59-2039 Fax: +33-3-83-27-5652 Email: claire.gardent(a)loria.fr Local co-chair: Paolo Bouquet (bouquet(a)cs.unitn.it) Language & Computation: Hinrich Schuetze (me(a)hinrichschuetze.com) Gerry Altmann (g.altmann(a)psych.york.ac.uk) Language & Logic: Fabio Pianesi (pianesi(a)irst.itc.it) Steve Pulman (stephen.pulman(a)somerville.ox.ac.uk) Logic & Computation: Simon Parsons (S.D.Parsons(a)csc.liv.ac.uk ) Frank Wolter (wolter(a)informatik.uni-leipzig.de) ORGANISING COMMITTEE: Luciano Serafini (chair) Email: serafini(a)itc.it FURTHER INFORMATION: To obtain further information, visit the web site for ESSLLI-2002 <http://www.folli.uva.nl/Esslli/2002/esslli-2002.html>. For this year's summer school, please see the web site for ESSLLI-2001 <http://www.helsinki.fi/esslli>.

1 0

LPAR 2001 Last CFP
by Robert Nieuwenhuis 11 Jul '01

11 Jul '01

[Apologies for multiple copies] LPAR 2001 8th International Conference on LOGIC for PROGRAMMING, AI and REASONING LAST CALL FOR PAPERS General Information: LPAR 2001 will be held in Havana, Cuba, December 3-7, 2001. In conjunction will take place the 2nd International Workshop on Implementation of Logics. Another workshop will be announced soon (see http://www.lsi.upc.es/~roberto/lpar2001.html) LPAR Topics: * logic in srtificial intelligence * automated reasoning * lambda and combinatory calculi * interactive theorem proving * constructive logic and type theory * implementations of logic * computional interpretations of logic * design of logical frameworks * logical foundations of programming * program & system verification * logical aspects of concurrency * model checking * program extraction from proofs * rewriting * linear logic * logic programming * modal and temporal logics * constraint programming * knowledge representation & reasoning * logic and databases * reasoning about actions * logic & computational complexity * description logics * specification using logics * nonmonotonic reasoning Both "theoretical" papers and "experimental" papers are welcome. The first category is intended to contain new theoretical results, the second one to describe implementations of systems, to report experiments with implemented systems, or to compare implemented systems. Programme Committee: Franz Baader (RWTH Aachen) Deepak Kapur (Univ. New Mexico) Maurice Bruynooghe (C.Univ Leuven) Hans Kleine Buening (Univ. Paderborn) Jan Van den Bussche (Limburg Univ) Maurizio Lenzerini (Univ. di Roma) Thierry Coquand (Goteborg Univ.) Giorgio Levi (Univ. Pisa) Patrick Cousot (ENS Paris) Fabio Massacci (Univ. Siena) Nachum Dershowitz (Tel Aviv Univ.) Robert Nieuwenhuis (Barcelona), co-chair Javier Esparza (TU Munich) Tobias Nipkow (TU Munich) Alan Frisch (Univ. of York) Mitsuhiro Okada (Keio University) Harald Ganzinger (Max-Planck-Inst) Leszek Pacholski (Univ. of Wroclaw) Georg Gottlob (TU Wien) Frank Pfenning (Carnegie Mellon) Jean Goubault (ENS Cachan) Michel Parigot (Paris 7) John Harrison (Intel) Maarten de Rijke (Univ. of Amsterdam) Neil Immerman (Massachusetts) Natarajan Shankar (SRI International) Neil Jones (DIKU Univ. Copenhagen) Wolfgang Thomas (RWTH Aachen) Jean-Pierre Jouannaud (Paris-Sud) Moshe Vardi (Rice University) Andrei Voronkov (Manchester), co-chair Organizing Committee: * Luciano Garcia (University of La Habana) * Andrei Voronkov (University of Manchester) Important dates: Submission: July 15 Notification: September 25 Final version: October 12 Conference: December 3-7 Paper submission: Submitted papers must be original and not submitted concurrently for publication to a journal or to another conference. The proceedings of LPAR'2001 will be published by Springer-Verlag in the LNAI series and available at the conference. Submitted "theoretical" papers should not be longer than 15 proceedings pages; "experimental" papers should not be longer than 10 proceedings pages. Instructions for submission are on the LPAR web page: http://www.lsi.upc.es/~roberto/lpar2001.html.

1 0

IEEE Conf.on Software Maintenance Italy,Florence, ICSM2001
by icsm2001 11 Jul '01

11 Jul '01

Dear Colleague I would like to invite you to attend the IEEE International Conference on Software Maintenance, 2001, and associated workshops: IEEE SCAM, IEEE WESS, IEEE WSE, TABOO. FLORENCE, ITALY, 6-10 November 2001 http://www.dsi.unifi.it/icsm2001 Sponsored by IEEE Supported bt the: EC-IST, University of Florence, O-Groupi, IBM Italy in collaboration with: TABOO, AICA, AIIA, ERCIM, UNINFO, CESVIT, ... ICSM is the major international conference in the field of software and systems maintenance, evolution, and management. Theme: Systems and Software Evolution in the era of the Internet kEYWORDS: software evolution, embedded suystems, program analysis, reengineering, managment, maintenance, lyfe cycle, Internet and distributed systems, Multimedia systems, User interface evolution, Commercial off-the-shelf (COTS), Program comprehension, Formal methods, Empirical studies, Testing and regression testing, Measurement of software, METRICS,etc. Outstanding Keynotes such as: Prof. David Lorge Parnas and Prof. Dieter Rombach. Kent Beck 110 technical presentations, 4 workshops, Industrial papers and experiences, reseach papers and award, tutorials, tool expositions, dissertation forum and award, workshops, panels, and other exciting activities have been planned. Please forward the following to anybody who you think may be interested. The discount for the advanced registration fee will be active for few weeks. Apologies for multiple receptions. If you would like to be removed from our list please send an email to icsm2001(a)dsi.unifi.it with REMOVE in the subject. Paolo Nesi (ICSM2001 General Chair)

1 0

Re: type classes and generality
by Norman Ramsey 10 Jul '01

10 Jul '01

> On 09-Jul-2001, Norman Ramsey <nr(a)eecs.harvard.edu> wrote: > > I'm trying to model probability and leave the > > representation of probability unspecified other than > > it must be class Real. But I'm having trouble with > > random numbers; how can I show that if a type has class Real, > > it also has class Random.Random? Is there a way to accomplish > > this goal other than by changing the library? > > I'm not sure if I fully understand your goal. > But one thing you can do is to define a wrapper type > > newtype WrapReal r = WrapReal r > > and make the wrapper an instance of Random.Random > if the underlying type is an instance of Real > > instance Real r => Random.Random (WrapReal r) where > ... > > Then you can use the wrapper type whenever you want to get a random number. The problem is that without intensional type analysis, I wouldn't know how to fill in the instance methods in the `...' N

4 6