March 2003 - Haskell - Haskell.org

Casting via Read/Show
by George Russell 25 Mar '03

25 Mar '03

I'm afraid I don't much care for this solution either. (1) it's not at all clear to me what on earth it's good for. The main reason I use unsafe casting is because I need a way of storing and retrieving a value in a storage location which does not know its type. For example, a finite map which contains values of different types. It should always be the case that the type with which I wish to extract the value is the same at which I want to put the value in. Usually I do this kind of thing via Glasgow Haskell's Dynamic types. I don't think the Read/Show solution really helps much. (2) My mind revolts from the idea of having to casting numbers by converting them into their ASCII decimal representation. This is also potentially an expensive operation, for example for floats, where converting a very large or very small float to decimal in such a way that the original float can be recovered is an operation requiring expensive multiprecision arithmetic. (It is possible to speed this up to some extent, but this involves either tricky coding, or making compromises with precision which mean that the number you get out may not be the number you put in.) (3) In many cases this is wholly impossible, for example functions, or values of IO type. I have actual examples where I do this sort of thing. (4) It does not work intuitively. For example you can cast (10^20) from Integer to Float, even though it is not precisely representable. You cannot cast from Float to Integer at all. The main way I can envisage users using this kind of cast is for converting between different sorts of numbers. But there are already good ways of doing this kind of thing (fromIntegral, Numeric.fromRat). Surely it is much better for the user to be encouraged to these functions?

1 0

FINAL CALL for papers: ICFP 2003 deadline is Saturday
by Olin Shivers 25 Mar '03

25 Mar '03

The submission deadline for ICFP -- the International Conference on Functional Programming -- is coming up soon: this Saturday, March 29. The 2003 ICFP will be in Uppsala, Sweden on August 25-29, in conjunction with PPDP (Principles and Practice of Declarative Programming). Please take a moment to read the "call for papers" I've appended below, and see if you have a topic or result you would like to submit to the program committee. See you in Sweden. -Olin Shivers program chairman =============================================================================== Eighth Annual ACM SIGPLAN International Conference on Functional Programming ICFP 2003 Call for Papers (Revised 2003/2/5) Affiliated with PLI 2003 August 25-29, 2003 Uppsala, Sweden http://www-users.cs.york.ac.uk/~colin/icfp2003.html http://www.cc.gatech.edu/icfp03/cfp.html ------------------------------------------------------------------------------- * Important dates ----------------- Submission deadline 18:00 EST 29 March, 2003 (Saturday) Notification of acceptance rejection 19 May, 2003 Final paper due 16 June, 2003 Conference 25-29 August, 2003 * Scope ------- ICFP 2003 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 programming with functions, 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. 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 18:00 EST on Saturday 29 March. Some convenient equivalents to 18:00 EST are New York: 6:00 PM = 18h00 San Francisco: 3:00 PM = 15h00 Chicago: 5:00 PM = 17h00 Paris: Midnight Hong Kong: 7:00 AM (30 March) UTC: 2300 For other time-zones/locations, see http://www.timeanddate.com/worldclock/fixedtime.html Submission URL: http://www.cc.gatech.edu/icfp03/submit Authors should submit a 100-200 word abstract and a full paper by 23:00 Universal Coordinated Time on Saturday, 29 March, 2003. Submissions should be no more than 12 pages (including bibliography and appendices) 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 above 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, and 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 have content that has not previously been published in other conferences or refereed venues; simultaneous submission to other conferences or refereed venues is unacceptable. Each paper should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, saying 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 of accepted papers will be required to sign the ACM copyright form. Proceedings will be published by ACM Press. * Student Attendees ------------------- Students who have a paper accepted for the conference are offered student membership of SIGPLAN free for one year. As members of SIGPLAN they may apply for travel fellowships from the PAC fund. * Conference Chair ------------------ Colin Runciman University of York, UK * Program Chair --------------- Olin Shivers College of Computing Georgia Institute of Technology Atlanta, Ga. 30332-0280, USA shivers at cc.gatech.edu Phone: +1 404 385.00.91 Fax: +1 404 383.12.53 * Program Committee ------------------- Andrzej Filinski (DIKU, University of Copenhagen) Robby Findler (University of Chicago) Fritz Henglein (IT University of Copenhagen) Hugo Herbelin (INRIA) Ralf Hinze (Universität Bonn) Annie Liu (Stony Brook University) Benjamin Pierce (University of Pennsylvania) Todd Proebsting (Microsoft Corp.) Amr Sabry (University of Indiana) Zhong Shao (Yale University) Tim Sheard (OGI School of Science and Engineering) Eijiro Sumii (University of Tokyo) Andrew Wright (Cisco, Critical Infrastructure Assurance Group) * Accessing this document ------------------------- This document can be obtained in the following formats: HTML http://www.cc.gatech.edu/icfp03/cfp.html PostScript http://www.cc.gatech.edu/icfp03/cfp.ps PDF http://www.cc.gatech.edu/icfp03/cfp.pdf Plain text http://www.cc.gatech.edu/icfp03/cfp.txt * Change log ------------ 2003/2/5 Added program committee; revised submission deadline from 3/20 to 3/29; updated student travel-fellowship information. 2003/2/5 March 29 is Saturday, not Thursday. (March 20 is a Thursday.) 2003/2/7 Added Andrew Wright to PC list. 2003/2/9 Added URLs for accessing the CFP in various formats.

1 0

RE: simulating dynamic dispatch
by Simon Peyton-Jones 25 Mar '03

25 Mar '03

You might also find the 'cast' function in Section 3 of "Scrap your boilerplate" useful. http://research.microsoft.com/~simonpj/papers/hmap/ I'm not certain, but it has the right smell. Simon | -----Original Message----- | From: oleg(a)pobox.com [mailto:oleg@pobox.com] | Sent: 21 March 2003 04:19 | To: hdaume(a)ISI.EDU; haskell(a)haskell.org | Subject: Re: simulating dynamic dispatch | | | > i'm hoping to be able to simulate a sort of dynamic dispatch based on | > class instances. | | It seems you want to dispatch based not on a type but on the | constraint of a type. | | You code almost worked. Here's the a bit updated and working version. | | class Foo a where { foo :: a -> Bool } | class Bar a where { bar :: a -> Bool } | | data FB = forall a . Foo a => MkFoo a | forall a . Bar a => MkBar a | | instance Foo FB where | foo (MkFoo x) = foo x | | instance Bar FB where | bar (MkBar x) = bar x | | -- some instances for the test | instance Foo Int where | foo x = x == 0 | | instance Bar Char where | bar x = x == 'a' | | | test x = case x of | (MkFoo a) -> Just $ foo a | (MkBar a) -> Just $ bar a | -- _ -> Nothing | | | -- *Main> test $ MkFoo (0::Int) | -- Just True | -- *Main> test $ MkFoo (10::Int) | -- Just False | -- *Main> test $ MkBar 'a' | -- Just True | -- *Main> test $ MkBar 'b' | -- Just False | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

3 3

WRS 2003 - Deadline extended to April 3, 2003
by Salvador Lucas 24 Mar '03

24 Mar '03

[- We apologize for multiple copies of this message -] Due to multiple requests, we are extending the deadline for submissions to WRS 2003. Please, send a message containing the title, authors and abstract of your submission before M a r c h 3 0, 2 0 0 3 to wrs03(a)logic.at The full version of your submission to WRS 2003 should be sent before A p r i l 3, 2 0 0 3 to the same e-mail address. ****************************************************************** Third International Workshop on Reduction Strategies in Rewriting and Programming (WRS 2003) http://www.dsic.upv.es/~rdp03/wrs part of the Federated Conference on Rewriting, Deduction and Programming (RDP 2003) Valencia, Spain, June 8, 2003 ****************************************************************** 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 is part of the Federated Conference on Rewriting, Deduction and Programming (RDP 2003) to be held in Valencia (Spain) on June 8, 2003. The workshop is (co-)organized by 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 and explicit substitutions, 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). Please, send a message containing the title, authors, and abstract of your submission before March 30, 2003 to the PC co-chairs at wrs03(a)logic.at The full version of your submission should be sent in postscript or PDF format before April 3, 2003. Submissions should include the title, authors' names, affiliations, addresses, and e-mail. Selection of papers by the PC will be based on originality, significance, and correctness. Final versions will be due by May 11, 2003. PUBLICATION Accepted papers will be included in the preliminary workshop proceedings that will be available at the workshop. The final workshop proceedings will be published in the Electronic Notes in Theoretical Computer Science (ENTCS) series of Elsevier. PROGRAM COMMITTEE Sergio Antoy Portland (USA) Zena M. Ariola Eugene (USA) Roberto Di Cosmo Paris VII (France) Juergen Giesl Aachen (Germany) Bernhard Gramlich (co-chair) Wien (Austria) Salvador Lucas (co-chair) Valencia (Spain) Aart Middeldorp Tsukuba (Japan) Ricardo Pe~na Madrid (Spain) Pierre Rety Orleans (France) Eelco Visser Utrecht (The Netherlands) ORGANIZERS Bernhard Gramlich Technische Universitaet Wien Salvador Lucas Universidad Politecnica de Valencia IMPORTANT DATES Abstract's submission: March 30, 2003 Deadline for submissions: April 3, 2003 Notification: April 25, 2003 Final version due: May 11, 2003 Workshop: June 8, 2003 FURTHER INFORMATION WRS 2003 website: http://www.dsic.upv.es/~rdp03/wrs WRS 2003 e-mail address: wrs03(a)logic.at RDP 2003 website: http://www.dsic.upv.es/~rdp03 ******************************************************************

1 0

AW: AW: simulating dynamic dispatch
by Markus.Schnell＠infineon.com 24 Mar '03

24 Mar '03

Thanks! These examples and counterexamples help a lot in understanding. Markus > The reason is that sum only works on integer lists, whereas the given > type for fun requires that the first argument be a function that works > on lists of any type, such as length. > If sum were allowed as argument to fun, then we would also have to be > allowed to say: > > fun sum [True, False] [1,2] > > which clearly makes no sense. > > That Hugs refuses to report the type of fun has to with the fact that > such (rank-2) types cannot be inferred. GHC generally has > better support > for higher-ranked types (no general inference, of course). > > Hope that helped, > Janis. > > -- > Janis Voigtlaender > http://wwwtcs.inf.tu-dresden.de/~voigt/ > mailto:voigt@tcs.inf.tu-dresden.de >

1 0

AW: simulating dynamic dispatch
by Markus.Schnell＠infineon.com 24 Mar '03

24 Mar '03

I think I get it. But to be sure: The forall means: The type for a may not be the same throughout the whole function. It just has to follow the pattern specified inside the braces. Interestingly, when I want hugs to show me the type of > fun::(forall a.[a]->Int)->[b]->[c]->Int it tells me: ERROR - Use of fun requires at least 1 argument Why that? At least I have explicitely specified the type. Markus > One may want: > > fun f x y = f x + f y > > for instance: > > fun length [True, False] [1,2] > > Therefore, I would say, you need typing a la > > fun::(forall a.[a]->Int)->[b]->[c]->Int > > Ciao, > Steffen >

3 2

AW: simulating dynamic dispatch
by Markus.Schnell＠infineon.com 24 Mar '03

24 Mar '03

> http://research.microsoft.com/~simonpj/papers/hmap/ The technique you describe in that paper is exactly what I was wanting for many times. I often stopped using algebraic data types because of the immense amount of boilerplate I had to introduce. Thanks! But now I have a question regarding the forall. What does it do? How do I have to read a type definition with foralls? Or more concrete: What is the difference between (forall b. Term b => b -> b) -> a -> a and (Term b) => (b -> b) -> a -> a ? Markus

2 1

RE: simulating dynamic dispatch
by oleg＠pobox.com 23 Mar '03

23 Mar '03

Hal Daume wrote: > -- *Main> test $ MkFoo (0::Int) > -- Just True > -- *Main> test $ MkBar 'a' > -- Just True > i forgot to mention the constraint > that i don't want the user to have to use the MkFoo/MkBar > constructors. if i could use them internally to 'test', that would be > great, but that's what i couldn't get to work :). It can be done without burdening the user with typing MkFoo and MkBar. In fact, the enclosed code shows that it is possible to implement the dynamic dispatch on a type class context -- exactly the way you wanted it, it seems. The code resorts to no unsafe operations. Here's the test: -- *Main> test (1::Int) -- "this is foo calling: 1" -- *Main> test 'a' -- "this is bar calling: 'a'" -- *Main> test [True,False] -- "this is quu calling: [True,False]" Here's the code -- Dynamic dispatch on a constraint: Foo, Bar, or Quux -- The constraints to dispatch on class Foo a where { foo :: a -> String } class Bar a where { bar :: a -> String } class Quu a where { quu :: a -> String } -- Populate the type classes instance Foo Int where foo x = "this is foo calling: " ++ (show x) instance Bar Char where bar x = "this is bar calling: " ++ (show x) instance Quu [Bool] where quu x = "this is quu calling: " ++ (show x) -- The Universe (with hidden constraints) data PACK = forall a . Foo a => MkFoo a | forall a . Bar a => MkBar a | forall a . Quu a => MkQuu a -- The packer class Packable a where pack:: a -> PACK -- The following three instances seem to be the "inverse" -- of the "instance Foo Int" .. instance Quu [Bool] -- The three instances below do an important job: they "introduce" -- the class context, so to speak. -- Also, a type can be a member of several type classes. The following -- instances resolve the ambiguity. For example, even if Int were a member -- of a class Bar (in addition to being the member of a class Foo), the first -- instance declaration below resolves Int to a class Foo (and so we would -- dispatch on Foo when we see an Int). instance Packable Int where pack = MkFoo instance Packable Char where pack = MkBar instance Packable [Bool] where pack = MkQuu -- The dispatcher instance Foo PACK where foo (MkFoo x) = foo x instance Bar PACK where bar (MkBar x) = bar x instance Quu PACK where quu (MkQuu x) = quu x test:: (Packable a) => a -> String test = dispatch . pack where dispatch x = case x of (MkFoo a) -> foo a (MkBar a) -> bar a (MkQuu a) -> quu a -- *Main> test (1::Int) -- "this is foo calling: 1" -- *Main> test 'a' -- "this is bar calling: 'a'" -- *Main> test [True,False] -- "this is quu calling: [True,False]"

1 0

LambdaTeX and \usepackage{german}?
by Steffen Mazanek 22 Mar '03

22 Mar '03

Hello, I am a little confused. I have written a seminary paper using lambdaTeX for typesetting of the Haskell code. Now this paper shall be included in our seminary report. The problem: an annoying conflict arises when the package german is included, too. Are there any solutions? Thanks in advance, Steffen

1 0

[list-mm-net] 1st MM-NET Workshop on Analytical Techniques for Memory Management
by Richard Jones 21 Mar '03

21 Mar '03

1st MM-NET Workshop on Analytical Techniques for Memory Management University of Kent at Canterbury 15th May 2003 Call for papers and participation There has been a recent increase in interest in applying analytical techniques to the prediction and modelling of memory management, which is broadly defined to include . garbage collection of main-memory, peristent and distributed systems; . explicit dynamic memory allocation/de-allocation . measurement of object demographics . interactions with languages and operating systems The UK's MM-NET (Memory Management Network) therefore proposes to hold a 1-day workshop on analytical techniques for memory management on Thurs 15th May 2003 at the University of Kent at Canterbury (venue and time to be confirmed). Topics of interest include but are not limited to static prediction and bounding of memory usage; garbage collection supported by compile-time techniques; memory management models. The keynote address will be given by Prof. Greg Morrisett, Cornell University. Participation is welcomed from both academic and industrial sectors. Registration is free for mm-net members and should be made through http://www.mm-net.org.uk/ Coffees and lunch will be provided. Some support for travel costs for UK personnel may be available (please contact Richard Jones <R.E.Jones(a)ukc.ac.uk>). Talk slots will be allocated on a first-come first-served basis. If you would like to give a talk, please indicate this when registering for the workshop, and indicate whether you prefer a short (15 min) or normal (30 min) slot. Titles and abstracts should be finalised before the workshopd. We will collect presentations from the workshop online to form an informal proceedings at the time, and may approach speakers to form an edited formal proceedings at a later date. Important Dates: now provisional registration and notification of talks 8th May 2003 workshop programme confirmed 15th May 2003 workshop 27th May 2003 provide copies of presentations for online "proceedings" The workshop organisers are: Kevin Hammond University of St Andrews kh(a)dcs.st-and.ac.uk Richard Jones University of Kent R.E.Jones(a)ukc.ac.uk Peter O'Hearn Queen Mary College ohearn(a)dcs.qmul.ac.uk MM-NET is generously sponsored by the UK's Engineering and Physical Sciences Research Council (EPSRC).

1 0