[Haskell] WS-FM 2005 Call For Tools
WS-FM 2005 TOOLS SESSION Tools session in 2nd International Workshop on Web Services and Formal Methods Versailles, 2-3 September 2005, France http://www.cs.unibo.it/WS-FM05 Web services technology is a widespread accepted instantiation of Service Oriented Computing which facilitates integration of newly built and legacy applications both within and across organizational boundaries avoiding difficulties due to different platform, heterogeneous programming languages, security firewall, etc... The idea behind the WS approach is allowing independently developed applications to be exposed as services and interconnected exploiting the already set up Web infrastructure with relative standards (HTTP, XML, SOAP and WSDL). The technologies related to developing basic services and interconnecting them on a point-to point basis can be considered well established but B2B processing requires managing more complex interactions involving a large number of participants and none of the above standards are able to meet this need. For this reason the so-called Web services Composition Languages like XLANG, WSFL, BPML, WS-BPEL and WS-CDL are taking place. These languages are claimed to be based on formal models (pi-calculus variants, Petri Nets) to allow rigorous mathematical reasoning. However, despite all this hype, no interesting relations with formal methods have been so far emphasized and no conceptual instruments for analysis and reasoning or software verification techniques and tools have been so far presented by the respective companies. Any mathematical rigor becomes pointless without the ability to show these kind of results. In this sense contracts conformance verification between different services and static analysis of behavioral properties becomes one of the most promising research directions. The aim of the tools session is presenting working prototypes designed exploiting the experience derived from concurrency theory (and formal methods in general) in order to strengthen the collaboration with industry and resulting in a strong impact on the standardization phase of composition languages and of web services technologies in general. LIST OF TOPICS The topics of interest include, but are not limited to: * Orchestration engines for Web services * Frameworks for recovery mechanisms in Web services composition * Static analyzers and verificators of behavioral properties * Contracts conformance checkers * Frameworks for securing Web services SUBMISSION MODALITIES To submit please send the information below to: [EMAIL PROTECTED] Submissions must include: * Name of the tool * Name(s) of the author(s) * Name(s) of the person(s) presenting the demo at the workshop * A short abstract presenting the tool and the underpinning theory. It should describe the way in which the theory benefits the implementation. * A link to a web site presenting the project. Submissions deadline: 3 August 2005 DEMO MODALITIES The demos presentation will be held as a special session of WS-FM 2005. Each presentation will take about 25 minutes plus 10 for the discussion. CONTACTS * Mario Bravetti ([EMAIL PROTECTED]) * Roberto Lucchi ([EMAIL PROTECTED]) * Manuel Mazzara ([EMAIL PROTECTED]) * Gianluigi Zavattaro ([EMAIL PROTECTED]) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Gtk2Hs version 0.9.8 released
On Fri, 2005-06-24 at 12:43 +0100, Duncan Coutts wrote: > Gtk2Hs - A Haskell GUI library based on the Gtk+ GUI Toolkit. [..] > Please report all problems to [EMAIL PROTECTED] > Contributions and feedback are also most welcome. Sorry, this address should be [EMAIL PROTECTED] Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: package mounting
(By the way, sorry about cross-posting again. People have already replied to just 'haskell@' and just 'libraries@' but I'll try to stick to 'libraries@' after this since it seems that some users' mail clients show them two copies otherwise) > This idea has been raised before, but it was a while back, and we called > it "grafting". Here's the start of the thread, which went on for quite > some time: > > http://www.haskell.org/pipermail/libraries/2003-August/001310.html Actually it looks like that is slightly different from my idea, perhaps I should have expounded a bit more in my original post. Correct me if I'm wrong, but in my proposal: - grafting/mounting would be done per compilation unit. In yours it seems it would be done per (user, system). - configuration of graft/mount points would be done at compile time, zero or one times per package import option. In yours it would be at package install time. I think my proposal is better. In it there would be no cross-system compatibility issues: since each program would specify where its imported packages get mounted itself, you could write a Haskell program on one system and be assured that someone else could use it on another system without problems. I think this is a rather important property and we shouldn't allow it to be broken - a warning that, as you say, "This wouldn't be recommended though: any source code you write won't compile on someone else's system that doesn't have the same convention" is quite insufficient in my opinion! Plus, I think the ability to remount packages at non-standard locations is an important one, but for the above reason your proposal makes it too dangerous and therefore unusable in practice. Our proposals agree on this point: > The implementation must obey the following rule: > When compiling a module belonging to a package, that package > is temporarily grafted into the root of the module hierarchy. It was kind of "implicit" in my proposal though. I think the "alternative design" which is mentioned in your proposal is interesting: > Alternative design: modules in the current package could be specified > explicitly, perhaps by prefixing them with '.'. This would avoid the > possibility of overlap between the current package and the global > hierarchy, at the expense of having to add lots of extra '.'s. I think that might be a useful feature. Obviously one could introduce the '.' syntax and still allow the present sytax to be used for backward compatibility. Frederik -- http://ofb.net/~frederik/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Gtk2Hs version 0.9.8 released
Gtk2Hs - A Haskell GUI library based on the Gtk+ GUI Toolkit. Version 0.9.8 is now available from: http://haskell.org/gtk2hs/ Changes since 0.9.7: * much greater API coverage, including the new Gtk+ 2.6 APIs * Yampa/wxHaskell-style properties added for all widgets * improved reference documentation, there is more of it and the docs for each module are now split into sections. * works with GHC 6.4 * there is now an easy-to-use installer for Windows * build process now works in 80Mb of RAM rather than 380Mb * added functions for manipulating Pixbufs using the Haskell mutable array interface * fixed a limitation on signal handlers on Sparc machines * minor API changes * minor bug fixes * completed GPL to LGPL conversion * internal code cleanups and improvements The API changes are documented here: http://haskell.org/gtk2hs/archives/2005/06/20/api-changes-between-gtk2hs-097-and-098/ Other changes since the last release announcement: * new screenshots, including HRay and HanDict: http://haskell.org/gtk2hs/screenshots/ * we are now included in the Gnome news feed: http://planet.gnome.org/news/ Gtk2Hs feature highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.6 * bindings for several Gnome modules: * libglade for loading GUIs from xml files at run-time. This allows you to design your user interface visually with the Glade user interface builder. (This works on Windows too.) * GConf, Gnome's system for storing app preferences * SourceView, code editor widget with syntax highlighting * the Mozilla browser rendering engine in a widget * API reference documentation * multi-platform support with native look * LGPL licence Platforms and requirements: * an installer for Windows is available * packages are now available for Fedora Core 3,4 and Gentoo * packages for other platforms should become available soon * builds from source on Linux, Windows, MacOS X and Solaris * builds with GHC 6.4.x, 6.2.x, 6.0.x and 5.04.x * works with Gtk+ version 2.0 through to 2.2, 2.4 and 2.6 * optional Gnome support requires Gnome 2.0 or better * optional Mozilla support requires Mozilla 1.4 or better Goals for the 1.0 release: * autumn 2005 release * a stable API for the 1.0.x series * complete coverage of the Gtk+ API (we're about 90% there now) * support for OpenGL 3D rendering API * support for cairo 2D rendering API * bindings for more Gnome modules * introductory and other tutorials * packages for all popular platforms Please report all problems to [EMAIL PROTECTED] Contributions and feedback are also most welcome. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Dynamic binding
> If we were on an OOP mailing
> list, I could ask for days how to simulate pattern matching and
> algebraic types---and get a nonsensical runaround involving the
visitor
> pattern and huge swaths of unreadable code.
In such a case, I would be happy if someone told me that there is work
like this: http://www.cs.cornell.edu/Projects/jmatch/
People who wrote those papers clearly have thought harder of the
problem than most subscribers to the preconceived OOP mailing list.
> Ralf, I think it's incumbent on you, having said several times "that
> isn't solving the problem", to more clearly explain what problem you
> think exists and cannot be solved gracefully
I am sure I said it.
Also, Oleg and I should be fairly clear on all this in the OOHaskell
paper.
http://www.cwi.nl/~ralf/OOHaskell Major revision 13 June 2005
We will be grateful for additional comments and questions,
and I am happy to summarize all feedback we get,
if not on this mailing list, then in the paper's appendices,
and elsewhere.
Anyway, as it is incumbent on me to explain,
I try to be as concise as I can get at 4.00am:
[This should also cover Andreas' question.]
1. The original poster asked:
> What would be the normal way for a Haskell programmer
> to handle the typical shape example in beginner OO
> tutorials?
2.
I take for granted that "typical shape example" is very
well abstracted in this famous benchmark:
http://onestepback.org/articles/poly/
http://www.angelfire.com/tx4/cus/shapes/
The essence of the typical shape example is the following:
a there are different kinds of shapes (say rectangle, circle, whatever),
b which are organized in a subtyping hierarchy, and
c each kind of shape supports a subclass-specific draw method;
d the interface of shapes allows for mutation/observation of state,
e and eventually we want to process collections of shapes
3.
Note that e) looks arbitrary at first sight,
but it is crucial because shape apps will
involve instances of the Composite pattern.
Also note that the original poster indeed said:
std::list shapes;
for(std::list::iterator it = shapes.begin();it !=
shapes.end();++it)
{ (*it)->draw(...); }
Also note that the
body of the for loop happens to be a single
statement that invokes draw, but obviously we must keep in mind
what happens if the body is a compound statement.
4.
Where did I say "that isn't solving the problem"?
((
For the record,
I did *not* say so when Lennart posted his proposal.
I only mentioned that this proposal has the extensibility
problem and that ("minor issue") it needs extra effort to
recover the same degree of type distinction as in the normal
OO approach.
))
Indeed,
I did strongly disagree regarding the faithfulness of Bulat's
attempts. He made two proposals. The first one basically
suggested:
- do not build a list of shapes,
- do rather build a list of (lazy) applications of draw methods to shape
construction arguments
- then do not map over a list of shapes to perform functionality per
element
- do rather map over a list of expressions to sequence their effects.
If you think of it,
we can get rid of the generality of Haskell's map this way,
which is something that others have thought of:
http://lambda-the-ultimate.org/node/view/613
The second proposal by Bulat goes as follows:
(again I save band with by not showing the actual code)
- define a single *non-parameterized* datatype ShapeInterface
- construct all sorts of shapes as terms over this monomorphic type
- allow for state by IOref allocation before returning the shape terms
- do *not* cover the problem of shapes with different interfaces
- that is do really just pretend that all shapes have the same type
- do therefore simplify away the issue of different types for different
kinds of shapes
- based on this simplification, build a homogeneous list of shapes
- and do a reasonable loop with type-specific draw method invocations
indeed.
Again, if you think of it, we can adopt the same simplification
strategy to Haskell. That is, in Haskell 20??, superclass constraints
will not be allowed. We will recommend to define a single class in
the recompilable Prelude to which we add methods as we encounter them.
Ralf
P.S.: I just realized that there is no OOCobol solution in the shapes
repository. I sign for it.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
