June 2005 - Haskell - Haskell.org

rfc: package mounting
by Frederik Eaton 23 Jun '05

23 Jun '05

Hi all, It looks like there's been a bit of recent discussion regarding module and package namespaces. There is a certain possible design feature that I don't think has been mentioned yet, that I think would be very helpful, so I thought I should at least bring it up. What I want is to be able to build a module namespace for a program out of packages in much the same way that filesystem namespaces are built, namely with mounting operations, rather than just by "union" or "overlay" operations as in the status quo. In other words I would like to be able to specify along with the "-package" option a "mount point" for that package in the module namespace. One possible option syntax might be e.g. "-package my-graphics-lib -package-base Graphics.UI.MyGraphicsLib". (Also, for backward compatibility and convenience, packages should probably be able to specify a default "mount point", to allow existing compiler command-line syntax to be used.) The idea is that with such a feature, library packages could get rid of the common module path prefixes which currently must be specified in every module in the library (such as "Graphics.UI.MyGraphicsLib" above). These prefixes would instead be specified once by each user of the library package (unless the default was desired), perhaps after the package import option on the compiler command line. Modules would have simple unqualified names within the library, like "Button" or "Window" which, if the package mount point were specified as say "Graphics.UI.MyGraphicsLib" in a certain compiler invocation, would be mapped to "Graphics.UI.MyGraphicsLib.Button" and "Graphics.UI.MyGraphicsLib.Window" respectively for code compiled by that invocation. But they could just as easily be mapped to "MGL.Button" etc. in a different invocation in a different project if a different mount point were preferred or were necessary to eliminate a namespace collision. There would be many benefits to being able to do things this way. First, developers would be able to move shared code across libraries without having to worry about the need to make widespread trivial changes to reflect the new module names. I could copy a 'Debug' or 'Util' module into my library from another library, and not have to go through the code to update the module hierarchy base location - furthermore I could incorporate new upstream changes easily without having to repeat this menial fixing-up procedure each time. While it's true that new version control systems like 'darcs' are meant to handle search-and-replace style changes effectively, I think that as far as this issue goes, a VC-based solution would be less elegant and less usable than what I am proposing. Second, this would decouple some aspects of the design process that in my opinion shouldn't be coupled. I would be able to start writing a library before deciding on a name, for instance - currently I at least have to stick in a dummy name as the module namespace base to avoid potential conflicts with other library imports while testing. But under this proposal I could just concentrate on building interior, bottom-up functionality first - at the end of the process a certain set of the package modules would be marked for external visibility, would comprise the exterior interface, and would suggest to me a fitting package name. Setting this name would only involve touching the cabal file rather than every single source file in my library. This would also make it easier to merge and split packages. Third, it would encourage the use of lightweight modules, by reducing the maintenance overhead of each module. Currently modules are the only way (correct me) to partition parts of the top-level namespace of a program - this is OK except that especially in libraries each module contains a certain amount of administrative paperwork, which is to say that it has to know the name of the library that contains it, because that, or some form of it, has to be part of the module name; and other importers of the module have to specify this information too; and as argued above there is a little work involved in touching up these references when code moves between libraries or when the library name changes. As a result I think people end up sticking more code in the same module at times when multiple modules would have been otherwise more suitable. Fourth, I think there would be psychological benefits. I think it's a bit patronizing to the programmer that he has to pretend to remind himself "you are in the following package" at the top of each file. I think people can easily enough keep track of that amount of state. It's as if the building code required me to put a sign with the current city and country in each room of my house. These are bits of context that I can easily call to mind if necessary, but which I would sometimes like to temporarily forget about. I believe programming is somewhat the same. We've come a long way from languages like C where one has to decide whether to precede each symbol in a library with an otherwise-meaningless identifier like "Py_", or risk namespace collisions with other libraries - but I don't think we're at the end of the road yet. It's true that if a module occurs in a package then that is its package, but often the package name doesn't do anything to suggest what the module functionality is - maybe the module exists only because other package modules depend on it, or maybe the package provides an assortment of otherwise unrelated functionality in its modules. In other words, the package name may describe something that the module functionality is only *applicable* to, or it may just be a catchy name. Being able to leave out this not-quite-relevant piece of information would make package-distributed code more conceptually streamlined, easier to quote out of context in e.g. papers, etc. Haskell is really a beautiful language - it's very dense and I think it is one of its great advantages that it allows the programmer to eliminate from code almost all save that which is absolutely relevant to its functionality - this proposal would take the language further in that direction. There is a strong tradition in science to put things in taxonomies, in static hierarchies, and people have tried to do this with collections of code libraries too, perhaps in imitation of scientists. One thing to note however is that the things from the natural world such as the genes of biological organisms change a lot more slowly than man-made code does. Science is different from engineering. A related reason that language designers may be drawn to requiring users to participate in universal classifications is that doing so projects an artificial aura of stability and organization onto the evolving code situation. But these designers, in shading themselves from progress, also stifle it. They create a central administrative hoop which couples all packages and impacts the scalability of the collective development effort. What I'm proposing would be a big departure from the practice of languages like Perl and Java that demand such a global module hierarchy. I've been told that the Haskell community is trying to make it so that two packages can have modules of the same name, as long as they aren't imported in the same compilation unit. My proposal would go further by (1) removing the latter restriction (2) allowing the package code to be completely ignorant of any "mount point". By the way, if you look at some aspects of operating system interfaces I think you'll see that often the choice I'm suggesting has already been made. For instance, you don't have to specify your current working directory with every command you execute, and furthermore the same command can easily be used in different working directories without modification; you can install binaries at different locations in the filesystem; you can mount filesystems at different mount-points, etc. One further thing, there have been proposals to simplify the importing of collections of modules from a certain point in the namespace, etc. I hope it is realized that they are independent from my proposal. They would not be very useful in implementing my proposal, at least I think any such solution would be far from optimal; and vice-versa. Modules and packages are quite distinct constructs, modules are needed for namespace partitioning and packages are needed to delineate administrative boundaries and sources of change. Both are necessary and both deserve special consideration in the ongoing design of Haskell. I will not be surprised if it seems strange to people that I attach such importance to what is likely seen as an unimportant detail of the language, but I do, and I hope that people will consider my suggestion. Also, I haven't said anything about implementation. I realize that this would probably require some modification to the linker. I hope I'm correct in assuming that the modifications will be relatively easy to make, provided it turns out of course that this feature is really something that people want. Frederik P.S. Thanks to John Meacham for a useful discussion. -- http://ofb.net/~frederik/

2 1

Dynamic binding
by Andrew Ward 23 Jun '05

23 Jun '05

Hi All, In Simon Thompson's The Craft of Functional Programming Second Edition, page 226, it is mentioned that Laufer (1996) describes a Haskell extension to allow dynamic binding. I was wondering if this has been implemented as an extension in any of the haskell compilers, or variants? I am a c++ programmer by trade, only dabbling in Haskell when I was at university, so it seems a disadvantage to me to not have dynamic binding in Haskell 98. What would be the normal way for a Haskell programmer to handle the typical shape example in beginner OO tutorials? Andrew Ward.

3 2

RE: [Haskell] Dynamic binding
by Ralf Lammel 23 Jun '05

23 Jun '05

Andreas Rossberg: Andreas R. wrote: > "dynamic binding" is just the OOO way of saying > "calling a first-class function"). Let me presume that dynamic binding was meant here in the sense of late binding, in the sense of subtyping polymorphism. At least, the given shapes example strongly suggested that. If so, I can't fully parse your reply in this context. Please elaborate. (First-class function seems to refer to currying or what?) (Did you miss a "polymorphic" before function? That would explain it. But then again, note, *first-class polymorphism* comes at the price of extra types just as the ugly ex. polymorphism trick. (This is of course just the same trick, indeed.) As we argue in Section 5.6 of the OOHaskell draft, current version, this does really not scale!) Andreas R. wrote: > In typical functional programming style, > you need the general thing only rarely. My impression is that the reason for not wanting (some do want however) true dynamic binding in Haskell relates more to the fact that we willingly make closed world assumptions about the cases to dispatch one. Where the C++ programmer defines classes, we are often just fine to define *one* datatype with n constructors (corresponding to n classes). In such a case, we have an easy time (except when we want case n+1 without recompilation). Using this "idea", late binding degenerates to pattern matching, which is the value-level variation on VMT dispatch. (And for the rare cases, where we want to become polymorphic with an open world, we seem to be willing to sacrifice type inference and we engage into existential polymorphism / first-class polymorphism.) And then of course with normal Haskell type classes we can nicely simulate *interface* polymorphism (again modulo the lack of type inference for subtyping polymorphism). So pre-OOHaskell doesn't miss a lot ;-) Ralf

2 1

RE: Re[2]: [Haskell] Dynamic binding
by Ralf Lammel 23 Jun '05

23 Jun '05

Andrew, you are circumventing the hard problem! (Even though I am sure you just forgot to mention it.) That is, the question is about drawing a *list* of shapes. As correctly observed by Rathman ages back, one naturally ends up with existential quantification when simulating dynamic binding. Ex. quantification is sufficiently scary for folks moving from C++ to Haskell. But fortunately it's not necessary ... see earlier plug ... Ralf > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of ajb(a)spamcop.net > Sent: Thursday, June 23, 2005 12:42 AM > To: haskell(a)haskell.org > Subject: Re: Re[2]: [Haskell] Dynamic binding > > G'day all. > > Thursday, June 23, 2005, 5:38:03 AM, you wrote: > > > To handle the problem of drawing all shapes, in c++, I would have a list > > of shape pointers: > > > struct shape{ virtual void draw(...);}; > > struct circle : public shape {...}; > > struct square : public shape {...}; > > std::list<shape *> shapes; > > for(std::list<shape *>::iterator it = shapes.begin();it != > > shapes.end();++it) > > { (*it)->>draw(...); } > > > This general pattern of dynamic binding I use over and over again. Could > > you give me some example code of this type of thing handled in Haskell's > > way? Assuming that the number of classes deriving from shape might get > > quite large. > > class Drawable s where > draw :: s -> IO () > > data Circle = Circle Point Radius > > instance Drawable Circle where > draw (Circle centre radius) = ... > > If you only need interface inheritance, this should do. If you also need > implementation inheritance, then you can model it with an upcast method: > > data Shape = Shape Stuff > > class Shape s where > toShape :: s -> Shape > draw :: s -> IO () > > instance Shape Shape where > toShape s = s > draw s = ... > > data Circle = Circle Shape Point Radius > > instance Shape Circle where > toShape (Circle s _ _) = s > draw (Circle _ centre radius) = ... > > In your original example, draw() wasn't abstract virtual, so I assume > there's a reasonable default draw() method for your "shape" class. If > there isn't, then it's probably better in Haskell to split the typeclass: > > class Shape s where > toShape :: s -> Shape > > class (Shape s) => DrawableShape s where > draw :: s -> IO () > > And only define DrawableShape on types where "draw" makes sense. > > Cheers, > Andrew Bromage > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

RE: Re[2]: [Haskell] Dynamic binding
by Ralf Lammel 23 Jun '05

23 Jun '05

Bulat, Bulat wrote: > just create list of draw functions itself: > > [drawCircle (10,10) 5, drawSquare (20,20) 10] No! the exercise is about lists of shapes not lists of results of drawing shapes. This is clearly a major difference. Bulat wrote: > for more complex tasks - declare interface as a structure: > > data ShapeInterface = Shape { draw :: IO (), > moveTo :: Point -> IO (), > calcArea :: Float > } No! You miss the point that the different shapes differ regarding state types. You don't have a chance when you use one datatype. haskell-cafe? Ralf > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Bulat Ziganshin > Sent: Thursday, June 23, 2005 12:18 AM > To: Andrew Ward > Cc: Pal-Kristian Engstad; haskell(a)haskell.org > Subject: Re[2]: [Haskell] Dynamic binding > > Hello Andrew, > > Thursday, June 23, 2005, 5:38:03 AM, you wrote: > > AW> To handle the problem of drawing all shapes, in c++, I would have a > list > AW> of shape pointers: > > AW> struct shape{ virtual void draw(...);}; > AW> struct circle : public shape {...}; > AW> struct square : public shape {...}; > AW> std::list<shape *> shapes; > AW> for(std::list<shape *>::iterator it = shapes.begin();it != > AW> shapes.end();++it) > { (*it)->>draw(...); } > > AW> This general pattern of dynamic binding I use over and over again. > Could > AW> you give me some example code of this type of thing handled in > Haskell's > AW> way? Assuming that the number of classes deriving from shape might get > AW> quite large. > > just create list of draw functions itself: > > [drawCircle (10,10) 5, drawSquare (20,20) 10] > > you are not expected that this problem can be solved with one line of > code? :) > > > for more complex tasks - declare interface as a structure: > > data ShapeInterface = Shape { draw :: IO (), > moveTo :: Point -> IO (), > calcArea :: Float > } > > > and return this structures from "constructor" functions: > > circle x y r = Shape { draw = drawCircle center r, > moveTo newCenter = ...., > calcArea = pi*r*r > } > where center = Point x y > > square x y size = Shape { draw = ...., > moveTo newCenter = ...., > calcArea = size*szie > } > > figures = [circle 1 2 3, square 4 5 6, circle 7 8 9] > > > > of course, you cannot use inherited field names when using this > technique :) > > -- > Best regards, > Bulat mailto:bulatz@HotPOP.com > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

RE: [Haskell] Dynamic binding
by Ralf Lammel 23 Jun '05

23 Jun '05

At the risk of being excluded from this list (because of an unmoral number of plugs about OOHaskell), here we go: http://homepages.cwi.nl/~ralf/OOHaskell/ You might start with the appendices of the paper and also read Section 2 which finally implements the Shapes example with ease. The C++ encoding is a bit verbose in so far that C++ doesn't quite have type inference, Haskell does and so OOHaskell does too :-) Apologies, Ralf > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Andrew Ward > Sent: Wednesday, June 22, 2005 6:38 PM > To: Pal-Kristian Engstad > Cc: haskell(a)haskell.org > Subject: Re: [Haskell] Dynamic binding > > Pal-Kristian Engstad wrote: > > >On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote: > > > > > >>What would be the normal way for a Haskell programmer to handle the > >>typical shape example in beginner OO tutorials? > >> > >> > > > >By not doing OO. You have to ask yourself, what is the purpose and/or > benefit > >of using OO? In C++, OO is _useful_ because you restrict the problems of > >mutable data (by enclosing it in C++ classes). > > > >ML type languages have other methods of doing things, and guess what, OO > is > >not that needed for these languages. Sum-types, pattern-matching and data > >constructors make half of the need for OO go away. Higher order functions > and > >make it even less needed. For the rest, there's always work-arounds. > > > >PKE. > > > > > To handle the problem of drawing all shapes, in c++, I would have a list > of shape pointers: > > struct shape{ virtual void draw(...);}; > struct circle : public shape {...}; > struct square : public shape {...}; > std::list<shape *> shapes; > for(std::list<shape *>::iterator it = shapes.begin();it != > shapes.end();++it) > { (*it)->draw(...); } > > This general pattern of dynamic binding I use over and over again. Could > you give me some example code of this type of thing handled in Haskell's > way? Assuming that the number of classes deriving from shape might get > quite large. > > Andrew Ward. > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: [Haskell] Dynamic binding
by Andrew Ward 23 Jun '05

23 Jun '05

Pal-Kristian Engstad wrote: >On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote: > > >>What would be the normal way for a Haskell programmer to handle the >>typical shape example in beginner OO tutorials? >> >> > >By not doing OO. You have to ask yourself, what is the purpose and/or benefit >of using OO? In C++, OO is _useful_ because you restrict the problems of >mutable data (by enclosing it in C++ classes). > >ML type languages have other methods of doing things, and guess what, OO is >not that needed for these languages. Sum-types, pattern-matching and data >constructors make half of the need for OO go away. Higher order functions and >make it even less needed. For the rest, there's always work-arounds. > >PKE. > > To handle the problem of drawing all shapes, in c++, I would have a list of shape pointers: struct shape{ virtual void draw(...);}; struct circle : public shape {...}; struct square : public shape {...}; std::list<shape *> shapes; for(std::list<shape *>::iterator it = shapes.begin();it != shapes.end();++it) { (*it)->draw(...); } This general pattern of dynamic binding I use over and over again. Could you give me some example code of this type of thing handled in Haskell's way? Assuming that the number of classes deriving from shape might get quite large. Andrew Ward.

5 4

Haskell version of Crystal Space 3D?
by Benjamin L. Russell 23 Jun '05

23 Jun '05

Does anybody know any Haskell tool(s) corresponding to Crystal Space 3D ( see http://www.crystalspace3d.org/tikiwiki/tiki-view_articles.php )? To quote from "About Crystal Space" ( see http://www.crystalspace3d.org/tikiwiki/tiki-index.php?page=About+Crystal+Sp… ), "Crystal Space is a free (LGPL) and portable 3D Game Development Kit written in C++. It supports: true six degrees of freedom, colored lighting, lightmapped and stencil based lighting, shader support (CG, vertex programs, fragment programs, ...), mipmapping, portals, mirrors, alpha transparency, reflective surfaces, 3D sprites (frame based or with skeletal animation using cal3d animation library), procedural textures, particle systems, halos, volumetric fog, scripting (using Python, Perl, Java, or potentially other languages), 16-bit and 32-bit display support, OpenGL, and software renderer, font support (also with freetype), hierarchical transformations, physics plugin based on ODE, ... See the extensive list of features for more details." The reason that I ask is that I would like to learn how to write my own version of PlaneShift (a 3D fantasy MMORPG written using Crystal Space 3D) with Haskell, instead of C++, if possible. However, I haven't been able to find any Haskell tools or libraries specific enough for this kind of project. Many thanks, Benjamin L. Russell

4 7

7th GPCE Young Researchers Workshop Deadline: June 30, 2005
by GPCE YRW Organizers 22 Jun '05

22 Jun '05

[apologies for multiple copies] 7th GPCE Young Researchers Workshop 2005 In conjunction with Generative Programming and Component Engineering (GPCE'05) Co-located with ICFP 2005 http://serl.cs.colorado.edu/~rutherfo/gpce_yrw05/ gpce_yrw05 (at) serl (dot) cs (dot) colorado (dot) edu Call for Papers This call is of special interest to people who have recently started their career in the domain of generative and component based software development (the "young researchers"). We would like to encourage contributions from PhD students, post-docs, and practitioners in industry. The topics of the workshop are: Component-based software engineering: Reuse, distributed platforms, distributed systems, evolution, analysis and design patterns, development methods, formal methods Product line engineering: Architectures, scoping, domain analysis, product line implementation and testing, variability Generative programming: Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artifacts, formal methods, reflection Separation of concerns: Aspect-oriented programming, intentional programming, and multi-dimensional separation of concerns Integration of generative and component-based approaches Domain engineering, analysis, and languages Aims and Objectives After the great success of the 6th GPCE Young Researchers Workshop (see the 6th GPCE Young Researchers Workshop website) this workshop which is traditionally held in conjunction with the GPCE aims again at providing a platform for young international researchers to present their work. The presentations will be commented by experienced panelists. The workshop serves as a forum for the participants to get in contact with other researchers in the field and to become familiar with other approaches and future research topics. Authors of accepted papers receive feedback and hints on their research in a constructive and international atmosphere. Submission Guidelines Potential participants are asked to submit a short paper in English. It must be no longer than 2500 words or five pages (including figures, tables, and references). Format the paper according to the LNCS style (for the formatting details see "Information for LNCS Authors") and submit your paper in either Postscript format or PDF. The submission should be classified according to the progress of the work, e.g. third year's PhD work. All submitted papers will undergo a review process by a panel of renowned experts. All accepted papers will be published as downloadable versions on the home page of the 7th GPCE Young Researchers Workshop 2005. The number of accepted papers is limited to ten. Papers should be sent by e-mail (please use the text GPCE-YRW-2005-Submission as subject of your mail) to the address listed in the Workshop Website and Email section. Workshop Structure The workshop is intended to take one day during the GPCE conference. Accepted papers have to be presented at the workshop by their authors. Afterwards the presenters receive constructive feedback and hints from invited panelists who are experienced experts in the workshop topics. Furthermore there will be time for discussion with the whole audience about the presented work. Workshop Website and Email http://serl.cs.colorado.edu/~rutherfo/gpce_yrw05/ gpce_yrw05 (at) serl (dot) cs (dot) colorado (dot) edu Important Dates Submission due: June 30, 2005 Notification of Acceptance: Jul 11, 2005 Camera Ready Copy: August 5, 2005 Workshop: September 27, 2005 Organization Douglas R. Dechow, Tech-X Corporation Daniel Fötsch, University of Jena Sebastian Kiebusch, University of Leipzig Saverio Perugini, University of Dayton Matthew J. Rutherford, University of Colorado at Boulder Denis Shestakov, Turku Center for Computer Science Panelists TDB

1 0

SOS 2005: Call for Papers
by sos2005＠mcs.le.ac.uk 22 Jun '05

22 Jun '05

First Call for Papers: Structural Operational Semantics 2005 A Satellite Workshop of ICALP 2005 July 10, 2005, Lisbon, Portugal http://www.cs.le.ac.uk/events/SOS2005 Aim: Structural operational semantics (SOS) provides a framework for giving operational semantics to programming and specification languages. A growing number of programming languages from commercial and academic spheres have been given usable semantic descriptions by means of structural operational semantics. Because of its intuitive appeal and flexibility, structural operational semantics has found considerable application in the study of the semantics of concurrent processes. Moreover, it is becoming a viable alternative to denotational semantics in the static analysis of programs, and in proving compiler correctness. Recently, structural operational semantics has been successfully applied as a formal tool to establish results that hold for classes of process description languages. This has allowed for the generalization of well-known results in the field of process algebra, and for the development of a meta-theory for process calculi based on the realization that many of the results in this field only depend upon general semantic properties of language constructs. This workshop aims at being a forum for researchers, students and practitioners interested in new developments, and directions for future investigation, in the field of structural operational semantics. One of the specific goals of the workshop is to establish synergies between the concurrency and programming language communities working on the theory and practice of SOS. Moreover, it aims at widening the knowledge of SOS among postgraduate students and young researchers from the U.K. and abroad. Specific topics of interest include (but are not limited to): * programming languages * process algebras * higher-order formalisms * rule formats for operational specifications * meaning of operational specifications * comparisons between denotational, axiomatic and SOS * compositionality of modal logics with respect to operational specifications * congruence with respect to behavioural equivalences * conservative extensions * derivation of proof rules from operational specifications * software tools that automate, or are based on, SOS. Papers reporting on applications of SOS to software engineering and other areas of computer science are welcome. History: The first SOS Workshop took place on 30th of August 2004 in London as one of the satellite workshops of CONCUR 2004. Over 30 participants attended the workshop. PAPER SUBMISSION: We solicit unpublished papers reporting on original research on the general theme of SOS. Prospective authors are invited to submit their work in two stages: Firstly, the title and abstract of the paper, together with the details of the author(s), should be emailed to sos2005 AT mcs.le.ac.uk by: Friday, 13 May 2005. Secondly, a pdf file with their full paper, whose length normally should not exceed 15 pages, should be sent by email to sos2005 AT mcs.le.ac.uk by: Monday, 23 May 2005. The email message with the full paper should also include, in plain text, contact information for the author(s), the title and abstract of the submission. Authors will be notified of acceptance by Monday, 13 June 2005. Submissions from the PC members are allowed. Proceedings: Preliminary proceedings containing the abstracts of the talks will be published as a Technical Report of the Department of Computer Science of Leicester University, and will be available at the meeting. The final proceedings of the workshop will appear as a volume in the ENTCS series. If the quality and quantity of the papers accepted for the workshop warrant it, submissions will be invited for a special issue of an archival journal devoted to full versions of selected papers. IMPORTANT DATES: * Submission of abstract: Friday, 13 May 2005 * Submission of full paper: Monday, 23 May 2005 * Notification: Monday, 13 June 2005 * Final version: Friday, 24 June 2005 * Workshop: Sunday, 10 July 2005. PROGRAMME COMMITTEE: Luca Aceto (BRICS, Aalborg, DK) Wan Fokkink (Amsterdam, NL) Rob van Glabbeek (NICTA, AU) Matthew Hennessy (Sussex, UK) Ralf Laemmel (CWI, NL) Peter Mosses (Swansea, UK, co-chair) David Sands (Chalmers, SE) Alex Simpson (Edinburgh, UK) Simone Tini (Insubria, I) Irek Ulidowski (Leicester, UK, co-chair) Erik de Vink (Eindhoven, NL) INVITED SPEAKERS: Jan Friso Groote Jose Meseguer CONTACT: sos2005 AT mcs.le.ac.uk WORKSHOP ORGANISERS: Peter D. Mosses Department of Computer Science University of Wales Swansea Singleton Park Swansea, SA2 8PP United Kingdom Irek Ulidowski Department of Computer Science University of Leicester University Road Leicester, LE1 7RH United Kingdom

2 1