Tuesday, November 29, 2005

Testing, Testing 1, 2, 3

I have been working on a test suite, which is now in the darcs repo under src/tester. Its a replacement for the python version - more features, including you can run only a specific test or set of tests if you choose. It also has performance recording (although thats not displayed yet), so hopefully it will be able to properly and easily benchmark yhc vs ghc vs yhcjvm and check for any performance regressions. Of course, the first priority is to get every test working, which is an ongoing test.

A report, as generated by the test suite is available at: http://www-users.cs.york.ac.uk/~ndm/yhc/report.html

Wednesday, November 23, 2005

Mailing list


Go now and subscribe! For all development and user related posts, and general discussion on Yhc. Hopefully this will let people who don't have lunch in Derwent be more involved in the decisions of Yhc :)

Tuesday, November 22, 2005



Yhc running on a java virtual machine, way cool!

Thursday, November 17, 2005


I was reading some stuff about GHC's API today - I may end up using it for my PhD. There are also a couple of other utilities I want to write - such as:

  • Type annotator, put explicit type signatures on every top level declaration
  • Minimal import calculation, to remove unneeded import statements
  • Call graph generator
  • Module dependancy graph generator
  • Tab -> Space convertor, respecting Haskell's rules
  • Haskell warnings, when you do something a bit dodgy
  • Salmon, a Haddock replacement [this is Bob's]
  • etc.
The reason I will never do any of these is it would take days to get from Haskell to an appropriate form where the stuff can be done. The actual code is probably trivial, the Haskell boilerplate parsing, type checking etc. would be horrendous. Unless there was a Yhc API :)

And hence, initial motivation for a Yhc API is born. The compiler could do with refactoring lots (and lots and lots), and working towards a publically visible API may help the internals solidify a bit. I have set up an initial wiki page here, comments welcome.

Of course, there is a Ghc API, but Ghc is a lot bigger platform. Yhc is aiming to be small, simple and straightforward - exactly the qualities I want in an API!

Tuesday, November 15, 2005

Names - I think we're getting there

I think we're getting more on the naming now. The tool names so far are:
  • yhc - York Haskell Compiler. Does exactly what it says on the tin, compiles haskell, and makes .hbc files and .hi files of the modules its given.
  • yhi - York Haskell Interpreter. Interprets hbc and har files.
  • yhe - York Haskell Evaluator. An interactive interpreter.
  • yha - York Haskell Archiver. Archives several hbc files into one har (Haskell Archive) file. In the future will prelink, or even link modules.

We were also thinking a bit about the interface to the runtime from the compiler. From both yha and yhe's points of view, we need a function that can take a binary array of byte code and load/run it. This needs some thought before I hack the runtime apart.


Documentation is good

As people start to want to play with the compiler and runtime, a good bit of documentation can go a long way. We already have a manual in the Wiki, and now we have a start to some runtime system documentation as well. I've just fixed up some Haddock documentation for some of the compiler - which required quite a few syntax fixes in the comments - its available here, unfortunately it doesn't deal with .lhs files yet (because Haddock doesn't), thats a task for the future.

People have also been hacking all over the place. Mike's been writing a GUI for the Yhci, along with cleanups and enhancements to its functionality. I've been refactoring "things" all over the place - removing all hint of CPP directives, moving towards modern modules (Data.Set, Data.Map), writing a test framework, writing a Windows makefile etc. Tom's been moving forward with the Make/Package system, working slowly towards the goal of building Yhc with Yhc.

And just so people know - I've been recompiling and modifying Yhc in a few seconds, thanks to the beauty that is WinHugs. If you are doing any major work on the compiler, I recommend using Hugs to first parse and typecheck the code, before running Ghc (and getting a cup of coffee) to test your changes.

Monday, November 14, 2005

New structure in the development version


I've made some changes to the structure of things in yhc-devel. Most notably

- yhc make mode is now fully operational.

yhc Main.hs

will chase Main.hs, find it's dependencies, compile them all in order and then compile Main.
It would seem that the .hbc files are going in the wrong place, though, which needs fixing.

- the inst directory now has a


where all the prelude .hi and .hbc files live. The compiler and runtime have been modified (albeit a little hackily in some cases) to support this new structure. This structure has the advantage that it gives yhc a sensible place to keep it's packages and 'make install' is still just 'copy the inst directory into the target'.

- cpphs is now included in the source code again and is built with the rest of the tools. It does in theory introduce a circular dependency for bootstrapping, but this can easily be solved by including a yhc compiler version in a 'bootstrap' directory.


Saturday, November 12, 2005

YHCI It is then

You'll have noted the naming war that was going on for our interactive interpreter - should it be yhii or yhci? Well, today it was decided -- I turned down Neil's offer of fisticuffs (him being rather good at karate), and instead suggested a coin toss to decide it. It came up tails, so the name is now yhci.

We also decided that when we can't think of any convincing arguments for one way or another, that this would be our new method of deciding things :)


Friday, November 11, 2005

stable and development

Since yhc seems to have appeared on the haskell mailing list I've created stable and development branches. The stable branch is the same as the old


the development branch is in


The stable branch (should) always compile and work, the same can not be said of the devel branch. I've made the current stable branch by reverting the compiler to its "pre-make" behaviour.

Hopefully that'll help people trying to use it.


Making yhc more open

You might have seen the haskell mailing list post on making Haskell more open. Yhc is a lot smaller than ghc, and a lot newer, so hopefully we can also be a bit more nimble, and more open.

We're already using darcs, so hopefully people can give us code more easily. Its also substantially easier and quicker to build yhc than ghc, so hopefully that will encourage people to contribute to us. I was going to start on some initial documentation for yhc tonight at home, since my computer is too slow to build yhc for development purposes at around 3 minutes for a build, and simple text files are quick. Then I thought that maybe our user manual should be in a wiki from the very start - and the Yhc Manual Wiki was born. Feel free to edit it as required!

Thursday, November 10, 2005

Tom's Introduction


I'm the other tom. I started yhc by rewriting the backend of the nhc98 ... mostly as an experiment. People liked the experiment so now it's a proper project.

Currently I'm doing most of the compiler and runtime work ... though I seem to increasingly be appropriating minions *buwahaha*. I am thus also the person that everyone talks about hitting when things break :-S


Introducing... Bob

For those people who don't know me in some way, I'm Bob, I'm going to be working on YHC's type checker, the linker, and probably a good chunk of yhii (York Haskell Interactive Interpreter, yes, that's right, we're in the midst of a naming battle). I'm also chief kicker when it stops working on OS X.

I did my undergrad at York with Neil and Mike, and have now pissed off to Canterbury where I'm working on Debuggers with Olaf Chitil.

Hope you enjoy the blog.


First Post

First post by me, that is - second post overall :)

Just an introduction really. I'm the single lone Windows user in the yhc team, so when it breaks on Windows I have to hit people. I'm also interested in the packaging system, and the user interface to the compiler - making it intuative and easy to use. I am currently a full time Hugs user, and rewrote WinHugs recently, so I want to make using Yhci [the interpeter, think ghci] and WxYhci [GUI round the interpeter, think WinHugs] a better experience than WinHugs.

On the more technical side of the compiler, I'm interested in parsing, and want to rewrite the parser to be more easily extendable, faster and significantly better error messages.

At a personal level, I sit next to Tom at York, did my undergrad with Bob and Mike, and eat lunch most days with Malcolm, Colin, Tom and a few others


Welcome to the York Haskell Compiler blog, here the people involved in the YHC project will post updates on how we're doing improving the compiler and related tools.