December 2000 - Haskell

PLI 2001: call for workshop proposals
by b.venneri 13 Dec '00

13 Dec '00

CALL FOR WORKSHOP PROPOSALS Principles, Logics and Implementations of high-level programming languages (PLI 2001) Firenze, Italy September 3 - 7, 2001 http://music.dsi.unifi.it/pli01 PLI 2001, a federation of colloquia which includes ICFP 2001 (ACM-SIGPLAN International Conference on Functional Programming) and PPDP 2001 (ACM-SIGPLAN International Conference on Principles and Practice of Declarative Programming), will be held in Firenze, Italy, September 3-7 2001. Workshops affiliated to PLI 2001 will be held before, after or in parallel with the main conferences. Researchers and practitioners are invited to submit workshop proposals, that should be sent to the PLI 2001 Workshop Chair Betti Venneri mailto:venneri@dsi.unifi.it with "PLI01 Workshop Submission" in the subject header. Proposals should include * a short scientific justification of the proposed topic (somehow related to the colloquia), * names and contact information of the organizers, * expected number of participants and duration (the preference is for one day-long workshops), * estimated dates for paper submissions, notification of acceptance and final versions and any other relevant information (e.g., invited speakers, publication policy, etc.). THE DEADLINE FOR RECEIPT OF PROPOSALS IS JANUARY 8, 2001. Proposals will be evaluated by the PLI 2001 Workshop Chair, the ICFP and PPDP Program Chairs and Conference Chairs. Notification of acceptance will be made by February 2, 2001. The titles and brief information related to accepted workshop proposals will be included in the conference program and advertised in the call for participation. Workshop organizers will be responsible for producing a Call for papers and a Web site, for reviewing and making acceptance decisions on submitted papers, and for scheduling workshop activities in consultation with the local organizers. Workshop selection committee: Xavier Leroy (INRIA, France), ICFP 2001 Program Chair Benjamin C. Pierce (Univ. of Pennsylvania), ICFP 2001 Conference Chair Harald Sondergaard (Univ. of Melbourne), PPDP 2001 Program Chair Rocco De Nicola (Univ. of Firenze), PPDP 2001 Conference Chair Betti Venneri (Univ. of Firenze), PLI 2001 Workshop Chair. we

1 0

PPDP 2001: Call for Papers
by Harald Sondergaard 11 Dec '00

11 Dec '00

Third International Conference on PRINCIPLES AND PRACTICE OF DECLARATIVE PROGRAMMING Firenze, Italy, 5-7 September 2001 CALL FOR PAPERS PPDP 2001 aims to stimulate research on the use of declarative methods in programming and on the design, implementation and application of programming languages that support such methods. Topics of interest include any aspect related to understanding, integrating and extending programming paradigms such as those for functional, logic, constraint and object-oriented programming; concurrent extensions and mobile computing; type theory; support for modularity; use of logical methods in the design of program development tools; program analysis and verification; abstract interpretation; development of implementation methods; application of the relevant paradigms and associated methods in industry and education. This list is not exhaustive: submissions describing new and interesting ideas relating broadly to declarative programming are encouraged. The technical program of the conference will combine presentations of the accepted papers with invited talks and advanced tutorials. PPDP 2001 is part of a federation of colloquia known as Principles, Logics and Implementations of high-level programming languages (PLI 2001) which includes the ACM SIGPLAN International Conference on Functional Programming (ICFP 2001). The colloquia will run from 2 to 8 September, 2001. The venue for the conference is Firenze (Florence), one of Europe's most attractive cities, famous for its churches, galleries and museums. For more details, see the conference web site. Important Dates: Submission 15 March 2001 Notification 7 May 2001 Final Version 11 June 2001 Affiliated Workshops: Proposals are being solicited for PLI 2001 affiliated workshops. Details about the submission of proposals are available at http://music.dsi.unifi.it/pli01/wkshops. Web Sites and Email Contact: PPDP 2001: http://music.dsi.unifi.it/pli01/ppdp PLI 2001: http://music.dsi.unifi.it/pli01 mailto:ppdp01@cs.mu.oz.au Conference Chair: Rocco De Nicola, Universita di Firenze http://www.dsi.unifi.it/~denicola/ mailto:denicola@dsi.unifi.it Program Chair: Harald Sondergaard, The University of Melbourne http://www.cs.mu.oz.au/~harald/ mailto:harald@cs.mu.oz.au Program Committee: Maria Alpuente, Univ. Politecnica de Valencia, ES Yves Caseau, Bouygues, FR Michael Codish, Ben-Gurion Univ. of the Negev, IL Saumya Debray, Univ. of Arizona, US Conal Elliott, Microsoft Research, US Sandro Etalle, Univ. Maastricht, NL Roberto Giacobazzi, Univ. di Verona, IT Michael Leuschel, Univ. of Southampton, GB John Lloyd, Australian National Univ., AU Torben Mogensen, Kobenhavns Univ., DK Alan Mycroft, Cambridge Univ., GB Gopalan Nadathur, Univ. of Minnesota, US Martin Odersky, Ecole Polyt. Fed. Lausanne, CH Catuscia Palamidessi, Penn State Univ., US Andreas Podelski, Max-Planck-Inst. Informatik, DE Kostis Sagonas, Uppsala Univ., SE Christian Schulte, Univ. des Saarlandes, DE Michael Schwartzbach, Aarhus Univ., DK Harald Sondergaard, Univ. of Melbourne, AU Peter J. Stuckey, Univ. of Melbourne, AU

1 0

Meet us on Wine Alley
by francois.xavier.bodin＠winealley.com 06 Dec '00

06 Dec '00

Hello! I found your address on a site about wine, food and good living. I thought that you will be interested by the services that our site offers. www.wine-alley.com is a virtual Club for all those interested in wine in both a professional and personal capacity. We now have more than 3900 members, both amateur and in the trade who use our site to discuss wine, buy and sell it and tell us about the best sources. Club members use the Newsgroup of www.wine-alley.com to exchange information and experiences. Only the other day someone asked how much a certain rare wine was worth, I asked for more information about the grape variety, which doesn't grow in France. Currently there have been more than 717 questions and replies. There is also the small ads. column. Among the 7 adverts placed this week there have been some really good deals including a magnum of 1945 Pichon Lalande and a 1947 Cheval blanc! Let me make it clear - www.wine-alley.com itself does not sell or buy wine: we simply offer our members the facilites for making their own arrangements. www.wine-alley.com is also a site supplying information in real time, particularly the latest news from winegrowers and makers via the French Press Agency (AFP). We also have a database of more than 21,000 wines with information supplied directly to the site by winegrowers co-operatives and specialist magazines. I should be delighted if you would come and join us. At www.wine-alley.com you will find similarly-minded people who just want to share their love of wine. Kind regards François Xavier Bodin, Manager of the Online Club fx.bodin(a)winealley.com PS. Registering with the www.wine-alley.com club is absolutely free and commits you to nothing. If you are not interested in my offer, please excuse this letter; I am sorry to have bothered you. To prevent further unwanted intrusions please click on the following link, your email will be automatically removed from our list. http://www.wine-alley.com/wines/desmail.asp?id=307392&l=uk

1 0

RE: Rank-2 polymorphism & type inference
by Simon Peyton-Jones 05 Dec '00

05 Dec '00

Musing on Zhanyong's problem some more, a solution occurs to me. Curiously, it's exactly the solution required for another useful extension to type classes. Here is is, so people can shoot holes in it. | In more detail, here's what happens. First we typecheck the RHS of | f, deducing the types | | x :: a where a is fresh | y :: k a where k is fresh | y >> return x :: k a | op (y >> return x) :: Bool with constraint C (k a) | \x -> op (y >> return x) :: a -> Bool with constraint C (k a) | | Now we try to generalise over a. We need to discharge the contraint | C (k a). Later we will find that y::[Int], so k=[], but we | don't know that yet. So we can't solve the constraint. One bad solution I thought of was to give f the type f :: forall a. C (k a) => a -> Bool This is bad because it's not the type signature the programmer specified. (It's also bad operationally because we'll pass a dictionary at runtime, which isn't necessary.) The good solution is to say this: \x -> op (y >> return x) :: a -> Bool with constraint C (k a) (just as before) /\a \x -> op (y>>return x) :: forall a. a -> Bool with constraint (forall a. C (k a)) This requires us to permit constraints with for-alls in them. As luck would have it, Ralf Hinze and I propose just such a thing in our paper "Derivable Type Classes" (Section 7) http://research.microsoft.com/~simonpj/#derive The motivation there is this: how can you write an equality instance for data T k a = MkT (k (T k a)) We can try: instance ... => Eq (T k a) where (MkT a) == (MkT b) = a == b But what is the "..."? We need that "k" is an equality type constructor. The right context is instance (forall a. Eq a => Eq (k a)) => Eq (T k a) where ...as before... Aha! A constraint with a for-all. There are some more details in the paper. So perhaps there's a reason for adding this extension in the implementation (to solve Zhanyong's problem) even for a Haskell 98 compiler. Simon

1 0

Call for papers: Haskell Workshop 2001
by Johan Jeuring 05 Dec '00

05 Dec '00

============================================================================ CALL FOR PAPERS 2001 Haskell Workshop Firenze, Italy The Haskell Workshop forms part of the PLI 2001 colloquium on Principles, Logics, and Implementations of high-level programming languages, which comprises the ICFP/PPDP conferences and associated workshops. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), and Montreal (2000). http://www.cs.uu.nl/people/ralf/hw2001.{html,pdf,ps,txt} ============================================================================ Scope ----- The purpose of the Haskell Workshop is to discuss experience with Haskell, and possible future developments for the language. The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Submissions that discuss limitations of Haskell at present and/or propose new ideas for future versions of Haskell are particularly encouraged. Adopting an idea from ICFP 2000, the workshop also solicits two special classes of submissions, application letters and functional pearls, described below. Application Letters ------------------- An application letter describes experience using Haskell to solve real-world problems. Such a paper might typically be about six pages, and may be judged by interest of the application and novel use of Haskell. Functional Pearls ----------------- A functional pearl presents - using Haskell as a vehicle - an idea that is small, rounded, and glows with its own light. Such a paper might typically be about six pages, and may be judged by elegance of development and clarity of expression. Submission details ------------------ Deadline for submission: 1st June 2001 Notification of acceptance: 1st July 2001 Final submission due: 1st August 2001 Haskell Workshop: to be announced Authors should submit papers of at most 12 pages, in postscript format, formatted for A4 paper, to Ralf Hinze (ralf(a)cs.uu.nl) by 1st June 2001. The use of the ENTCS style files is strongly recommended. Application letters and functional pearls should be labeled as such on the first page. They may be any length up to twelve pages, though shorter submissions are welcome. The accepted papers will be published as a University of Utrecht technical report. Programme committee ------------------- Manuel Chakravarty University of New South Wales Jeremy Gibbons University of Oxford Ralf Hinze (chair) University of Utrecht Patrik Jansson Chalmers University Mark Jones Oregon Graduate Institute Ross Paterson City University, London Simon Peyton Jones Microsoft Research Stephanie Weirich Cornell University ============================================================================

1 0

RE: Rank-2 polymorphism & type inference
by Simon Peyton-Jones 05 Dec '00

05 Dec '00

| > My question is: how does the type inference algorithm work in the | > presence of rank-2 types? Does anyone know of any documentation on | > this? Thanks! I had a look at this. Actually it turns out to be only loosely related to rank-2 polymorphism. I've been able to reproduce your problem using only Haskell 98. It looks like a problem with incomplete type inference Consider this: module MP where class C t where op :: t -> Bool instance C [t] where op x = True test :: [Int] -> Bool -- REQUIRED! test y = let f :: c -> Bool f x = op (y >> return x) in f (y::[Int]) Both GHC and Hugs reject this module if the type signature for test is omitted. NHC (v1.00, 2000-09-15) falls over completely, with Fail: Prelude.chr: bad argument All three succeed if the signature is in, or if the signature for f is omitted. This was unexpected, to me at least. You may need to add a type signature if polymorphic recursion is being used, but here it isn't! The problem is this: the compiler learns that y::[Int] "too late" to make use of it when solving the constraints arising from the RHS of f. In more detail, here's what happens. First we typecheck the RHS of f, deducing the types x :: a where a is fresh y :: k a where k is fresh y >> return x :: k a op (y >> return x) :: Bool with constraint C (k a) \x -> op (y >> return x) :: a -> Bool with constraint C (k a) Now we try to generalise over a. We need to discharge the contraint C (k a). Later we will find that y::[Int], so k=[], but we don't know that yet. So we can't solve the constraint. Adding the type signature to 'f' lets both GHC and Hugs figure out that y::[Int] in advance, so we need to solve the constraint C ([] a), which is fine. So I think you have uncovered a genuine problem, and one I don't know how to solve. It can always be "solved" by adding more type information, such as the type sig for 'test'. In you case you said: | After sending out my question, I noticed that hugs and ghc understood my | code differently: from the error messages, we can see that hugs view (\a | -> super a) as having type Sub b _1 -> Super b _2, while ghc thinks it | is Sub c a -> Super c Int. To verify it, I changed my code s.t. y is | defined as | | y = f (\(a :: Sub c Int) -> super a) x This is exactly right, and GHC is happy now. I can't account for Hugs' behaviour. The "right" solution is presumably to defer all constraint checking until we know what 'k' is. But that's a bit tricky because the constraint checking generates bindings that must appear in f's RHS. A full solution looks a bit over-kill-ish. But it's unsettling that the inference algorithm is incomplete. Simon

1 0

Rank-2 polymorphism & type inference
by Zhanyong Wan 04 Dec '00

04 Dec '00

Hello, I'm playing with Haskell's rank-2 polymorphism extension and am puzzled by the following example: ----------------------------------------------------------- module R2Test where class SubType a b where super :: a -> b data Sub c a = Sub data Super c a = Super instance SubType (Sub c a) (Super c a) f :: (forall c. Sub c a -> Super c b) -> Sub c a -> Super c b f g x = undefined x :: Sub c Int x = undefined y :: Super c Int y = f (\a -> super a) x ---------------------------------------------------------- I though the definition of y should type-check because (roughly): 1. We know x :: Sub c Int, y :: Super c Int 2. Hence in f :: (forall c. Sub c a -> Super c b) -> Sub c a -> Super c b, we know a is Int and b is Int. 3. Hence (\a -> super a) :: (forall c. Sub c Int -> Super c Int), and we are all set. However, Hugs 98 Feb 2000 (with the -98 switch) gives me: ERROR "R2Test.hs" (line 19): Cannot justify constraints in application *** Expression : \a -> super a *** Type : Sub b _1 -> Super b _2 *** Given context : () *** Constraints : SubType (Sub b _1) (Super b _2) and GHC 4.08.1 (with the -fglasgow-exts switch) gives: R2Test.hs:19: Could not deduce `SubType (Sub c a) (Super c Int)' from the context: () Probable cause: missing `SubType (Sub c a) (Super c Int)' in the type signature of an expression or missing instance declaration for `SubType (Sub c a) (Super c Int)' arising from use of `super' at R2Test.hs:16 In the right-hand side of a lambda abstraction: super a If I remove the "forall c." from the type signature for f, then both compilers accept my code. My question is: how does the type inference algorithm work in the presence of rank-2 types? Does anyone know of any documentation on this? Thanks! -- Zhanyong # Zhanyong Wan http://pantheon.yale.edu/~zw23/ ____ # Yale University, Dept of Computer Science /\___\ # P.O.Box 208285, New Haven, CT 06520-8285 ||___|

1 1

JFP Special Issue on Haskell
by gmh＠marian.cs.nott.ac.uk 04 Dec '00

04 Dec '00

Dear all, Please note that the deadline for submission to the JFP Special Issue on Haskell is in two months time --- 1st February 2001. Graham Hutton ---------------------------------------------------------------------- CALL FOR PAPERS Journal of Functional Programming Special Issue on Haskell Since its inception in 1987, Haskell has provided a focal point for research in lazy functional programming. During this time the language has continually evolved, as a result of both theoretical advances and practical experience. Haskell has proved to be a powerful tool for many kinds of programming tasks, and applications in industry are beginning to emerge. The recent definition of Haskell 98 provides a long-awaited stable version of the language, but there are many exciting possibilities for future versions of Haskell. The fourth Haskell Workshop was held as part of the PLI 2000 colloquium on Principles, Logics, and Implementations of high-level programming languages in Montreal, 17th September 2000. Previous Haskell Workshops have been held in Paris (1999), Amsterdam (1997) and La Jolla (1995). Following on from these workshops, a special issue of the Journal of Functional Programming will be devoted to Haskell. Possible topics include, but are not limited to: Critiques of Haskell 98; New proposals for Haskell; Applications or case studies; Programming techniques; Reasoning about programs; Semantic issues; Pedagogical issues; Implementation. Contributors to any of the Haskell workshops are invited to submit full papers to the special issue on Haskell, but submission is open to everyone. Submissions should be sent to the guest editor (address below), with a copy to Nasreen Ahmad (nasreen(a)dcs.gla.ac.uk) Submitted articles should be sent in postscript format, preferably gzipped and uuencoded. In addition, please send, as plain text, title, abstract, and contact information. The submission deadline is 1st February 2001. For other submission details, please consult an issue of JFP or see the Journal's web pages. Guest Editor: Graham Hutton School of Computer Science and IT The University of Nottingham Nottingham NG8 1BB United Kingdom gmh(a)cs.nott.ac.uk Useful Links: 2000 Haskell Workshop www.cs.nott.ac.uk/~gmh/hw00.html JFP Special Issue on Haskell www.cs.nott.ac.uk/~gmh/jfp.html JFP Home Page www.dcs.gla.ac.uk/jfp ----------------------------------------------------------------------

1 0

Re: old easter egg
by Ashley Yakeley 02 Dec '00

02 Dec '00

At 2000-12-01 13:08, Ronald Kuwawi wrote: >open text editor, type >hash :: [Char] -> Int >hash = (foldl (+) 0) . (map ord) > >save as hash.hs > >load script, type: >hash "MSDOS 6.000" > >or > >hash "SYSTEM 7.0" It's not really an easter egg, is it? It's more a modern form of numerology. I was hoping to see the hugs environment show me a little dancing bunny animation or something. letter c | ord c <= 64 = 0 letter c | ord c <= 90 = ord c - 64 letter c | ord c <= 96 = 0 letter c | ord c <= 122 = ord c - 96 letter c | otherwise = 0 renum n | n == 0 = 0 renum n | otherwise = (mod ((n - 1) * 19) 26) + 1 engql c = renum (letter c) engq = (foldl (+) 0) . (map engql) -- Ashley Yakeley, Seattle WA

1 0

old easter egg
by Ronald Kuwawi 02 Dec '00

02 Dec '00

open text editor, type hash :: [Char] -> Int hash = (foldl (+) 0) . (map ord) save as hash.hs load script, type: hash "MSDOS 6.000" or hash "SYSTEM 7.0" :-) Ronald

4 3