[Yhc] What is the status of the "york-compiler98" repo?

[Malcolm Wallace]

"Dimitry Golubovsky" <golubovsky at gmail.com> wrote:

> "http://darcs.haskell.org/york-compiler98/" receives some patches.
> Is this the place where the Yhc development is going on now? I see
> that PosLambda converter to Yhc Core is there.

The repo called "york-compiler98" is shared between yhc and nhc98.  It
contains only the source code for the compiler proper (which can be
built in two different ways, depending on which compiler you want).  It
contains no runtime system, no prelude, and no libraries.  The latter
components live in the main yhc and nhc98 repositories, and their build
systems must grab a copy of york-compiler98 before they can do anything.

> Does nhc98 have any Yhc Core support?

Not directly.  However, because the compiler code is so closely shared
between nhc98 and yhc, it is probably not too hard to make nhc98 produce
yhc core as an alternative output format.

> Hugs is more or less compatible with modern GHC libraries, but Yhc
> AFAIR used much older and smaller subset of them. Is libraries support
> in york-compiler98 any better than those included with Yhc repo?

AFAIK, yhc has never regularly built/tested any libraries except for a
forked subset of the "base" package.  On the other hand, nhc98 shares
(with ghc and Hugs) the source code for many of the commonly-used
packages, and includes them in the nightly builds so they are
pretty-much kept in working order.

Here are the packages that nhc98 builds and includes by default:
    haskell98 base polyparse
    array containers old-locale old-time filepath directory pretty
    process haskell-src random QuickCheck bytestring HaXml
    HUnit html xhtml packedstring Cabal parsec getopt

Here are some of the common ones that are not currently possible to
build with nhc98:
    arrows fgl hpc monadLib mtl network readline time unix

The latter packages are incompatible for usually one of two reasons:
    (a) not written in Haskell'98 (too many extensions)
    (b) uses too many low-level details of ghc's runtime system
        representation (e.g. Handles)

Regards,
    Malcolm