June 2005 - Haskell - Haskell.org

Re: ANNOUNCE: GHC survey results
by John Meacham 28 Jun '05

28 Jun '05

On Tue, Jun 28, 2005 at 11:30:04AM -0400, Jim Apple wrote: > > Some people would like features removed (implicit parameters was > > mentioned a couple of times). Linear implicit parameters is a clear > > candidate for removal. > > I don't understand the motivation for this. Implicit parameters do weird > things with the monomorphism restriction, but when I'm worried about > that, I choose not to use them together. > > Why remove a feature from a product? Why not, instead, just choose to > not use it? implicit parameters are inherently broken according to some people (including me). There is no reason to remove them immediatly, but if it ever comes up that the code for them is holding back some other change, I would say dump them rather than try to work around or modify it. However, I would like to explore linear parameters more. I think a main issue with them is that they are mixed in with implicit parametrs and hence share their problems. An extension I was considering for jhc goes like this: in addition to normal variables, you may have linear variables which start with a %. linear variables may be used and bound exactly like normal variables. The only differences are as follows. linear variables automatically get a (Splittable a) constraint, they must be in class Splittable. and the following desugaring occurs. f %vs x y = g %vs <> h %vs z where z = name %vs x + y becomes f _vs x y = g _vs1 <> h _vs2 y x where z = name _vs3 x + y (_vs1,_nvs1) = split _vs (_vs2,_nvs2) = split _nvs1 (_vs3,_nvs3) = split _nvs2 where _vs is some unique name. basically the transformation is to change a linear variable to a normal one, replace each occurance of the linear variable with a unique name, bind the unique names to split versions of of the original ,now normal, binding. I think this gives all the advantages of linear parameters with a much simpler binding and semantics. an example of how this might be used is renameTerm %ns (EAp a b) = EAp (renameTerm %ns a) (renameTerm %ns b) renameTerm %ns (Let v e) = Let v' (renameTerm %ns e) where v' = rename v newname (newname:_) = %ns -- pull off first element of namesupply ... this assumes %ns is an infinite list of unique names. - note that %ns and ns are completly different variables with no relation. - any binding whether a let, where, function argument or monad generator can create a linear variable as long as it is in class Splittable, they are not special in any way. - The desugaring is really simple - there is no implied order of evaluation or modification of function structure like with monads. - none of the implicit parameter oddness. Comments? and yes, I know the term 'variable' is a misnomer when dealing with haskell :) John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

ANNOUNCE: GHC survey results
by Simon Marlow 28 Jun '05

28 Jun '05

We've finally digested the results of the GHC survey, and you can find our analysis here: http://www.haskell.org/ghc/survey2005-summary.html There's a lot to take in, but it's an interesting read. Enjoy! -- The GHC Team.

3 2

[ANNOUNCEMENT]: Two Postdoctoral Research Fellowships in Functional Programming
by Kevin Hammond 28 Jun '05

28 Jun '05

[With apologies in advance for any duplication. Kevin] Heriot-Watt University, School of Mathematical & Computer Sciences/ University of St Andrews, School of Computer Science Two Postdoctoral Research Positions in Embedded Software for Visual Sensing on Autonomous Vehicles £21,640 - £29,128 per annum Applications are invited from well-qualified individuals for this BAE SYSTEMS supported project. The first post, to be held at Heriot-Watt University, involves the evaluation of functional and imperative approaches to constructing embedded image processing software to perform simultaneous motion computation and environmental mapping. The second post, to be held at the University of St Andrews, involves the development of static analyses of time and space behaviour for the embedded software. Appointments will be made for one year in the first instance with a strong expectation of continuing to a further year. The starting date will be 5th September 2005 or as soon as possible thereafter. The closing date for applications is July 8th. For further details of the HWU post please contact Dr Greg Michaelson ( greg(a)macs.hw.ac.uk ) or Prof Andy Wallace ( A.M.Wallace(a)hw.ac.uk ). For application details please contact the Human Resources Office, Heriot-Watt University Edinburgh EH14 4AS, telephone 0131 451 3475 (24 hours) Minicom 0131 451 8212 or email hr(a)hw.ac.uk quoting Ref 88/05/*. The advertisement and further particulars may be viewed at: http://www.hw.ac.uk/hr/v_research.php . For further details of the StA post please contact Dr Kevin Hammond (kh(a)dcs.st-and.ac.uk) Please quote ref: CD243/05. Application forms and further particulars are available from Human Resources, University of St Andrews, College Gate, North Street, St Andrews, Fife KY16 9AJ, (tel: 01334 462571, by fax 01334 462570 or by e-mail Jobline(a)st-andrews.ac.uk. The advertisement and further particulars can be viewed at http://www.st-andrews.ac.uk/hr/recruitment/vacancies.

1 0

Re: ANNOUNCE: GHC survey results
by Dinko Tenev 28 Jun '05

28 Jun '05

On 6/28/05, Jim Apple <japple(a)freeshell.org> wrote: > > Some people would like features removed (implicit parameters was mentioned a couple of times). Linear implicit parameters is a clear candidate for removal. > > I don't understand the motivation for this. Implicit parameters do weird > things with the monomorphism restriction, but when I'm worried about > that, I choose not to use them together. > > Why remove a feature from a product? Why not, instead, just choose to > not use it? It depends on what you mean by "using it," of course, but sometimes that's not a matter of choice (e.g. when you're reading others' code.) Cheers, D. Tenev

1 0

AVL library update available.
by Adrian Hey 26 Jun '05

26 Jun '05

Hello, At.. http://homepages.nildram.co.uk/~ahey/HLibs/Data.Tree.AVL/ ..you can find the another release of the Data.Tree.AVL library. A few notes about this release: The library is not intended to provide an elegant api or to be a model of what general purpose collection classes should look like. It just aims to provide raw AVL operations as efficiently and flexibly as possible. This version and the Data.COrdering library have had a major purge of 1 line trivia (which I decided were really little more than name space pollution in practice). I'm sure that anybody using it is quite capable of writing whatever trivia they need so I decided to try and restrict myself to the stuff you really don't want to have to write yourself if you can avoid it. So the Map module has been removed completely. This release has also had a Zipper module added, which should be useful for implementing many of those awkward operations not covered by the main library. Earlier (on the libraries list I think), I said I would also include AVL tree based clones of Data.Set and Data.Map. I did start on this but then stopped as I don't think there's any point. The native AVL api is more useful (in my completely biased and not at all humble opinion :-). But these clones are about 75% complete so if somebody really wants them finished I might be persuaded to do this. In the meantime there's are some conversion utilities to convert between AVL trees and Data.Set, Data.Map. The library is not yet cabalised as there are apparently some difficulties using cabal with the ghc -split-objs option (which I use to reduce the bloat of executables). But the makefile enclosed should work OK on *nix environments for ghc 6.4 only (it uses new package descriptions so won't work with earlier ghc versions). The source code should be OK with other Haskells too, but the makefile assumes ghc. I haven't tried building under windows (shouldn't be too hard but makefile would probably need some hacking). I'd like to think this is reasonably complete (and stable) now, but it almost certainly isn't complete. So if anybody has any feature requests please let me know. I've marked the modules as being "stable", so I promise not to introduce any radical api changes or disappearances in future releases. Regards -- Adrian Hey

1 0

ANNOUNCE: Gtk2Hs version 0.9.8 released
by Duncan Coutts 25 Jun '05

25 Jun '05

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-09… 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 gtk2hs-users(a)sourceforge.net Contributions and feedback are also most welcome. Duncan

1 1

WS-FM 2005 2nd Call For Papers (submission deadline extended to may 6)
by Mario Bravetti 24 Jun '05

24 Jun '05

====================================================================== 2nd International Workshop on Web Services and Formal Methods (WS-FM 2005) 1-3 September 2005, Versailles, France http://cs.unibo.it/WS-FM05 Co-located with EPEW'05 2nd European Performance Evaluation Workshop ====================================================================== SCOPE Web Services technology aims at providing standard mechanisms for describing the interface and the services available on the web, as well as protocols for locating such services and invoking them (e.g. WSDL, UDDI, SOAP). Innovations are moving towards two main directions: The first one tends to the definition of new standards that support the specification of complex services out of simpler ones (the so called Web Service orchestration and choreography). Several proposals have been already set up: BPML, XLANG and BizTalk, WSFL, WS-BPEL, WS-CDL, etc... The second approach consists of the design of new (meta-)Web Services to be exploited at run-time by other Web Services: e.g. managing the cooperation of Web Services or acting as dynamic registry services. Formal methods, which privide formal machinery for representing and analysing the behavior of communicating concurrent/distributed systems, may potentially play a fundamental role in the development of such innovations. First of all they may help in understanding the basic mechanisms (in terms of semantics) which characterize different orchestration and choreography languages and to focus on the essence of new features that are needed. Secondly they may provide a formal basis for reasoning about Web Service semantics (behaviour and equivalence): e.g. for realizing registry services where retrieval is based on the meaning of a service and not just a Web Service name. Thirdly also studies on formal coordination paradigms can be exploited for developing mechanisms for complex run-time Web Service coordination. Finally, given the importance of critical application areas for Web Services like E-commerce, the development of the Web Service technology can certainly take advantage from formal analisys of security properties and performance in concurrency theory. The aim of the workshop is to bring together researchers working on Web Services and Formal Methods in order to activate a fruitful collaboration in this direction of research. This, potentially, could also have a great impact on the current standardization phase of Web Service technologies. LIST OF TOPICS The topics of interest include, but are not limited to: - Protocols and standards for WS (SOAP, WSDL, UDDI, etc... ) - Languages and descripion methodologies for Coreography/Orchestration/Workflow (BPML, XLANG and BizTalk, WSFL, WS-BPEL, WS-CDL, YAWL, etc... ) - Coordination techniques for WS (transactions, agreement, coordination services, etc...) - Semantics-based dynamic WS discovery services (based on Semantic Web/Ontology techniques or other semantic theories) - Security, Performance Evaluation and Quality of Service of WS - Semi-structured data and XML related technologies - Comparisons with different related technologies/approaches SUBMISSIONS Submissions must be original and should not have been published previously or be under consideration for publication while being evaluated for this workshop. Papers are to be prepared in LNCS format and must not exceed 15 pages. Accepted original papers will be published in the workshop proceedings. It is planned to publish the proceedings in the Springer Lecture Notes in Computer Science (LNCS) series ( www.springeronline.com/lncs ). As done for the previous WS-FM'04 workshop, we intend to publish a journal special issue inviting full versions of papers selected among those presented at the workshop. IMPORTANT DATES May 6, 2005: Submission deadline (EXTENDED) June 10, 2005: Notification of acceptance June 20, 2005: Camera ready September 1-3, 2005: Workshop dates PROGRAM CO-CHAIRS Mario Bravetti and Gianluigi Zavattaro PROGRAM COMMITTEE: Marco Aiello University of Trento, Italy Jean-Pierre Banatre University of Rennes1 and INRIA, France Boualem Benatallah University of New South Wales, Australia Karthik Bhargavan Microsoft research Cambridge, UK Manfred Broy Technische Universitat Munchen, Germany Roberto Bruni University of Pisa, Italy Michael Butler University of Southampton, UK Fabio Casati HP Labs, USA Rocco De Nicola University of Florence, Italy Schahram Dustdar Wien University of Technology, Austria Gianluigi Ferrari University of Pisa, Italy Jose Luiz Fiadeiro University of Leicester, UK Peter Furniss Choreology Ltd, UK Stephanie Gnesi CNR Pisa, Italy Reiko Heckel University of Leicester, UK Nickolas Kavantzas Oracle Co., USA Leila Kloul Université de Versailles, France Mark Little Arjuna Technologies Limited, UK Natalia López University Complutense of Madrid, Spain Roberto Lucchi University of Bologna, Italy Jeff Magee Imperial College London, UK Fabio Martinelli CNR Pisa, Italy Shin Nakajima National Institute of Informatics and JST, Japan Manuel Nunez University Complutense of Madrid, Spain Fernando Pelayo University of Castilla-La Mancha, Albacete, Spain Marco Pistore University of Trento, Italy Wolfgang Reisig Humboldt University, Berlin, Germany Vladimiro Sassone University of Sussex, UK Frank Van Breugel York University, Toronto, Canada Friedrich Vogt Technical University of Hamburg-Harburg, Germany

1 1

Re: package mounting
by Frederik Eaton 24 Jun '05

24 Jun '05

(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/

1 0

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

24 Jun '05

> 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<shape *> shapes; for(std::list<shape *>::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.

1 0

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

23 Jun '05

Lennart, from a textbook perspective I agree that this solution should be mentioned to make it easy for non-Haskellers to get into the subject. However (as you of course know, but I just don't understand why you don't dare to mention the limitations a) and b) ...) a) Your constructor-based approach is not extensible. (Adding another form of shape requires touching existing code and recompilation.) I reckon that the (normal implied OO) point of the Shapes example, to a considerable extent, is also about the potential addition of new shapes. Saying we can take a snapshot of shape "types" and burn them into constructors of an algebraic type does not give me the impression of Haskell being ahead in type system and programming language arena. b) This "burn subtypes into constructors" leads me to a second weakness. By doing so, we have lost the precision of the original type dichotomy circle vs rectangle vs square since these guys are now all represented as terms of type. Of course, you might say that we could define dedicated types for circle, rectangle and square so that we would use the shape type merely as a *sum* type. (So constructors only serve for embedding.) This way we could at least recover the typing precision of OO. So I am willing to give in on b) but I maintain a) and I really miss extensible datatypes :-) Ralf (doing too much C# these days I guess) > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Lennart Augustsson > Sent: Thursday, June 23, 2005 7:30 AM > To: Andrew Ward > Cc: haskell(a)haskell.org > Subject: Re: [Haskell] Dynamic binding > > Andrew Ward wrote: > > 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? > > > Unlike previous posters that have shown various ways to simulate > object oriented programming I'm going to try and answer the > question. :) > > Here is what I would do: > > ---------------------- > data Shape > = Circle Point Radius > | Square Point Size > > draw :: Shape -> Pict > draw (Circle p r) = drawCircle p r > draw (Square p s) = drawRectangle p s s > > moveTo :: Shape -> Point -> Shape > moveTo (Circle _ r) p = Circle p r > moveTo (Square _ s) p = Square p s > > shapes :: [Shape] > shapes = [Circle (0,0) 1, Square (1,1) 2] > > shapes' :: [Shape] > shapes' = map (moveTo (2,2)) shapes > ---------------------- > > This is in rather stark contrast to the object oriented way of doing the > same things. For reference, here's how you could do it : > > ---------------------- > class IsShape shape where > draw :: shape -> Pict > moveTo :: Point -> shape -> shape > > data Shape = forall a . (IsShape a) => Shape a > > data Circle = Circle Point Radius > instance IsShape Circle where > draw (Circle p r) = drawCircle p r > moveTo p (Circle _ r) = Circle p r > > data Square = Square Point Size > instance IsShape Square where > draw (Square p s) = drawRectangle p s s > moveTo p (Square _ s) = Square p s > > shapes :: [Shape] > shapes = [Shape (Circle (0,0) 10), Shape (Square (1,1) 2)] > > shapes' :: [Shape] > shapes' = map (moveShapeTo (2,2)) shapes > where moveShapeTo p (Shape s) = Shape (moveTo p s) > ---------------------- > > Both ways of doing it contains the same information, it's just that > it's organized in different ways. > > The "functional way" centers around the type Shape. You can find out > all about what shapes exist by looking at the type definition. For > each operation on shapes (draw & moveTo) you describe what they do for > the different shapes. > > The object oriented way centers more around the objects (surprise, > surprise). For each kind of object you say that it's a shape and how > the shape operations work. > > > So, which is better? I don't think you can say one is better than the > other. They have different strengths. With the object oriented way it > is easy to answer questions like "What is a Circle?", whereas with the > functional way it is easy to answer "How do you draw a Shape"? > Likewise, with the object oriented way it's easier to add a new kind > of shape and with the functional way it's easier to add a new > operation. > > To me it's a matter of taste. I like the functional taste; my brain > has been warped over many years. > > -- Lennart > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

2 1