- Haskell - Haskell.org

CFP: DALT'03 - 1st Workshop on Declarative Agent Languages and Technologies
by João Alexandre Leite 25 Mar '03

25 Mar '03

=========================================================== S E C O N D C A L L F O R P A P E R S DALT 2003 First International Workshop on Declarative Agent Languages and Technologies Melbourne, Australia July 15th 2003 http://centria.di.fct.unl.pt/~jleite/dalt03/index.htm In conjunction with AAMAS 2003 2nd International Conference on Autonomous Agents and Multi-Agent Systems http://www.aamas-conference.org/ Submission: 11 of April, 2003 Post-Proceedings publishe by Springer-Verlag (LNAI) =========================================================== TECHNICAL DESCRIPTION Agent metaphors and technologies are ever more adopted to harness and govern the complexity of today's systems. As a consequence, the growing complexity of agent systems calls for models and technologies that promote system predictability, and enable feature discovery and verification. Recent advances in the area of logics and formal methods make declarative languages and technologies a mostly promising approach to the modeling and engineering of complex agent systems. DALT aims at fostering a discussion forum to export, on the one hand, such techniques into the broader community of agent researchers and practitioners and, on the other hand, to bring in the issues of real-world, complex, and possibly large-scale agent system design in the perspective of formal methods and declarative technologies. DALT 2003 will take place in Melbourne, Australia, in conjunction with AAMAS, the 2nd International Conference on Autonomous Agents and Multi-Agent Systems. Topics of interest include, but are not limited to: * Declarative agent communication and coordination languages * Knowledge-based and knowledge-intensive MAS * Modeling of agent rationality * Declarative approaches to the engineering of MAS * High level agent specification languages * Practical aspects of declarative agent programming and implementation * Formal methods for the specification and verification of MAS * Computational logics in MAS * Argumentation and dialectical systems in MAS * Declarative description of contracts and negotiation issues in MAS * Lessons learned from the design and implementation of MAS * Declarative paradigms for the combination of heterogeneous agents * Constraints and MAS * Declarative representation of policies and security in MAS SUBMISSIONS We welcome and encourage the submission of high quality, original papers, which are not simultaneously submitted for publication elsewhere. Papers should be written in English, formatted according to the Springer LNCS style, which can be obtained at (http://www.springer.de/comp/lncs/authors.html) and not exceed 16 pages including figures, references, etc. Send your paper in PostScript (PS) or Portable Document Format (PDF) to jleite(a)di.fct.unl.pt. IMPORTANT DATES * Submission, 11 of April, 2003 * Notification, 6 of May, 2003 * Camera Ready, 16 of May, 2003 PROCEEDINGS To encourage and promote the discussion, early and final versions of the accepted papers will be available online, at the workshop's web page, as soon as they are available. A printed volume with the proceedings will be available at the workshop. Authors of papers presented at the workshop will be asked to extend their contributions, possibly incorporating the results of the workshop discussion, to be included in the workshop post-proceedings. Post-proceedings will be published by Springer-Verlag as a volume of the Lecture Notes on Artificial Intelligence series (http://www.springer.de/comp/lncs/index.html) PROGRAM COMMITTEE Rafael Bordini, The University of Liverpool, UK Jeff Bradshaw, The University of West Florida, FL, USA Antonio Brogi, Università di Pisa, Italy Stefania Costantini, Università degli Studi di L'Aquila, Italy Yves Demazeau, Institut IMAG, Grenoble, France Jürgen Dix, The University of Manchester, UK Toru Ishida, Kyoto University, Japan Catholijn Jonker, Vrije Universiteit Amsterdam, The Netherlands Antonis Kakas, University of Cyprus, Cyprus Daniel Kudenko, University of York, UK Alessio Lomuscio, King's College, London, UK Viviana Mascardi, DISI, Genova, Italy Paola Mello, Università di Bologna, Italy John Jules Ch. Meyer, Universiteit Utrecht, The Netherlands Charles L. Ortiz, SRI International, Menlo Park, CA, USA Sascha Ossowski, Universidad Rey Juan Carlos, Madrid, Spain Luís Moniz Pereira, Universidade Nova de Lisboa, Portugal Jeremy Pitt, Imperial College, London, UK Ken Satoh, National Institute of Informatics, Tokyo, Japan Michael Schroeder, City University, London, UK Onn Shehory, IBM Research Lab in Haifa, Israel Carles Sierra, Spanish Research Council, Barcelona, Spain V.S. Subrahmanian, University of Maryland, MD, USA Francesca Toni, Imperial College, London, UK Wiebe van der Hoek, The University of Liverpool, UK Franco Zambonelli, Università di Modena, Italy ORGANIZING COMMITTEE Co-chairs: João Alexandre Leite (Contact Person) Universidade Nova de Lisboa jleite(a)di.fct.unl.pt Andrea Omicini Università di Bologna aomicini(a)deis.unibo.it Leon Sterling The University of Melbourne leon(a)cs.mu.oz.au Paolo Torroni Università di Bologna ptorroni(a)deis.unibo.it

1 0

Error in Hugs 98
by Cesar Augusto Acosta Minoli 25 Mar '03

25 Mar '03

1 0

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