Dear Claus [and others],

it is not too nice if libraries have to depend on internal details of the Hugs distribution, but I assume they wouldn't if their author's had known any way around this.

I'm afraid the problem with the HGL is my fault. Back when I was the Hugs maintainer, and both the HGL and Fran were part of the Hugs distribution, it was easy to keep them in sync and, when I added experimental features to Hugs (like exception handling), decisions about where to place the experimental code were based on issues like how many people might come to depend on that feature rather than maintainability. And now that I maintain the HGL in my spare time, I can't always find the time to test it, work on bug reports, etc. as promptly as I'd like. In particular, the latest release of Hugs came shortly after a meeting with my current source of funding, coincided exactly with the first public release of my current project (Knit: a component definition and linking language for low-level systems code written in C and assembly language), and came shortly before a trip to Yale to work on a different aspect of the HGL, a short climbing vacation in Las Vegas and a paper deadline for a conference.

And, given that several very popular libraries were affected seriously by the latest release of Hugs, may I suggest that those libraries are added to the test-suite for Hugs?

I sympathise with the idea of having a central test suite for all the important Hugs libraries but there's a lot of things needing done with Hugs and, if I remember correctly, the current funding for Hugs maintenance is about to run out so I think I'd like to see Johan concentrate on the things that require central control like: o Coordinating bug fixes and enhancements. (This requires a small number (ideally one) of people with a global view of all development watching out for conflicts, worrying about basic software engineering issues like portability, maintainability, etc.) o Bringing Hugs and GHC back into line with each other. GHC's copies of the Hugs-GHC libraries have moved on a lot in the last few years whilst Hugs' have just held ground. There's now a very active library development mailing list at haskell.org and it looks like the GHC and NHC folk are about to make massive changes to the libraries. Hugs should be part of this. This will take some basic infrastructure to base the Hugs libraries on the same codebase as the {G,N}HC folk are using, some negotiating over library aesthetics, some negotiating when Hugs can't support a library design but could support a slightly different design, etc. [There are probably other tasks which require/benefit from having a single central coordinator.] On the other hand, I think testing is a task which distributes very well. It used to be the case that people on hugs-bugs would snatch up new beta releases and very quickly start sending in bug reports. These days, I don't see that same level of support from the Hugs community. Of course, if someone wanted to volunteer for the task of setting up a central test suite including all libraries considered useful or important by the community, I'm sure there'd be no objection from the current Hugs maintainer.

(*) Btw, what was the rationale for that change? Was it really necessary?

There was a bug in the existing implementation of concurrency. -- Alastair Reid ps The real heart of the HGL problem (beyond the error message currently reported) is an awkward interaction between the implementation of concurrency and exception handling (in the sense of "imprecise exceptions" like pattern match failure not IOErrors). (And, again, this is my fault since I'm the one who added both features to Hugs...) A fix for this has now been committed to the CVS repository and is being alpha-tested as you read this message.