Yhc/FAQ

Part of Yhc (Download)

In relation to nhc98

Q) What did you think needed changing from nhc98?

A) nhc98's backend had several problems (not portable to Windows, high memory bug).

Q) nhc98 had a small size and a simple implementation, what about yhc?

A) Yhc has simpler bytecodes (not by much, but by a bit) and is designed to have a simpler implementation. Yhc needs fewer bytecodes to encode a program, and executes each bytecode slightly faster.

Q) I was interested in nhc, should I now be more interested in yhc?

A) Good question. Unfortunately there isn't a good answer yet - try them both and see which one you like. nhc98 has a better build system, with fewer external dependencies, and will generally just work if your machine is supported. yhc is in theory more portable, but you will need to spend longer working out how to get it up and running, and you will have to install lots of other software first.

Q) Does the Yhc back-end support everything that the current nhc98 back-end does?

A) Not yet. Nhc98 supports heap and time profiling whereas this hasn't been implemented yet, more crucially the FFI support in yhc is also not ready yet. However, in terms of simple Haskell 98, yhc does everything nhc98 does.

Portability

Q) How portable is Yhc itself?

A) If your platform already has GHC, plus a C compiler that at least looks slightly ANSI C compliant, plus a Python installation, plus a darcs installation, plus a scons installation, plus a svn installation, it could be a 10 minute port. Most of this time will be spent fighting with the build system rather than the source code. It should certainly be possible to bootstrap yhc and we intend to provide makefiles for doing this soon, however until that time GHC is a dependancy.

Q) Why does it fail to build on my platform?

A) On MacOS X, you need to install libgmp somewhere that scons can see it. E.g. if you have GHC, copy its libgmp.a and libgmp.la into /usr/lib, and gmp.h into /usr/include.

Q) What about programs compiled by Yhc?

A) If you use sensible libraries - i.e. don't build up filepaths by ++, then you should be fine. If you use the FFI you will need to compile the FFI bits separate for every platform you support.

Language Support

Q) Does it support Unicode?

A) Internally all characters are stored as 32 bit integers, so that bit doesn't have a problem. However, currently there is no library support to access the full unicode range. All source files are also assumed to be ASCII. Adding Unicode support is probably not very hard, volunteers welcome!

Q) What extensions does it support?

A) Very few. Existentials and pattern guards are supported. Rank-2 types, multiparameter type classes and most other extensions are not.