March 2001 - Haskell - Haskell.org

PLI 2001: submission deadline is approaching
by Rosario Pugliese 05 Mar '01

05 Mar '01

[Apologies for multiple copies] ---------------------------------------------------------------- PLI 2001 Principles, Logics, and Implementations of high-level programming languages (Sponsored by ACM) Firenze, ITALY September 2 - 8, 2001 http://music.dsi.unifi.it/pli01/ The colloquium on Principles, Logics, and Implementations of high- level programming languages is a collection of conferences and workshops aimed at the advancement of high-level programming languages. The events composing PLI will cover a spectrum of topics important to language development and use, including issues such as semantics, design, analysis, implementation, and application. Theoretical issues relevant to language design and programming will be represented. Implementation questions will provide an emphasis on compilation methods, distributed computation and static debugging techniques. There will also be a focus on industrial and educational applications. Conferences: ICFP (September 3-5) Int. Conf. on Functional Programming General chair: Benjamin Pierce (Univ. Pennsylvania) Program chair: Xavier Leroy (INRIA Rocquencourt) PPDP (September 5-7) Int. Conf. on Principles and Practice of Declarative Programming Conference chair: Rocco De Nicola (Univ. Firenze) Program chair: Harald Søndergaard (Univ. Melbourne) Workshops: · Multilanguage Infrastructure and Interoperability (BABEL) · ERLANG Workshop · Fixed Points in Computer Science (FICS) · HASKELL Workshop · Quantitative Aspects of Programming Languages (QAPL) · Rule-Based Programming (RULE) · Semantics, Applications, and Implementation of Program Generation (SAIG) · Scheme and Functional Programming (SCHEME) · Verification and Computational Logic (VCL) Submission deadline for ICFP and PPDP: March 15, 2001 Workshops chair: Betti Venneri (Univ. Firenze) Publicity chair: Rosario Pugliese (Univ. Firenze) Organizing Committee: Gianni Aguzzi (Univ. Firenze, co-chair), Giorgio Ghelli (Univ. Pisa, co-chair), Lorenzo Bettini (Univ. Firenze), Michele Loreti (Univ. Firenze), Dario Colazzo (Univ. Pisa) Contact Information: pli-inf(a)gdn.dsi.unifi.it Conference Venue: Auditorium Banca Toscana, Via Panciatichi, 87 (Firenze Nova), Firenze, ITALY

1 0

Circular Data Types - a directory tree abstraction
by Shlomi Fish 04 Mar '01

04 Mar '01

I want to implement a directory data type where each directory may contain other directories, as well as end documents. I declared the following file for managing it: ------------------------------ module Contents_Abs where data Contents_Image url mime = MakeContents_Image url mime get_image_url (MakeContents_Image url mime) = url get_image_mime_type (MakeContents_Image url mime) = mime make_image url mime = (MakeContents_Image url mime) data Contents_Node url title subs images is_dir = MakeContents_Node url title subs images is_dir get_url (MakeContents_Node url title subs images is_dir) = url get_title (MakeContents_Node url title subs images is_dir) = title get_subs (MakeContents_Node url title subs images is_dir) = subs get_is_dir (MakeContents_Node url title subs images is_dir) = is_dir make_contents_doc url title = (MakeContents_Node url title [] [] False) make_contents_dir url title subs = (MakeContents_Node url title subs [] True) make_contents_dir_with_images url title subs images = (MakeContents_Node url title subs images True) -------------------------------------------- Now, I have the following example file: -------------------------------------------- module Contents where import Contents_Abs contents = (make_contents_dir_with_images "" "Contents" [ (make_contents_doc "intro.html" "Introduction"), (make_contents_doc "properties.html" "Properties"), (make_contents_dir "recursion" "Recursion" [ (make_contents_doc "fib1.html" "Fibonnaci (Take 1)"), (make_contents_doc "qsort.html" "Quick Sort") ] ), (make_contents_dir "lazy_eval" "Lazy Evaluation" [ (make_contents_doc "primes1.html" "Primes (Take 1)"), (make_contents_doc "fib2.html" "Fibonnaci (Take 2)") ] ) ] [ (make_image "style.css" "text/css") ] ) ------------------------------------------- I would like to be able to traverse this tree, so I defined the following script: --------------------- import Contents_Abs import Contents mytraverse contents = trav contents where trav branch = (get_url branch) ++ (trav_subs (get_subs branch)) where trav_subs [] = "" trav_subs (a:as) = (trav a) ++ (trav_subs as) result = mytraverse contents ----------------------- However, when trying to load it hugs reports the following error: Reading file "Z:\Download\unpack\hugs98\lib\Prelude.hs": Reading file "print_cont.hs": Reading file "Contents_Abs.hs": Reading file "Contents.hs": Reading file "print_cont.hs": Type checking ERROR "print_cont.hs" (line 5): Type error in function binding *** Term : trav *** Type : Contents_Node [Char] b [a] c d -> [Char] *** Does not match : a -> [Char] *** Because : unification would give infinite type Contents> I would like to know how I can define a data structure that will contain a list of references to its own types (I don't need circular data structures). I would also like to know how I can define such an abstraction inside a type. Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)techie.com The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.

2 1

Extensible Algebraic Data Types
by Ashley Yakeley 03 Mar '01

03 Mar '01

I think it would be useful to extend Haskell so that one could create algebraic data types in one module that could be union-extended in another. Something like this: data Thing = CharThing Char | IntThing Int | _ ...later... data Thing |= StringThing String This would be useful for two reasons: 1. You could do something akin to dynamic typing without unreasonably stressing the ideas behind the Haskell type system: data BaseExtension = _ data Base = MkBase (Char,Int,BaseExtension) ...later... data Derived = MkDerived (Char,Int,Int,Int) data BaseExtension |= MkDerivedExtension (Int,Int) upcast :: Derived -> Base upcast (MkDerived (a,b,c,d)) = MkBase (a,b,MkDerivedExtension(c,d)) downcast :: Base -> Maybe Derived downcast MkBase (a,b,MkDerivedExtension(c,d)) = Just (MkDerived (a,b,c,d)) downcast MkBase (a,b,_) = Nothing 2. You'd have a way of autogenerating values similar to LISP's gensym: data Token = _ deriving Eq ...later... data Token |= ThisToken data Token |= ThatToken data Token |= BunchOfTokens Int Of course this extension to Haskell begs another, virtual or generic functions. I'm not sure how to do this properly while maintaining the principle that an expression has the same value regardless of other modules loaded. data Thing = CharThing Char | IntThing Int | _ f1 :: Thing -> Int f1 (CharThing c) = ord c f1 (IntThing i) = i -- somehow allow cases to be inserted later here f1 _ = 0 -- multiple dispatch f2 :: Thing -> Thing -> Int f2 (IntThing i) (IntThing j) = i + j -- might want cases inserted here, -- provided they don't cause trouble f2 (IntThing i) _ = i -- or here f2 _ (IntThing i) = i + 1 -- or here f2 _ _ = 0 Are these ideas something worth thinking about? Or would such extensions compromise important principles behind Haskell? -- Ashley Yakeley, Seattle WA

1 0

Announce: Mysql-HS 0.10.0
by Volker Wysk 02 Mar '01

02 Mar '01

MySQL-HS is an interface to the MySQL database. This is a maintaince release. Changes: - Ported to GHC 4.08 and H/Direct 0.17 - Inproved documentation - General polishment This version is considered to be stable. If there don't show any bugs, the next version will be 1.0.0 and probably the conclusive one. (Except for support of new versions of GHC, H/Direct, MySQL). The homepage is at http://www.volker-wysk.de/mysql-hs

1 0

question re hugs and func dependencies
by Dominic Duggan 02 Mar '01

02 Mar '01

Dear all, I haven't got a reply from hugs-bugs, so I'll see if anyone here can answer the question. class foo a b | a |-> b where foo :: a -> b -> Int instance foo Int Float where foo x y = 0 instance foo [a] [b] where foo [x] [y] = foo x y g x y = (foo [x] y) + (foo [y] x) It is my conjecture that Hugs terminates on type-checking g because of a depth bound in the type-checker (although there is no indication from the type-checker that this is what is going on). Can anyone confirm or refute this conjecture? FWIW this is as part of the related work section for a paper that has been accepted to JFP: "Type-Checking Multi-Parameter Type Classes," by D. Duggan and J. Ophel. I'd appreciate cc-ing any replies to me, I'm not sure that I'm still on this mailing list. Cheers --dd

1 0

strictness question
by S. Doaitse Swierstra 02 Mar '01

02 Mar '01

I ran into a difference between GHC and Hugs. The following code: f (P p) ~(P q) = P (\ k -> \inp -> let (((pv, (qv, r)), m), st) = p (q k) inp in (((pv qv , r ), m), st)) runs fine with Hugs but blows up with GHC, whereas: f (P p) ~(P q) = P (\ k -> \inp -> let ~(~(~(pv, ~(qv, r)), m), st) = p (q k) inp in (((pv qv , r ), m), st)) runs fine with GHC too. From the Haskell manual I understand that pattern matching in "let"'s should be done lazily, so the addition of a collection of ~'s should not make a difference. Am I right with this interpretation? A possible source of this problem may be origination from the smarter GHC optimiser, but in that case the optimiser is not doing its work well. Doaitse Swierstra -- __________________________________________________________________________ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:doaitse@cs.uu.nl WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __________________________________________________________________________

3 2

RE: strictness question
by S. Doaitse Swierstra 02 Mar '01

02 Mar '01

Thanks for the prompt reply. Hugs apparently is more lazy and performs all the matching lazily, and that really makes a difference in my case. Doaitse At 8:11 AM -0800 3/2/01, Simon Peyton-Jones wrote: >Strange. You don't supply a complete program, so it's hard to >test. > >Nevertheless, the Haskell Report (Sect 3.12) specifies that >a let adds a single twiddle. Thus > > let (x, (y,z)) = e in b > >means > > let x = case e of (x,(y,z)) -> x > y = case e of (x,(y,z)) -> y > z = case e of (x,(y,z)) -> z > in b > >And that is what GHC implements. You get something different if you >add twiddles inside: > > let (x, ~(y,z)) = e in b > >means > let x = case e of (x,_) -> x > y = case e of (_,(y,_)) -> y > etc > >Adding more twiddles means less eager matching. I don't know whether >Hugs implements this. > >Simon > >| -----Original Message----- >| From: S. Doaitse Swierstra [mailto:doaitse@cs.uu.nl] >| Sent: 01 March 2001 11:26 >| To: haskell(a)haskell.org >| Subject: strictness question >| >| >| I ran into a difference between GHC and Hugs. The following code: >| >| f (P p) ~(P q) = P (\ k -> \inp -> let (((pv, (qv, r)), m), st) = >| p (q k) inp >| in (((pv qv , r ), m), st)) >| >| runs fine with Hugs but blows up with GHC, whereas: >| >| f (P p) ~(P q) = P (\ k -> \inp -> let ~(~(~(pv, ~(qv, r)), m), >| st) = p (q k) inp >| in (((pv qv , r ), m), st)) >| >| runs fine with GHC too. >| >| From the Haskell manual I understand that pattern matching >| in "let"'s >| should be done lazily, so the addition of a collection of ~'s should >| not make a difference. Am I right with this interpretation? >| >| A possible source of this problem may be origination from the smarter >| GHC optimiser, but in that case the optimiser is not doing its work >| well. >| >| Doaitse Swierstra >| >| >| >| >| -- >| ______________________________________________________________ >| ____________ >| S. Doaitse Swierstra, Department of Computer Science, Utrecht >| University >| P.O.Box 80.089, 3508 TB UTRECHT, the >| Netherlands >| Mail: mailto:doaitse@cs.uu.nl >| WWW: http://www.cs.uu.nl/ >| PGP Public Key: >http://www.cs.uu.nl/people/doaitse/ > tel: +31 (30) 253 3962, fax: +31 (30) 2513791 >__________________________________________________________________________ > >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell -- __________________________________________________________________________ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:doaitse@cs.uu.nl WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __________________________________________________________________________

1 0

Pattern guards vs. case (was, unfortunately :Re: interesting example of laziness/ghc optimisation)
by Ketil Malde 02 Mar '01

02 Mar '01

(Apologies, I forgot to change the subject) Laszlo Nemeth <laszlo(a)ropas.kaist.ac.kr> writes: > * * * Ketil Malde <ketil(a)ii.uib.no> wrote: > There is no difference. The 'pipe-syntax' (or pattern guards) gets > desugared (by the pattern matching compiler) to case statements i.e.: > runRandom = \ last max num.case (num > 1) of > True -> runRandom (fst new) max (num-1) > False -> snd new But - the converse is not true, is it? I can write ... = case foo of (Foo f) -> ... (Bar b) -> ... but I can't express that as a pattern-guarded expression, can I? My impression here is that the PG syntax adds nothing, and is hardly any more readable, and less intuitive for migrators from more traditional language. Why is it there at all? Is there a (rough) guideline for when to use one or the other? > For a more detailed discussion see SPJ's book, Augustsson original > paper, or M Pettersen't thesis (LNCS 1549). Okay, I'll try to look them up. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

5 5

RE: strictness question
by Simon Peyton-Jones 02 Mar '01

02 Mar '01

Strange. You don't supply a complete program, so it's hard to test. Nevertheless, the Haskell Report (Sect 3.12) specifies that a let adds a single twiddle. Thus let (x, (y,z)) = e in b means let x = case e of (x,(y,z)) -> x y = case e of (x,(y,z)) -> y z = case e of (x,(y,z)) -> z in b And that is what GHC implements. You get something different if you add twiddles inside: let (x, ~(y,z)) = e in b means let x = case e of (x,_) -> x y = case e of (_,(y,_)) -> y etc Adding more twiddles means less eager matching. I don't know whether Hugs implements this. Simon | -----Original Message----- | From: S. Doaitse Swierstra [mailto:doaitse@cs.uu.nl] | Sent: 01 March 2001 11:26 | To: haskell(a)haskell.org | Subject: strictness question | | | I ran into a difference between GHC and Hugs. The following code: | | f (P p) ~(P q) = P (\ k -> \inp -> let (((pv, (qv, r)), m), st) = | p (q k) inp | in (((pv qv , r ), m), st)) | | runs fine with Hugs but blows up with GHC, whereas: | | f (P p) ~(P q) = P (\ k -> \inp -> let ~(~(~(pv, ~(qv, r)), m), | st) = p (q k) inp | in (((pv qv , r ), m), st)) | | runs fine with GHC too. | | From the Haskell manual I understand that pattern matching | in "let"'s | should be done lazily, so the addition of a collection of ~'s should | not make a difference. Am I right with this interpretation? | | A possible source of this problem may be origination from the smarter | GHC optimiser, but in that case the optimiser is not doing its work | well. | | Doaitse Swierstra | | | | | -- | ______________________________________________________________ | ____________ | S. Doaitse Swierstra, Department of Computer Science, Utrecht | University | P.O.Box 80.089, 3508 TB UTRECHT, the | Netherlands | Mail: mailto:doaitse@cs.uu.nl | WWW: http://www.cs.uu.nl/ | PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __________________________________________________________________________ _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

WRS'2001 - Extended deadline
by Salvador Lucas Alba 02 Mar '01

02 Mar '01

[Apologies for multiple copies of this announcement] ************************************************************************** ******* Last call for papers - extended deadline: March 12, 2001 ******* ************************************************************************** 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 12, 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 12, 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 12, 2001 (extended deadline) 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