[Haskell-cafe] Re: Rewriting a famous library and using the same
name: pros and cons
wren ng thornton
wren at freegeek.org
Tue Jul 6 01:04:18 EDT 2010
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
More information about the Haskell-Cafe