- Haskell - Haskell.org

Package "mounting" proposal
by Sven Moritz Hallberg 17 Jul '06

17 Jul '06

Hi lists, (I hope my cross-posting is okay, but somehow this post seems to apply to all of you, so here goes...) I've recently noticed that folks at GHC HQ are working on a way to resolve the problem of importing two modules with the same name from different packages. There is a proposal[1] on the GHC wiki calling for a syntax extension for 'import' statements in Haskell modules so that the package (and version) to import from can be specified explicitly. There is a second ("extended") proposal[2], which calls for the ability to import (subtrees of) the module hierarchy exposed by a package and attach it to the global module namespace at an arbitrary point, analogous to mounting a filesystem in Unix. This proposal was appearently inspired by a post to the libraries mailing list by Frederik Eaton[3]. I agree with Frederik that it would be very nice to remove the burden of writing out long package or hierarchy prefixes in modules, and just work in some previously defined context. I'd like to propose yet another alternative to the existing two proposals that follows [2] in trying to satisfy [3] but differes from it in the following ways: - It doesn't require an extension of the existing Haskell syntax. - It can be implemented by extending Cabal alone (AFAICT). In particular, I propose to drop the assumption that Haskell modules are closed entities but rather always consider them to be seen in the context of a particular _package_. The package is now made responsible for assembling an appropriate (hierarchical) module namespace to which imports in the packaged modules are taken to refer. To this end, the current 'depends:' entry in a package description would be replaced by a more general "mounting" construct, i.e. "mount package foo at Foo.Bar in the module hierarchy". Optionally, as in [2], only a subtree of "foo" could be selected, or only a specific version of "foo". While I'm at it, I had to evaluate how this proposal would interact with the "ECT" module versioning scheme, I've proposed earlier[4]. I'd like to rework that scheme to this proposal. In ECT, a library author guarantees to his users that their imports will never break by providing different (numbered) variants of the library modules whenever their interface changes. By keeping the old variants as re-exports of updated versions, the author can record compatibilities. This carries the burden for users to annotate each import with a version number. If we lift the principles of ECT to the package level in accord with this proposal, that burden largely evaporates. Keeping the promise of "eternal backwards-compatibility", however, requires an (obvious) extension to the way Cabal deals with version numbers... First of all, package "mounts" must be able to say "this version, or any compatible one". Obviously, that's actually always what one wants, so it can be taken to be the only meaning of specifying "mount foo-1.3 at Foo.Bar". Then the question is just when to consider another version of foo compatible to 1.3. Obviously, only later versions should be considered, but when does compatibility end? Only the author of foo knows! She must specify it somehow. Two possibilities come to mind: 1. Add a field to the package description of foo (v1.4, say) that says "I'm backwards-compatible with 1.3." When building, this relation would have to be inspected to see whether any currently installed version of foo satisfies the dependency specified by the mount. 2. Declare a convention for version numbers to carry compatibility information, like the OpenGL standard, for example: If the new version is backwards-compatible, only the minor version number changes. If it isn't, the major version number must be incremented. I'd personally favour 2, as it would be easier to maintain for the author of foo (no compatiblity-field in the package description to update all the time) and also to implement in the build system (just a simple version comparison instead of a relation traversal to check a dependency). As a (more conservative?) variant of alternative 2, the third (instead of second) version component could be declared as "stays compatible", i.e. if only the third (or later) version component changes, the new version is assumed backwards-compatible, otherwise it's assumed incompatible. This would allow frequent incompatible updates without quickly getting large major version numbers... As for wasting space by keeping old versions around: Of course, if the new one is backwards-compatible, any old version can be removed. Otherwise, if it's "half-way" compatible, the author of foo can release a new backwards-compatible revision of the old version that reimplements (part of) the functionality in terms of the new operations, so the old version can be replaced by this leaner revision. Comments? Best regards, Sven [1]: http://cvs.haskell.org/trac/ghc/wiki/GhcPackages [2]: http://cvs.haskell.org/trac/ghc/wiki/GhcPackageNamespaces [3]: http://www.haskell.org/pipermail/libraries/2005-June/004009.html [4]: http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory

3 2

What would Haskell middleware look like?
by Paul Johnson 15 Jul '06

15 Jul '06

I've noticed that many other languages have a middleware to handle distribution and concurrency issues. Haskell has STM for shared-memory concurrency, but there is no mechanism (AFAIK) for distribution. So I've been having a think about what one might look like. The primary requirements seem to me to be: * Transactions: STM is great, and the concept should work for distributed computation as well. So you should be able to say something like: atomic $ do { send message1 remote1; send message2 remote2} Both remote1 and remote2 processes will have world-visible state modified by the messages, but either they both happen atomically or neither happens. * Pi Calculus I've been reading a bit about this, and I think I see the basic ideas. The middleware operations should have a formal semantics specified in the Pi calculus, on the grounds that its the best formalism currently available. That way we can prove that the operations preserve desirable properties. * Replication If you want a reliable distributed system you absolutely have to have replicated tasks. Haskell's strict control over side effects is a big strength here: the headache for reliable replication has always been threads doing non-deterministic stuff that gets them out of sync. How does the IO monad interact with this? Replicated threads cannot be in the IO monad because that doesn't guarantee determinism, but they need to interact with the real world somehow. * Configuration management Another big headache for middleware. If you are not careful it can turn out that the only way to upgrade a component in the system is to upgrade all the components simultaneously, which is not really an option in a big system that has to stay up 24x7. Component names are not the right place for version numbers, and you need some formal definition of upward compatibility. Could XML have a place here? It does let you do duck typing. Or can we come up with something stronger? * Serialization of circular data structures. "show" is fine for non-looping structures, but what about: let x = 1 : y y = 2 : x Can we find a way of transmitting such a structure? Thats all I can think of for now. Paul.

3 2

The History of Haskell
by Simon Peyton-Jones 15 Jul '06

15 Jul '06

Friends, Phil Wadler, John Hughes, Paul Hudak and I have been writing a paper about the The History of Haskell We've submitted an earlier draft to the History Of Programming Languages conference (HOPL'07), and it's been accepted. We have to submit a more-or-less final draft by 1 September. This message is to invite you to read it, tell us what you think, and help us improve it. Here it is, along with a Wiki page for you to write comments: http://haskell.org/haskellwiki/History_of_Haskell Enjoy! Simon PS: If you followed a link earlier today, and have a version dated Feb, discard it. The one you want is dated July 14th.

2 1

ANN: System.FilePath 0.9
by Neil Mitchell 14 Jul '06

14 Jul '06

Hi, I have written a System.FilePath module in part based on the one in Yhc, and in part based on the one in Cabal (thanks to Lemmih). The aim is to try and get this module into the base package, as FilePath's are something many programs use, but its all too easy to hack up a little function that gets it right most of the time on most platforms, and there lies a source of bugs. This module is Posix (Linux) and Windows capable - just import System.FilePath and it will pick the right one. Of course, if you demand Windows paths on all OS's, then System.FilePath.Windows will give you that (same with Posix). Written in Haskell 98 + Heirarchical Modules. Homepage: http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php Haddock: http://www-users.cs.york.ac.uk/~ndm/projects/filepath/System-FilePath.html Darcs: darcs get http://www.cs.york.ac.uk/fp/darcs/filepath Source: http://www.cs.york.ac.uk/fp/darcs/filepath/System/FilePath.hs Tests: http://www.cs.york.ac.uk/fp/darcs/filepath/Tests.hs Readme: http://www.cs.york.ac.uk/fp/darcs/filepath/readme.txt If you go to the haddock page there are a few little examples at the top of the file. The Yhc project, hquickfile and a few other utilites are already using this module succesfully. Comments welcome. Thanks Neil

1 0

ANN: Takusen 0.5
by Alistair Bayley 14 Jul '06

14 Jul '06

Oleg and I are pleased to announce the release of a new version of Takusen (it's been a while; so long that we don't remember the last version number we used). The most significant code change is a new internal design (courtesy of Oleg) which gives better separation of concerns like statement preparation, binding, and result-set processing. Also of note is a conversion to darcs, and hosting at haskell.org (thanks to Simon Marlow): darcs get http://darcs.haskell.org/takusen ... which also has the nice property that the Haddock documentation is browseable online: http://darcs.haskell.org/takusen/doc/html/index.html A comprehensive description of API usage can be found in the documentation for module Database.Enumerator: http://darcs.haskell.org/takusen/doc/html/Database-Enumerator.html We hope that the use of darcs will encourage contributions... Other changes: - support for multiple result sets returned from functions (PostgreSQL only). Oracle support for this is in the pipeline, which will allow use of nested cursors, and processing RefCursors returned as output parameters from procedure calls. Future plans: - Cabalisation - use of Data.Time instead of System.Time - ODBC and MS Sql Server backends For those of you unfamiliar with Takusen, here is our HCAR blurb: Takusen is a library for accessing DBMS's. It is a low-level library like HSQL, in the sense that it is used to issue SQL statements. Takusen's "unique-selling-point" is a design for processing query results using a left-fold enumerator. For queries the user creates an iteratee function, which is fed rows one-at-a-time from the result-set. We also support processing query results using a cursor interface, if you require finer-grained control. Currently we fully support Oracle, Sqlite, and PostgreSQL. Alistair

1 0

Type-Level Naturals Like Prolog?
by Jared Warren 14 Jul '06

14 Jul '06

Haskell's type checking language is a logical programming language. The canonical logical language is Prolog. However, Idealised Prolog does not have data structures, and does Peano numbers like: natural(zero). natural(x), succ(x,y) :- natural(y) And I believe (but cannot confirm): succ(zero,y). succ(x,y) :- succ(y,z) Why can't Haskell (with extensions) do type-level Peano naturals in the same fashion? The code would be something like: > data Zero > > class Natural x where > toInt :: x -> Integer > instance Natural Zero where > toInt _ = 0 > instance (Natural x, Succ x y) => Natural y where > toInt y = undefined + 1 > > class Succ x y > instance Succ Zero y > instance Succ x y => Succ y z > > zero = toInt (undefined :: Zero) -- THIS SUCCEEDS > > one = toInt (undefined :: (Succ Zero x) => x) -- THIS FAILS Thanks, Jared Warren

3 2

AngloHaskell: Gathering at Cambridge.
by Lemmih 13 Jul '06

13 Jul '06

Greetings fellow Haskellers, As you may or may not know, the great folks at Microsoft Research are interviewing people from the end of this month to the 11th of August. In light of this event, I hereby call attention to the AngloHaskell gathering: http://haskell.org/haskellwiki/AngloHaskell Everyone is welcome. Our agenda includes beer, hacking and other fun. -- Friendly, Lemmih

1 0

Last CFP (4 days left): 2nd Int'l Workshop on Automated Specification and Verification of Web Systems (WWV'06)
by Santiago Escobar 12 Jul '06

12 Jul '06

[ We apologize for multiple copies ] ******************************************************************* 2nd International Workshop on Automated Specification and Verification of Web Systems (WWV'06) Cyprus, November 15-19, 2006 (Track of ISoLA 2006) http://www.dsic.upv.es/workshops/wwv06 ******************************************************************* SCOPE The increased complexity of Web sites and the explosive growth of Web-based applications has turned their design and construction into a challenging problem. Nowadays, many companies have diverted their Web sites into interactive, completely-automated, Web-based applications (such as Amazon, on-line banking, or travel agencies) with a high complexity that requires appropriate specification and verification techniques and tools. Systematic, formal approaches to the analysis and verification can address the problems of this particular domain with automated and reliable tools that also incorporate semantic aspects. We solicit paper on formal methods and techniques applied to Web sites, Web services or Web-based applications, such as: * rule-based approaches to Web site analysis, certification, specification, verification, and optimization * formal models for describing and reasoning about Web sites * model-checking, synthesis and debugging of Web sites * abstract interpretation and program transformation applied to the semantic Web * intelligent tutoring and advisory systems for Web specifications authoring The WWV series provides a forum for researchers from the communities of Rule-based programming, Automated Software Engineering, and Web-oriented research to facilitate the cross-fertilization and the advancement of hybrid methods that combine the three areas. LOCATION WWV'06 will be held in November in Cyprus as a Special Track of the 2006 International Symposium on Leveraging Applications of Formal Methods, Verification, and Validation (ISoLA 2006). SUBMISSION PROCEDURE Submissions must be received by July 16, 2006. Submitted papers should be at most 15 pages in the Lecture Notes in Computer Science (LNCS) style. Submitted papers should include an abstract and the author's information. See the author's instructions of LNCS style at http://www.springer.de/comp/lncs/authors.html. PUBLICATION Accepted papers will be published in a preliminary proceedings volume, which will be available during the workshop. Publication of the workshop post-proceedings by IEEE Computer Society Press is envisaged. PROGRAM CO-CHAIRS Maria Alpuente (Technical University of Valencia, Spain) Moreno Falaschi (University of Siena, Italy) WORKSHOP CHAIR Santiago Escobar (Technical University of Valencia, Spain) PROGRAM COMMITTEE Jose Julio Alferes (Universidade Nova de Lisboa, Portugal) Maria Alpuente (Technical University of Valencia, Spain) Demis Ballis (University of Udine, Italy) Francois Bry (University of Munich, Germany) Santiago Escobar (Technical University of Valencia, Spain) Francois Fages (INRIA Rocquencourt, France) Moreno Falaschi (University of Siena, Italy) Gopal Gupta (University of Texas at Dallas, USA) Shriram Krishnamurthi (Brown University, USA) Tiziana Margaria (University of Potsdam, Germany) I.V. Ramakrishnan (State University of New York at Stony Brook, USA) Leon van der Torre (University of Luxembourg, Luxembourg) IMPORTANT DATES Paper Submission July 16, 2006 Acceptance Notification September 17, 2006 Camera Ready October 15, 2006 Workshop November 15-19, 2006 (one day)

1 0

Lrc status
by Robert Dockins 12 Jul '06

12 Jul '06

Does anyone have any information about the current status of Lrc? Has it ever been released? Does it live somewhere else now? The homepage is apparently: http://www.di.uminho.pt/~jas/Research/ LRC/lrc.html It has a bunch of "coming soon" links, but the page hasn't been updated since about 2002. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

3 2

crash unsafeperformio stm
by Johannes Goetz 11 Jul '06

11 Jul '06

hi folks, i'm using ghc6 (apt-get install ghc6) on debian31. as far is i understand, the following program shouldn't crash. can somebody tell me why it does? thanks a lot. johannes. module Main(main) where import Control.Concurrent.STM import System.IO.Unsafe {-# NOINLINE a #-} a :: TMVar Int a = unsafePerformIO $ atomically $ newTMVar 123 main = do atomically $ takeTMVar a >>= putTMVar a ghc --make -fno-cse Test.hs -o test ./test Segmentation fault

2 2