[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons

[wren ng thornton]

Ivan Lazar Miljenovic wrote:
> Stephen Tetley <stephen.tetley at gmail.com> writes:
> 
>> I think it was Hugs compliant as least for some revisions - I seem to
>> remember looking at it before I switched to GHC.
> 
> People still use Hugs? :p

MPJ uses it for teaching Haskell because it's a lot easier to install 
than GHC. I've heard tale of people using it in the embedded world 
(again because of easy portability), though I haven't witnessed it to 
know how recent that is.

I do my best to retain compatibility with Hugs for my Hackage libraries, 
and I use Hugs to define the boundary between "semiportable" (i.e., not 
H98 but still portable) vs "nonportable" (i.e., GHC-only). Doing so has 
highlighted some simple bugs in Cabal which, AFAIK, haven't been fixed 
yet. Perhaps because I seem to be the only advocate for trying to keep 
Hugs support alive, and I don't know the Cabal code well enough to make 
the fix myself.


> A bit more seriously: is there any listing anywhere of which extensions
> Hugs supports?

Cabal has a partial listing embedded in its code, though I can't seem to 
find a textual version at the moment. In general, Hugs has all the 
features of GHC 6.6: FFI, CPP, MPTCs, FunDeps, OverlappingInstances,... 
I'm forgetting off-hand whether it has Rank2Types/RankNTypes, but I 
think so. The one notable difference between Hugs and GHC6.6 is that it 
does not have IncoherentInstances, and instead supports a 
different/incompatible way of trying to solve that problem.

Of course, since it's GHC6.6-era that means it doesn't support LANGUAGE 
pragma to enable these features. The -98 flag enables most of the 
extensions with separate flags for OverlappingInstances, 
Not-IncoherentInstances, and CPP (or any other preprocessor); and in 
order to use the FFI you must first run ffihugs in order to compile the 
bindings. Because the shift from GHC6.6 to GHC6.8 was so significant, 
it'd be nice if someone put out a maintenance version of Hugs which adds 
support for LANGUAGE pragma and similar compilation interface issues, 
even if the underlying code base remains the same. One can dream, eh?


> Definitely serious: if anything, I would care more about ensuring
> compatability with JHC, UHC, etc. than Hugs nowadays.

Certainly JHC and UHC should be targeted for compatibility. However, 
doing so seems unlikely to come at the cost of compatibility with Hugs. 
Hugs implements H98 along with the most venerable and widely used 
extensions. Consequently, the language Hugs understands happens to be 
the same one that's the goal of modern Haskell compilers like JHC and 
UHC. However little maintenance Hugs is getting, it captures all of 
"classic Haskell". The hallmarks of "new Haskell" like GADTs and type 
functions are, so far as I'm aware, considered a more distant goal for 
alternative compilers.

-- 
Live well,
~wren