|Part of Yhc|
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.
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.
Q) How portable is Yhc itself?
A) If your architecture has a C compiler that at least looks slightly ANSI C compliant, it should be a 10 minute port. In general most people have had the most trouble 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.
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.