Fran and HGL broken with Feb 2001 Hugs

[Alastair Reid]

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.