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

Mailing list

http://haskell.org/mailman/listinfo/yhc

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 :)

Yhc JVM

http://www.brianweb.net/personal/blog/entry.php?id=18

Yhc running on a java virtual machine, way cool!

Yhc API

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!

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.

New structure in the development version

Hello,

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

./lib/yhc/packages/yhc-base/1.0

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.



Tom

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

http://www.cs.york.ac.uk/fp/darcs/yhc/

the development branch is in

http://www.cs.york.ac.uk/fp/darcs/yhc-devel/

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.


Tom

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!

Tom's Introduction

Hello,


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

Tom

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

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.