- Haskell - Haskell.org

Polymorphic types without type constructors?
by Shin-Cheng Mu 02 Feb '05

02 Feb '05

Hi, I have been thinking about using Haskell (extended with higher ranked polymorphism) to demonstrate to my colleagues some ideas in second-order lambda calculus. It turned out, however, I am puzzled by the type system myself. So I've written to seek for help. :) I started with define Church numerals as > type N = forall a . (a -> a) -> a -> a (The syntax above works only for GHC. In Hugs I would have to write type N a = (a -> a) -> a -> a and replace every N below with (forall a. N a)) I should have used newtype or data instead of a type synonym, but I wanted it to look more like seond-order lambda calculus so I tried to omit the constructor if possible. I could define addition and multiplication smoothly. > zero :: N > zero = \f -> \a -> a > succ :: N -> N > succ n = \f -> \a -> f (n f a) > add, mul :: N -> N -> N > add m n = \f -> \a -> m f (n f a) > mul m n = \f -> \a -> m (n f) a But when it comes to exponential, GHCi complained about type being not polymorphic enough. > exp :: N -> N -> N > exp m n = n (mul m) one GHC said: Inferred type is less polymorphic than expected Quantified type variable `a' escapes Expected type: ((a -> a) -> a -> a) -> (a -> a) -> a -> a Inferred type: (forall a2. (a2 -> a2) -> a2 -> a2) -> (a1 -> a1) -> a1 -> a1 In the application `mul m' In the first argument of `n', namely `(mul m)' On the other hand, there is another definition of exp > exp2 :: N -> N -> N > exp2 m n = n m which would type check. It seems to me that the difference is: in the case of the second definition of exp, the type variable in N can be instantiated to a monomorphic type (the same with add and mul). exp2 = \m::N -> \n::N -> \f::(b -> b) -> \b::b -> n [b->b] (m[b]) f b (where square brackets denote type application) while in the first exp, n::N is instantiated to a polymorphic type (another N): exp = \m::N -> \n::N -> \f::(b -> b) -> \b::b -> (n[N] (mul m) one)[b] f b I tried to add more type signatures to inform GHC of the fact that n::N is to be instantiated to a polymorphic type. However none of the attempts worked so far. I then noticed that in the GHC User's Guide (Sec 7.4.9) it was written "There is one place you cannot put a forall: you cannot instantiate a type variable with a forall-type. So you cannot make a forall-type the argument of a type constructor." The examples followed are all about type constructors (for example [forall a. a->a], a list of for-all's, is illegal). But is this the reason why exp cannot be typed? If so, is there a reason for such a restriction? Thank you very much! sincerely, Shin-Cheng Mu

1 0

[OT] post-structuralist object oriented system
by PA 01 Feb '05

01 Feb '05

Not really a question, but rather for your entertainment: "Lua’s Story of O" http://alt.textdrive.com/lua/19/lua-story-of-o Cheers -- PA, Onnay Equitursay http://alt.textdrive.com/

1 0

Applying Functors
by Johan Glimming 01 Feb '05

01 Feb '05

Folks, I wonder if there is any particular reason for not having a class for object map of a functor (Functor-instances) in addition to the arrow map (fmap). Now you may say that this is just the constructor, but in my current example I have found it useful to have a general way of taking an object/value a into F a since the constructor can be arbitrary. I thought that I may need the return-operator in class Monad. I call it flift: class Lift f where flift :: a -> f a This works nicely for trivial datatypes like "data Unit a = Unit" and "data Id a = Id a": instance Lift Unit where flift a = Unit instance Lift Id where flift a = Id a My question is --- how would you define Lift for constructors such as data Sum a = Inl a|Inr a and so forth? Best Wishes, Johan Glimming

1 0

Re: [Haskell] Typing in haskell and mathematics
by Cale Gibbard 01 Feb '05

01 Feb '05

I agree, as an undergraduate student of pure mathematics, I have been finding fairly large parts of the discussion about mathematical notation to be somewhat silly and uninformed. (Really it was more the previous thread, but it seems to have been continued here). One thing to keep in mind about mathematical notation is that it is usually not intended to be read by machines, rather it is a human language, albeit a very precise one. Statements like "a < b < c" are perfectly clear to everyone present, and if anyone has a type error in their head when reading that which they can't get past, they are most likely just being stubborn. Another common thing which is done whenever convenient is to treat Cartesian product as associative, and naturally identify the spaces (A x A) x A and A x (A x A), along with perhaps A^3 which might be functions f: {0,1,2} -> A, or might be treated as one of the preceding. In any given context, it should be easy to determine the author or lecturer's intent as to whether these are distinct or the same. Bookkeeping is left as an exercise to the bored reader or to logicians. (With the recent comment that functional programmers are applied logicians, perhaps it is no surprise that they would be upset with such fuzziness in the language!) The notational confusion between f and f(x) tends not to happen beyond the level of highschool, at least not where I am. The former refers to the function f, and the latter refers to a point in its codomain. In fact, I currently am dealing with the opposite problem in trying to learn differential geometry - people and books using just f to refer to a particular point in the codomain of f. All functions are automatically evaluated at a given point of concern. This seems to be common among physicists for some reason (most likely because they'd like to think of the function as a quantity, and are used to quantities having implicit relationships). Another thing to keep in mind is that mathematics is written in what is usually another human language. If I write a proof in English, I can provide enough context that any natural transformations I implicitly apply to things will be made obvious to the reader. The goal is not usually a machine-checkable proof, rather it's to convey enough information that anyone paying attention could produce one. A professor of mine used the term "rigourisable", halfway joking about the process. Basically, enough logical steps are provided so that the ideas are clear, and everyone is completely convinced that they could fill in the details -- mathematicians are usually pretty good at making sure that the details that they're providing for themselves are consistent. The reasons that such bookkeeping details are not generally provided is that for one, if someone is unable to fill some detail in, they are expected to think about it and then ask a question, and two, providing all of the details only serves to obscure the actual reasoning. Getting caught up in explicitly applying natural transformations that people would apply in their head without much thought anyway is a waste of time and creates a lot of junk to have to sift through to find the key ideas. In any case, it is important to keep the audience in mind while writing anything, including symbols. - Cale p.s. There are other good philosophical reasons not to take everything down to the level of formal logic and set theory all the time, stemming from Goedel's result that a formal system for mathematics cannot be proven consistent within itself. If we ever discover our system is broken it will likely have to be replaced by a similar one which corrects the problem. The fuzziness serves as good protection in the case of such an earthquake. It's easier to map slightly fuzzy notions with a given semantic interpretation onto a new system and find the analogues of theorems that you had before than it is to map direct low-level syntactical statements across and be able to say that they mean anything at all similar. On Mon, 31 Jan 2005 13:59:58 +0100, Benjamin Franksen <benjamin.franksen(a)bessy.de> wrote: > On Monday 31 January 2005 04:24, Jeremy Gibbons wrote: > > Despite being a fan of generic programming, I have my doubts about > > this kind of automatic lifting. It works fine in "ordinary > > mathematics", because there is no fear of confusion - one hardly ever > > deals with functions as entities in their own right. > > May I please beg to differ? When I studied math, things were quite > different, at least. I remember whole branches of mathematics > completely dedicated to dealing with "functions as entities in their > own right". One notable example is Functional Analysis, of which I > happen to know a little. And, as far as I remember, we used notation > which reflected this, i.e. nobody wrote 'f(x)' when actually they meant > just 'f', which is the same as '\x -> f x', which in math is usually > written 'x |-> f(x)'. > > > (Witness "sigma > > sin(x) dx", involving a term sin(x) and a dummy variable x, rather > > than the more logical "sigma sin", involving the function.) > > The notations for 'integral' and 'differential quotient' stem from a > time when dealing with functions as entities in their own right was > indeed not yet a common concept in mathematics, i.e. earlier than 1900. > > BTW, 'sigma sin' is not a function. > > Ben > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

5 4

RE: [Haskell] space behaviour of lazy recursive lists
by Simon Marlow 01 Feb '05

01 Feb '05

On 30 January 2005 17:09, Ben Rudiak-Gould wrote: > Axel Jantsch wrote: > > >Consider: > > > >>gibs = 1 : 1 : (zipWith f gibs (tail gibs)) > >> where f x y = min (x + y) 10 > > > >[...] how can I force the garbage collector to reclaim the > >memory of the head of the list after I have processed it, since I > will >never ever reference it again? > > There's no entirely satisfactory way to do this. The language standard > doesn't specify caching behavior, so you have to rely on the way that > actual implementations handle caching. > > I think it's safe in practice to assume that a binding inside a > function won't be cached across call boundaries, even if the value of > the binding doesn't depend on the function argument. I.e. you should > be able to solve your problem with > > makeGibs () = gibs where > gibs = 1 : 1 : (zipWith f gibs (tail gibs)) > f x y = min (x + y) 10 > > In principle a compiler could float the definition of gibs outside the > function makeGibs and cache it across calls, but I don't think any > compiler will actually do this, precisely because it makes this trick > stop working. Actually, GHC can garbage collect top-level definitions, and it also floats things out to the top-level precisely because doing so doesn't affect the space behaviour (any more than floating in general, that is). Unfortunately in this case, laziness is the culprit. Each element of the list is a thunk that refers to the previous two elements of the list, which are thunks that refer to the previous two elements... and so on. So even if you drop the front of the list, each element keeps the whole list alive until it is evaluated. Try this: gibs = 1 : 1 : f gibs (tail gibs) where f (x:xs) (y:ys) = z `seq` z : f xs ys where z = min (x + y) 10 main = print (head (drop 1000000 gibs)) Cheers, Simon

1 0

[HLPP 2005] Call for papers
by Frederic Loulergue 01 Feb '05

01 Feb '05

Third International Workshop on HIGH-LEVEL PARALLEL PROGRAMMING AND APPLICATIONS (HLPP 2005) July 4-5, 2005, Warwick University, Coventry, United Kingdom http://hlpp2005.free.fr AIMS AND SCOPE Parallel and distributed systems are now readily available as their price/performance ratio continues to improve. But parallel and distributed programming is still dominated by low-level techniques such as send/receive message passing. Sequential programming has long benefited from high-level programming techniques and tools that have made today's immense range of software economically viable. Two decades of research into high-level parallel and distributed programming have produced methods and tools that improve the price/performance ratio of parallel software, and broaden the range of target applications. Grid systems offer a tremendous computing power. Nevertheless, this power is far from being effectively exploited. In addition to technical problems related to portability and access, grid computing needs new programming paradigms. Research on high level programming for meta and grid computing is particularly relevant. This workshop follows HLPP 2001 & HLPP 2003, and is aimed at: computer science and scientific computing researchers, practitioners, graduate students; high-performance application developers (e.g. in DBMS, data-mining, parallel model checking, virtual reality) TOPICS We welcome submission of original, unpublished papers in English on topics including (but not limited to) the following aspects of parallel, distributed, meta and grid computing: - high-level algorithmic methods for parallel, communication-efficient and external-memory computation - high-level programming models (BSP, CGM, LogP, MPM, etc.) and tools - performance models and performance evaluation - high level resource-aware approaches - algorithmic skeletons and constructive methods - object, functional, logic, constraint programming - applications using high-level languages and tools - teaching experience with high-level tools and methods Accepted papers should be presented at the workshop and will be published in a special issue of an international journal (provided revisions suggested by the referees are made). IMPORTANT DATES 14 March 2005 Full paper due 2 May 2005 Notification 12 June 2005 Camera-ready paper due 4-5 July 2005 Workshop INVITED SPEAKER Prof. Dr. math. Friedhelm Meyer auf der Heide (Univ. of Paderborn, Germany) PROGRAMME COMMITTEE Rob Bisseling (Univ. of Utrecht, The Netherlands) Murray Cole (Univ. of Edinburgh, UK) Alexandros Gerbessiotis (NJIT, USA) Sergei Gorlatch (Univ. of Muenster, Germany) Gaétan Hains (Univ. of Orléans, France) Zhenjiang Hu (Univ. of Tokyo, Japan) Christoph Kessler (Linköpings Universitet, Sweden) Frédéric Loulergue (Univ. Paris Val de Marne, France) Mauricio Marín (Univ. de Magallanes, Chile) Quentin Miller(Somerville College, Oxford, UK) Andrea Pietracaprina (Univ. of Padova, Italy) Geppino Pucci (Univ. of Padova, Italy) Alexander Tiskin (Univ. of Warwick, UK) CHAIRS AND ORGANIZERS Dr. Alexander TISKIN Department of Computer Science University of Warwick Coventry CV4 7AL UNITED KINGDOM Dr. Frédéric LOULERGUE Laboratory of Algorithms, Complexity and Logic (LACL) University of Paris Val de Marne 61, avenue du Général de Gaulle F-94010 CRÉTEIL - FRANCE PAST HLPP WORKSHOPS HLPP 2003 was held in Paris (June 16-18, 2003). Parallel Processing Letters (Volume 13, issue 3) contains 14 revised papers presented at the workshop. HLPP 2001 was held in Orléans (March 26-27, 2001). Parallel Processing Letters (Volume 11,issue 4) contains 8 revised papers presented at the workshop.

1 0

CFP: WRS'05 *** extended deadline ***
by roberto＠dicosmo.org 31 Jan '05

31 Jan '05

********************************************************************** 5th Int'l Workshop on Reduction Strategies in Rewriting and Programming WRS'05 Nara, Japan, April 22nd, 2005 Call For Submissions *** EXTENDED DEADLINE: February 14th *** ********************************************************************** 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. Information on the previous, and forthcoming, WRS editions is available from the WRS permanent homepage. TOPICS 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 your submission in postscript or PDF format to the PC co-chairs at wrs05(a)pps.jussieu.fr before February 14th, 2005. 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 March 18, 2005. PUBLICATION Accepted papers will be included in the preliminary workshop proceedings that will be available at the workshop. Selected papers will be published in the Electronic Notes in Theoretical Computer Science (ENTCS) series of Elsevier. IMPORTANT DATES February 14, 2005 Deadline for electronic submission of papers February 28, 2005 Notification of acceptance of papers March 18, 2005 Deadline for final versions of accepted papers April 22, 2005 Workshop INVITED SPEAKERS * Kokichi Futatsugi (JAIST, Japan) * Hongwei Xi (Boston University, USA) PROGRAM COMMITTEE * Sergio Antoy (Portland) * Eduardo Bonelli (Stevens) * Roberto Di Cosmo (Paris VII, Co-Chair) * Bernhard Gramlich (Wien) * Stefano Guerrini (Roma) * Salvador Lucas (Valencia) * Aart Middeldorp (Innsbruck) * Yoshihito Toyama (Tohoku, Co-Chair) PROGRAM CO-CHAIRS Roberto Di Cosmo Laboratoire PPS - Universite Paris 7, France Email: roberto(a)dicosmo.org Yoshihito Toyama Tohoku University, Japan Email: toyama(a)nue.riec.tohoku.ac.jp FURTHER INFORMATION * Call for papers in Text, PostScript and PDF format * WRS permanent website: http://www.dsic.upv.es/~wrs * WRS 2005 e-mail address: wrs05(a)pps.jussieu.fr * RDP 2005 website: http://www.kurims.kyoto-u.ac.jp/rdp05/

1 0

monad transformers
by John Meacham 31 Jan '05

31 Jan '05

So, I create my own monad transformers quite often, It is great to be able to compose 5 or 6 transformers to get the perfect one for a given task. for example here is one for collecting statistics: -- The stats newtype Stat = Stat (Map.Map Atom Int) instance Monoid Stat where mempty = Stat Map.empty mappend (Stat a) (Stat b) = Stat $ Map.unionWith (+) a b -- The Monad transformer. newtype StatT m a = StatT (WriterT Stat m a) deriving(MonadIO, Functor, MonadTrans, Monad) runStatT (StatT m) = runWriterT m -- The operations on this type of monad class Monad m => MonadStats m where mticks' :: Int -> Atom -> m () instance Monad m => MonadStats (StatT m) where mticks' n k = StatT $ tell (Stat $ Map.single k n) Now all is well and good, I was able to use newtype deriving for most every interesting property I wanted from the WriterT monad. (note I specifically did not derive MonadWriter, as the point of my own transformer is to hide this). However, now we come to the crux, I want the various interesting monad operations (MonadReader, MonadWriter, etc.. ) to be able to pass through StatT as well as let MonadStats pass through other monad transformers. the second is easy and elegant: instance (Monad m, Monad (t m), MonadTrans t, MonadStats m) => MonadStats (t m) where mticks' n k = lift $ mticks' n k the first, however, is tricky. Right now, it appears that every Monad type in the libraries defines a rule for commuting with every other monad type, this seems impracticle for many monads (n^2 rules!) so, my question is, why arn't the standard monad transformers declared with an instance like above? as in: instance (Monad m, Monad (t m), MonadTrans t, MonadWriter w m) => MonadWriter w (t m) where ... Then, all that is needed is for everyone to declare theire monads as MonadTrans providing an appropriate lift and every monad property should compose nicely.* Another semi-solution would be to allow newtype-deriving of these monad properties somehow.. newtype StatT m a = StatT (WriterT Stat m a) deriving(MonadIO, Functor, MonadTrans, Monad, MonadReader) doesn't work, how bout something like newtype StatT m a = StatT (WriterT Stat m a) deriving(MonadIO, Functor, MonadTrans, Monad, MonadReader r m => MonadReader r ) which should give the newtype-deriving rule enough to figure out how to derivie the MonadReader rule properly. * We might need to come up with a more advanced MonadTrans class for certain monads, as 'lift' has been shown to not be fully capable for some situtations such as catching exceptions in an arbitrary MonadIO. ** The monad transformer libraries appear to have moved somewhere in the most recent cvs fptools tree, anyone know where they moved too? *** Monad transformers rock. -- John Meacham - ⑆repetae.net⑆john⑈

3 2

Typing in haskell and mathematics
by Jacques Carette 31 Jan '05

31 Jan '05

The previous post on record syntax reminded me of some 'problems' I had noticed where Haskell and mathematics have a (deep) usage mismatch. First, consider a syntax for other component-wise function application? For example, it would be convenient to have (f,g) @ (x,y) be (f x, g y). In some languages [with dynamic typing], one can even do (f,g) (x,y) :-) Yes, I am aware that this untypeable in Haskell, because polymorphism is straight-jacketed by structural rules. But in mathematics, it is convenient and extremely common to: 1) look at the type a -> b as being a *subtype* of b (though I have never seen it phrased that way in print) 2) to consider every 'natural transformation' available and use it (tuples of functions <-> obvious function on tuples) Seeing a -> b as a subtype of b allows one to take any function f : b -> b -> c (like + ) and 'lift' it to ff : (a -> b) -> (a -> b) -> (a -> c) via the obvious definition ff g h = \x -> f (g x) (h x) This is done routinely in mathematics. The meaning of the expression (sin + cos) should be immediately obvious. Such 'lifting' is used even in first-year calculus courses, but not in Haskell. The "same" phenomenon is what allows one to 'see' that there is an obvious function apply_tuple:: (a->b,c->d) -> (a,c) -> (b,d) so that (f,g) (a,b) only has one possible meaning, if the built-in apply function were to be overloaded. Similarly, there are "obvious" maps apply_T :: T (a->b) -> a -> T b for any datatype constructor T (as has been noticed by all who do 'generic' programming). This means that [f, g, h] x == [f x, g x, h x] but also (in mathematics at least) {f, g, h} x == {f x, g x, h x} where {} denotes a set, and the equality above is extensional equality, and so on. Note that some computer algebra systems use #1 and #2 above all the time to define the operational meaning of a lot of syntactic constructs [where I personally extended the use of such rules in the implementation & operational semantics of Maple]. What hope is there to be able to do something 'similar' in a Haskell-like language? Jacques

6 6

[CFP] ProMAS'05 @ AAMAS 2005 - Third International Workshop on Programming Multi-Agent Systems
by Juergen Dix 31 Jan '05

31 Jan '05

Call for Papers ================= Third International Workshop on Programming Multi-Agent Systems (ProMAS'05) <http://www.cs.uu.nl/ProMAS/> ProMAS'05 is a satellite workshop at AAMAS 2005 Utrecht University, The Netherlands <http://www.aamas2005.nl/> Even though the contributions of the multi-agent systems (MAS) community can make a significant impact in the development of open distributed systems, the techniques resulting from such contributions will only be widely adopted when suitable programming languages and tools are available. Furthermore, such languages and tools must incorporate those techniques in a principled but practical way, so as to support the ever more complex task of professional programmers, in particular when the systems have to operate in dynamic environments. The ProMAS workshop series aims to address the practical programming issues related to developing and deploying multi-agent systems. In particular, ProMAS aims to address how multi-agent systems designs or specifications can be effectively implemented. In its two previous editions, ProMAS constituted an invaluable occasion bringing together leading researchers from both academia and industry to discuss issues on the design of programming languages and tools for multi-agent systems. In particular, the workshop promotes the discussion and exchange of ideas concerning the techniques, concepts, requirements, and principles that are important for multi-agent programming technology. We encourage the submission of proposals for programming languages and tools that provide specific programming constructs to facilitate the implementation of the essential concepts used in multi-agent system analysis and specifications (e.g., mental attitudes, distribution, and social interaction). We also welcome submissions describing significant multi-agent applications, as well as agent programming tools that allow the integration of agents with legacy systems. Further, we are particularly interested in approaches or applications that show clearly the added-value of multi-agent programming, and explain why and how this technology should be adopted by designers and programmers both in academia and industry. Specific topics for this workshop include, but are not limited to: - Programming Languages for multi-agent systems - Extensions of traditional languages for multi-agent programming - Theoretical and practical aspects of multi-agent programming - Computational complexity of MAS - Semantics for multi-agent programming languages - High-level executable multi-agent specification languages - Algorithms, techniques, or protocols for multi-agent issues (e.g., coordination, cooperation, negotiation) - Agent communication issues in multi-agent programming - Implementation of social and organisational aspects of MAS - Formal methods for specification and verification of MAS - Verification tools for implementations of MAS - Agent development tools and platforms - Generic tools and infrastructures for multi-agent programming - Interoperability and standards for MAS - Programming mobile agents - Safety and security for mobile MAS deployment - Fault tolerance and load balancing for mobile MAS - Application areas for multi-agent programming languages - Applications using legacy systems - Programming MAS for Grid-based applications - Programming MAS for the Semantic Web - Deployed (industrial-strength) MAS - Benchmarks and testbeds for comparing MAS languages and tools Important Dates: ---------------- Paper submission deadline: 14th of March, 2005 Notifications of acceptance/rejection: 18th of April, 2005 Camera-ready copies due: 15th of May, 2005 Workshop Date: 25th or 26th of July, 2005 (TBA) Submission Details: ------------------- Authors should submit their paper by attaching it to an email to J�rgen Dix (dix(a)tu-clausthal.de) The email should also contain paper title, author name(s), affiliation(s), contact information of the main author, and a few keywords describing the topic (eg. from the list above). Papers should be formatted using Springer LNCS style (http://www.springer.de/comp/lncs/authors.html) and have a maximum of 15 pages. Accepted papers will be published as a technical report and distributed among participants during the workshop. As it was the case for ProMAS'03 and ProMas'04, we are planning to publish extended versions of the accepted papers as a volume of the Lecture Notes in Computer Science series by Springer-Verlag. Programme Committee: -------------------- - Chris van Aart (Acklin, The Netherlands) - Jean-Pierre Briot (University of Paris 6, France) - Monique Calisti (Whitestein Technologies, Switzerland) - Keith Clark (Imperial College, United Kingdom) - Yves Demazeau (Institut IMAG - Grenoble, France) - Frank Dignum (Utrecht University, The Netherlands) - Michael Fisher (University of Liverpool, United Kingdom) - Vladimir Gorodetsky (Russian Academy of Sciences, Russia) - Jomi H�bner (Universidade Regional de Blumenau, Brasil) - Toru Ishida (Kyoto University, Japan) - David Kinny (CTO, Agentis Software, USA) - Jo�o Leite (University Nova de Lisboa, Portugal) - Jiming Liu (Hong Kong Baptist University, Hong Kong) - John-Jules Meyer (Utrecht University, Netherlands) - J�rg M�ller (Clausthal University of Technology, Germany) - Oliver Obst (Koblenz-Landau University, Germany) - Gregory O'Hare (University College Dublin, Ireland) - Andrea Omicini (University of Bologna, Italy) - Julian Padget (University of Bath, United Kingdom) - Agostino Poggi (Universit� degli Studi di Parma, Italy) - Chris Reed (Calico Jack Ltd., United Kingdom) - Ichiro Satoh (National Institute of Informatics, Kyoto, Japan) - Onn Shehory (IBM Haifa Research Labs, Haifa University, Israel) - Kostas Stathis (Universit� di Pisa, Italy) - Milind Tambe (University of Southern California, USA) - Leendert van der Torre (CWI, Netherlands) - Paolo Torroni (University of Bologna, Italy) - Gerhard Weiss (Technische Universit�t M�nchen, Germany) - Michael Winikoff (RMIT University, Melbourne, Australia) - Cees Witteveen (Delft University, Netherlands) Organising Committee: --------------------- Rafael H. Bordini (University of Durham, U.K.) http://www.dur.ac.uk/r.bordini Mehdi Dastani (Utrecht University, The Netherlands) http://www.cs.uu.nl/~mehdi J�rgen Dix (Clausthal University of Technology, Germany) http://cig.in.tu-clausthal.de/ Amal El Fallah Seghrouchni (University of Paris VI, France) http://www-poleia.lip6.fr/~elfallah/

1 0