"Dimitry Golubovsky"
"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