- Haskell - Haskell.org

Announce: Haskell XML-RPC library
by Bjorn Bringert 15 Mar '04

15 Mar '04

Announcement: Haskell XML-RPC library ---------------------------------------------------------------------- I have written a Haskell XML-RPC client and server library which is available from: http://www.dtek.chalmers.se/~d00bring/haskell-xml-rpc/ XML-RPC (http://www.xmlrpc.com/) is "remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned." Library features: - Easy to use interface, see code examples below. - Lower-level interface for explicit conversion between XML-RPC and Haskell types, e.g. to support heterogeneous arrays and structs. - Support for XML-RPC introspection in both client and server. Remote method declarations can be generated by using introspection, see test/make-stubs.hs. - Support for HTTP authentication. Code examples: This is a simple CGI-based server with only one method that takes two integers and returns their sum: > import Network.XmlRpc.Server > > add :: Int -> Int -> IO Int > add x y = return (x + y) > > main = cgiXmlRpcServer [("examples.add", fun add)] This is a client that calls the method implemented by the server above and prints the result: > import Network.XmlRpc.Client > > server = "http://localhost/~bjorn/cgi-bin/simple_server" > > add :: Int -> Int -> IO Int > add = remote server "examples.add" > > main = do > let x = 4 > y = 7 > z <- add x y > putStrLn (show x ++ " + " ++ show y ++ " = " ++ show z) Requirements: - GHC >= 6.01 or Hugs >= Nov2003 - HaXml >= 1.10 All comments, suggestions, bug reports and flames are welcome. Yours truly, Bjorn Bringert

1 0

Re: [Haskell] What is the best way to write adapters?
by Ben_Yu＠asc.aon.com 12 Mar '04

12 Mar '04

Well. The instance declaration is like this: instance FwdSig Native instance FwdSig Def instance FwdSig d => Sig d instance Sig XXX Neither Native nor Def are direct instances of Sig. And this XXX, it is an instance of Sig, not a FwdSig. As you can see, there's no real overlapping at all if we take the "FwdSig d =>" as a precondition for "Sig d". However, ghc seems disregard the "FwdSig d =>" piece and insists that the "Sig d" and "Sig XXX" forms an overlapping. This confuses me and the only reason I can figure out is that ghc does not attempt to resolve ambiguity based on "=>", which, I guess, could make the implementation simpler. Brandon Michael Moore <brandon(a)its.caltech.edu>@haskell.org on 03/11/2004 06:56:41 PM Sent by: haskell-bounces(a)haskell.org To: Ben_Yu(a)asc.aon.com cc: haskell(a)haskell.org, oleg(a)pobox.com Subject: Re: [Haskell] What is the best way to write adapters? On Thu, 11 Mar 2004 Ben_Yu(a)asc.aon.com wrote: > > Thanks! Oleg. > > This works and it looks nice! > > And now, my code can be like: > > class FwdSig d where > (forall a. Sig a => a -> w) -> d -> w > > All the types that supports such forwarding are instances of FwdSig. > > My Def type is: > > instance FwdSig Def where > fwd f (ClassDef c) = f c > fwd f (ProtDef p) = f p > > instance Sig Def where > getName = fwd getName > getMethods = fwd getMethods > ... > > My Native type is: > > instance FwdSig Native where > fwd f (NativeSignature s) = f s > fwd f (NativeProtocol p) = f p > > instance Sig Native where > getName = fwd getName > getMethods = fwd getMethods > ... > > Many annoying forwarding functions are gone. > > The only thing that I hope to be better is this "getXXX = fwd getXXX" piece > of code. Is it possible to reuse the same piece of code for both Native and > Def and any other possible types? I'm not as handy with the type system as Oleg, but I can help out here. The problem with your new instance is that if the compiler is trying to see if Native is an instance of Sig, it can start with the declaration Sig Native, or the declarations FwdSig a => Sig a, both of which could potentially derive an instance of Sig Native. Additionally passing the -fallow-overlapping-instances flag will permit you to compile a program where instances overlap like this, and will select the most specific matching instance (looking only at the head). Your code is fine. Brandon > Inspired by your generic code, I wrote such thing: > > instance FwdSig d => Sig d where > getName = fwd getName > getMethods = fwd getMethods > ... > > However, my ghc complains about the use of "Sig d". > > I followed its recommendation and put -fallow-undecidable-instances flag > with the surprise that the "FwdSig d=>Sig d" instance declaration conflicts > with my other "instance Sig XXX" declarations. > > Surely this is not a serious problem, I can live with repeating the > "getXXX=fwd getXXX" several times. Just curious about how further this can > go. > > Ben. _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise us immediately.

2 1

CFP: Haskell Workshop 2004
by Henrik Nilsson 12 Mar '04

12 Mar '04

Please find enclosed the Call For Papers for the 2004 Haskell Workshop, to be held on 22 September in Snowbird, Utah, USA in association with ICFP'04. My apologies for multiple copies. Best regards, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn(a)cs.nott.ac.uk 2004 Haskell Workshop Snowbird, Utah, USA, 22 September, 2004 http://www.cs.nott.ac.uk/~nhn/HW2004 Call For Papers The Haskell Workshop 2004 is intended to form part of the 2004 International Conference on Functional Programming (ICFP) as an associated, ACM SIGPLAN sponsored workshop. It has been accepted by the ICFP'04 workshop committee; formal approval by the SIGPLAN executive committee is pending. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), Montreal (2000), Firenze (2001), Pittsburgh (2002), and Uppsala (2003). ******************** 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, imple- mentation, and teaching of Haskell. Topics of interest include, but are not limited to, the following: Language Design with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; Theory in the form of a formal treatment of the semantics of the present language or future extensions, type systems, and foundations for program analysis and transformation; Implementation Techniques including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management as well as foreign function and component interfaces; Tool Support in the form of profilers, tracers, debuggers, pre-processors, and so forth; Applications, Practice, and Experience with Haskell for scientific and symbolic computing, database, multimedia and Web applications, and so forth as well as general experience with Haskell in education and industry; Functional Pearls being elegant, instructive examples of using Haskell. Papers in the latter two categories need not necessarily report original research results; they may instead, for example, report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! The programme committee welcomes short papers and may accept them for brief presentation at the workshop. ******************** Submission Details ******************** Deadline for submission: 4 June, 2004 Notification of acceptance: 5 July, 2004 Final submission due: 30 July, 2004 (tentative) Haskell Workshop: 22 September, 2004 Authors should submit papers in postscript format, formatted for A4 paper, to Henrik Nilsson (nhn(a)cs.nott.ac.uk) by 4 June 2004. The length should be restricted to the equivalent of 5000 words (which is approximately 12 pages in ACM format). The papers will be published by the ACM and will appear in the ACM Digital Library. If you are interested in demonstrating a Haskell-related system or tool, please send a brief demo proposal to Henrik Nilsson (nhn(a)cs.nott.ac.uk) ******************** Programme Committee ******************** Jörgen Gustavsson Chalmers Thomas Hallgren OGI Jerzy Karczmarczuk Université de Caen Daan Leijen Universiteit Utrecht Henrik Nilsson (chair) University of Nottingham Colin Runciman University of York Martin Sulzmann National University of Singapore Valery Trifonov Yale University

1 0

Re: [Haskell] What is the best way to write adapters?
by Ben_Yu＠asc.aon.com 12 Mar '04

12 Mar '04

Thanks! Oleg. This works and it looks nice! And now, my code can be like: class FwdSig d where (forall a. Sig a => a -> w) -> d -> w All the types that supports such forwarding are instances of FwdSig. My Def type is: instance FwdSig Def where fwd f (ClassDef c) = f c fwd f (ProtDef p) = f p instance Sig Def where getName = fwd getName getMethods = fwd getMethods ... My Native type is: instance FwdSig Native where fwd f (NativeSignature s) = f s fwd f (NativeProtocol p) = f p instance Sig Native where getName = fwd getName getMethods = fwd getMethods ... Many annoying forwarding functions are gone. The only thing that I hope to be better is this "getXXX = fwd getXXX" piece of code. Is it possible to reuse the same piece of code for both Native and Def and any other possible types? Inspired by your generic code, I wrote such thing: instance FwdSig d => Sig d where getName = fwd getName getMethods = fwd getMethods ... However, my ghc complains about the use of "Sig d". I followed its recommendation and put -fallow-undecidable-instances flag with the surprise that the "FwdSig d=>Sig d" instance declaration conflicts with my other "instance Sig XXX" declarations. Surely this is not a serious problem, I can live with repeating the "getXXX=fwd getXXX" several times. Just curious about how further this can go. Ben. oleg@pobox.com@haskell.org on 03/11/2004 01:36:30 PM Please respond to oleg(a)pobox.com Sent by: haskell-bounces(a)haskell.org To: haskell(a)haskell.org cc: Ben_Yu(a)asc.aon.com Subject: [Haskell] What is the best way to write adapters? > The code is currently like this: > instance Sig Def where > getName (DefClass c) = getName c > getName(DefProtocol p) getName p > getName(DefSignature s) = getName s > getParents(DefClass c) = getParents c > getParents(DefProtocol p) = getParents p > blah blah blah... > > But this seems very annoying. > > If I have 4 different constructors in Def, and 5 methods of class Sig, > (Please bear with me if I'm using some OO terminology because I'm still a > new FP programmer), I'll have to write 4*5=20 forwarding functions. Adapters seem by necessity higher-ranked functions. The following is a stubefied code that uses generic adaptors (the function fwd). > {-# OPTIONS -fglasgow-exts #-} > module Foo where > > class Sig a where > getName :: a -> Int > getParents :: a -> String > getMethods :: a -> String > > data ClassDef = ClassDef > data ProtocolDef = ProtocolDef > > instance Sig ClassDef where > getName _ = 0 > getParents _ = "ClassDef Parents" > getMethods _ = "ClassDef Methods" > > instance Sig ProtocolDef where > getName _ = 1 > getParents _ = "ProtocolDef Parents" > getMethods _ = "ProtocolDef Methods" > > data Def = DefClass ClassDef | DefProtocol ProtocolDef > > fwd::(forall a. Sig a => a -> w) -> Def -> w > fwd f (DefClass c) = f c > fwd f (DefProtocol p) = f p > > instance Sig Def where > getName = fwd getName > getParents = fwd getParents > getMethods = fwd getMethods Tests: *Foo> getParents ClassDef "ClassDef Parents" *Foo> getParents ProtocolDef "ProtocolDef Parents" *Foo> getParents (DefClass ClassDef) "ClassDef Parents" *Foo> getParents (DefProtocol ProtocolDef) "ProtocolDef Parents" _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise us immediately.

2 1

What is the best way to write adapters?
by oleg＠pobox.com 11 Mar '04

11 Mar '04

> The code is currently like this: > instance Sig Def where > getName (DefClass c) = getName c > getName(DefProtocol p) getName p > getName(DefSignature s) = getName s > getParents(DefClass c) = getParents c > getParents(DefProtocol p) = getParents p > blah blah blah... > > But this seems very annoying. > > If I have 4 different constructors in Def, and 5 methods of class Sig, > (Please bear with me if I'm using some OO terminology because I'm still a > new FP programmer), I'll have to write 4*5=20 forwarding functions. Adapters seem by necessity higher-ranked functions. The following is a stubefied code that uses generic adaptors (the function fwd). > {-# OPTIONS -fglasgow-exts #-} > module Foo where > > class Sig a where > getName :: a -> Int > getParents :: a -> String > getMethods :: a -> String > > data ClassDef = ClassDef > data ProtocolDef = ProtocolDef > > instance Sig ClassDef where > getName _ = 0 > getParents _ = "ClassDef Parents" > getMethods _ = "ClassDef Methods" > > instance Sig ProtocolDef where > getName _ = 1 > getParents _ = "ProtocolDef Parents" > getMethods _ = "ProtocolDef Methods" > > data Def = DefClass ClassDef | DefProtocol ProtocolDef > > fwd::(forall a. Sig a => a -> w) -> Def -> w > fwd f (DefClass c) = f c > fwd f (DefProtocol p) = f p > > instance Sig Def where > getName = fwd getName > getParents = fwd getParents > getMethods = fwd getMethods Tests: *Foo> getParents ClassDef "ClassDef Parents" *Foo> getParents ProtocolDef "ProtocolDef Parents" *Foo> getParents (DefClass ClassDef) "ClassDef Parents" *Foo> getParents (DefProtocol ProtocolDef) "ProtocolDef Parents"

1 0

What is the best way to write adapters?
by Ben_Yu＠asc.aon.com 11 Mar '04

11 Mar '04

Hi, I have a class: class Sig a where getName :: a -> Id getParents :: a -> [TypeExp] getMethods :: a -> [MethodDef] getFields :: a -> [FieldDef] and a few data structures that are instances of Sig. They are ClassDef, ProtocolDef, SignatureDef, etc. Now I have a type Def defined as: data Def = DefClass ClassDef | DefProtocol ProtocolDef | DefSignature Signature And I want to make Def also an instance of Sig. The code is currently like this: instance Sig Def where getName (DefClass c) = getName c getName(DefProtocol p) getName p getName(DefSignature s) = getName s getParents(DefClass c) = getParents c getParents(DefProtocol p) = getParents p blah blah blah... But this seems very annoying. If I have 4 different constructors in Def, and 5 methods of class Sig, (Please bear with me if I'm using some OO terminology because I'm still a new FP programmer), I'll have to write 4*5=20 forwarding functions. I was trying to write something like: getSig:: Sig a => Def -> a getSig (DefClass c) = c getSig (DefProtocol p) = p ... But this does not compile. So, is there any nice way to save me from typing the x*y forwarding functions? Thanks! Ben. This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise us immediately.

1 0

RFC: DData in hierarchical libraries
by JP Bernardy 11 Mar '04

11 Mar '04

Dear haskellers, I propose to add a modified version of DData to the hierachical libraries. DData is a concrete library of collection types, by Daan Leijen. My modifications intend to make DData fit better in the hierarchical libraries. The haddock-generated documentation can be found here: http://users.skynet.be/jyp/DData/doc/index.html while the source code is at http://users.skynet.be/jyp/DData/ddata.tar.gz Any comment is welcome. (Including "I support this proposal" :)) Cheers, JP. PS. For those who don't follow the libraries list, the reasoning leading to this proposal goes as such: * Data.FiniteMap & Data.Set don't use the module system * We need better collection types * A fully fledged collection framework is difficult to agree on for integration in standard. * We should have a concrete types library, leaving the framework for later. * DData looks like a good candidate __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com

6 6

RE: [Haskell] RFC: DData in hierarchical libraries
by Simon Peyton-Jones 11 Mar '04

11 Mar '04

I'm glad to see this progressing. However, it might be better to move this thread to the libraries mailing list, which is specifically for this purpose. Anyone out there on the Haskell list who wants to contribute to discussion about Haskell libraries? http://www.haskell.org/mailman/listinfo/libraries Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of JP Bernardy | Sent: 10 March 2004 23:27 | To: Christian Maeder | Cc: Haskell Mailing List | Subject: Re: [Haskell] RFC: DData in hierarchical libraries | | | Hi, | | > Maybe the documentation to the "0rdered lists" | > section can be improved. | | Could you be more specific about this? | | > The functions Set.fromAscList and | > Set.fromAscDistinctList should be | > marked as "unsafe", since it's not clear what sets | > result if the input | > is not ascending (and/or has duplicates). | | Would you prefix the function name with unsafe? I | wonder what is the best way to do such a marking. | | > Furthermore, already for | > Set.fromList I expect it to be linear, if the input | > list happens to be | > ascending. | | I'm afraid it's not, unfortunately. I intend not to | fiddle with the implementation, to avoid the involved | instability. | | > "Set.map" is (still) missing. There are two variants | > of map functions | > with type: | > | > (Ord a, Ord b) => (a -> b) -> Set a -> Set b | > | > The first variant requires the function argument f | > to be strongly | > ascending, a < b => f a < f b, and corresponds to a | > map on the | > associated ascending lists. | > | > The second variant does not restrict the function | > argument but may | > result in a set of smaller size. Maybe this variant | > should be called | > "Set.image". | > | > The first variant, maybe call it "Set.mapAsc", is | | I'd choose "mapMonotonic", from Edison. | | > again "unsafe", since | > the argument function may not be ascending. (The | > descending case can be | > ignored.) | > | > The same argument about "ordered lists" apply to the | > Map module. In | > addition, it would be nice if there were a variant | > of "Map.keys" that | > returns a set of keys, since the invariant that the | > keys are ascending | > and distinct may easily get lost, if not captured by | > the Set type. A | > straight forward implementation is: | > | > Map.keySet = Set.fromDistinctAscList . Map.keys | > | > The use of "Set.fromDistinctAscList" is safe in this | > case, but - alas - | > Map needs to import Set. (But maybe there is even a | > faster | > implementation of Map.keySet that exploits the | > internal representation.) | | Fine. I'll come up with a revision soon. | | Thanks for your feedback, | JP. | | | __________________________________ | Do you Yahoo!? | Yahoo! Search - Find what you're looking for faster | http://search.yahoo.com | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: RFC: DData in hierarchical libraries
by JP Bernardy 11 Mar '04

11 Mar '04

--- Christian Maeder <maeder(a)tzi.de> wrote: > Simon Marlow wrote: > > Why are there IntBags but no Bags? > > As I've said before, rename MultiSet to Bag. Daan's remark about the difference between bags and multisets is: " A multi set differs from a /bag/ in the sense that it is represented as a map from elements to occurrence counts instead of retaining all elements. This means that equality on elements should be defined as a /structural/ equality instead of an equivalence relation. If this is not the case, operations that observe the elements, like 'filter' and 'fold', should be used with care. " Yet it can be argued that Eq is (nearly) always assumed to be defined by structural equality, so "Bag" would be just as good as "MultiSet". Since a true "Bag" type may be added later, I did not bother to change the name. > > Internal functions like DData.Set.valid should not > be visible. > > "valid" may be useful for debugging purposes if > certain (for efficiency > reasons unsafe) functions like "fromDistinctAscList" > may produce invalid > representations (if the argument is not strictly > ascending). But I don't > know if this is the case. Indeed. Maybe the best is just to rename the function to a name less likely to clash. Cheers, JP. __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com

2 1

ICFP Deadline 4/1; Submission site now open
by Kathleen Fisher 10 Mar '04

10 Mar '04

International Conference on Functional Programming Call for Papers ICFP 2004 September 19-22, 2004 Snowbird, Utah IMPORTANT DATES Submission deadline 23:00 01 April, 2004 Apia, Samoan time (Thursday) Author review period 23:00 17 May to 23:00 19 May, 2004, Apia, Samoan time Author notification 26 May, 2004 Final paper due 07 July, 2004 Conference 19-22 September, 2004 SCOPE ICFP 2004 seeks original papers on the full spectrum of the art, science, and practice of functional programming. The conference invites submissions on all topics ranging from principles to practice, from foundations to features, and from abstraction to application. The scope covers all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages that support objects and concurrency. Topics of interest include, but are not limited to, the following: Foundations: Formal semantics, lambda calculus, type theory, monads, continuations, control, state, effects. Design: Algorithms and data structures, modules and type systems, concurrency and distribution, components and composition, relations to object-oriented and logic programming, multiparadigm programming. Implementation: Abstract machines, compile-time and run-time optimization, just-in-time compilers, memory management. Interfaces to foreign functions, services, components and low-level machine resources. Transformation and analysis: Abstract interpretation, partial evaluation, program transformation, theorem proving, specification and verification. Software development techniques for functional programming : Design patterns, specification, verification and validation, debugging, test generation, tracing and profiling. Applications and domain-specific languages: Systems programming, scientific and numerical computing, symbolic computing and artificial intelligence, systems programming, databases, graphical user interfaces, multimedia programming, application scripting, system administration, distributed-systems construction, web programming, XML and related languages. Practice and experience: Functional programming in education and industry, ramifications on other paradigms and computing disciplines. Functional pearls: Elegant, instructive examples of functional programming. Papers in the latter three categories need not necessarily report original research results; they may instead, for example, report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! SUBMISSION GUIDELINES Due date & time: Submissions must be filed at the web site by 23:00 Thursday, 01 April, Apia, Samoa time. Some equivalents to this time are: * New York: 5:00 AM = 5h00 (02 April) * San Francisco: 2:00 AM = 2h00 (02 April) * Chicago: 4:00 AM = 4h00 (02 April) * Paris: Noon (02 April) * Hong Kong: 6:00 PM = 18h00 (02 April) * UTC: 10:00 AM (02 April) For other time-zones/locations, see the worldclock. Submission URL: http://icfp.acm.org/papers/submit/ (Available now) Authors should submit a 100-200 word abstract and a full paper by 23:00 Apia, Samoa Time on Thursday, 01 April, 2004. Submissions should be no more than 12 pages (including bibliography) in standard ACM conference format: two columns, nine-point font on a ten-point baseline, with pages 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). Detailed formatting guidelines are available at http://www.acm.org/sigs/pubs/proceed/template.html, along with formatting templates or style files for LaTeX, Word Perfect, and Word. You don't need to include categories, keywords, etc., though you are welcome to do so. Also, note that the ACM copyright notice is not required of submissions, only of accepted papers. Authors wishing to supply additional material to the reviewers beyond the 12-page limit can do so in clearly marked appendices, on the understanding that reviewers are not required to read the appendices. Submissions that do not meet these guidelines will not be considered. The submission deadline and length limitations are firm. Submissions will be carried out electronically via the Web, at the URL given above. Papers must be submitted in either PDF format or as PostScript documents that are interpretable by Ghostscript. They must be printable on US Letter sized paper. Individuals for which this requirement is a hardship should contact the program chair at least one week before the deadline. Submitted papers must adhere to SIGPLAN's republication policy. Each paper should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. Authors should strive to make the technical content of their papers understandable to a broad audience. Authors will be given a 48-hour period (23:00 17 May to 23:00 19 May 2004 Apia, Samoa time) to read and respond to the reviews for their papers before the PC meeting. Authors of submitted papers will receive more details from the submission site. Authors of accepted papers will be required to sign the ACM copyright form. Proceedings will be published by ACM Press. SPECIAL ISSUE OF JOURNAL OF FUNCTIONAL PROGRAMMING The top submitted papers, as determined by the program committee, will be invited to submit journal versions for a special issue of JFP. CONFERENCE CHAIR Chris Okasaki U.S. Military Academy, West Point PROGRAM CHAIR Kathleen Fisher AT&T Labs Shannon Laboratory 189 Park Ave., E244 Florham Park, NJ, USA kfisher at research.att.com Phone: +1 973 360.8675 Fax: +1 973 360.8077 PROGRAM COMMITTEE * Lennart Augustsson (Sandburst Inc.) * Hans-J. Boehm (HP Laboratories) * Koen Claessen (Chalmers University) * Adriana Compagnoni (Stevens Institute of Technology) * Matthias Felleisen (Northeastern) * Zhenjiang Hu (University of Tokyo) * Erik Meijer (Microsoft SQLServer/WebData) * Manuel Serrano (INRIA Sophia Antipolis) * Peter Sewell (University of Cambridge) * J�r�me Sim�on (Bell Laboratories) * Christopher A. Stone (Harvey Mudd College) * Martin Sulzmann (National University of Singapore) * David Walker (Princeton University) * Elena Zucca (Universit� di Genova) This document can be obtained in the following formats: HTML http://www.cs.indiana.edu/icfp04/cfp.html PostScript http://www.cs.indiana.edu/icfp04/cfp.ps PDF http://www.cs.indiana.edu/icfp04/cfp.pdf Plain text http://www.cs.indiana.edu/icfp04/cfp.txt

1 0