[Yhc] how to get a new front-end - idea

[Thomas Shackell]

Isaac Dupree wrote:
> Perhaps we can steal one from another compiler like Jhc? 

Or how about GHC? It's got a nice compiler API, and any typing 
extensions added to GHC we get for free. Plus loads of libraries have 
been written to work with GHC.

I think as a community we should seriously consider it. I can see a lot 
of good, pragmatic, reasons for becoming a GHC backend, and not very 
many reasons against. I'll present both cases here, as I see them:

--- FOR ----------------------------------------------------------

1) Essentially the main problems with Yhc as it stands are:
	- Lack of commonly used typing extensions
	- Lack of commonly used libraries (which often use commonly used
	  typing extension).

Moving to being a GHC back-end would fix both these problems. Adding the 
necessary type extensions to the current Yhc has been looked at by 
several people and none of them has succeeded. Speaking from experience 
I can't say I'm surprised because the current Yhc front end is extremely 
difficult to modify.

2) When Haskell prime comes along Yhc is essentially stuck. At this 
point the new type extensions become in some sense mandatory. GHC has 
these extensions implemented already.

3) The design aims for nhc98 and Yhc are actually quite different and 
there isn't really an obvious reason to stick with nhc98 as the front end.

nhc98 had a design goal being a small compiler that can run on limited 
memory, but this was never really a goal for Yhc. Nor should it be 
given that cross compiling is so easy with Yhc with it's "write once run 
anywhere" bytecode format.

Yhc on the other has the design goal of high portability and flexibility 
- and here lack of libraries and type extensions really bites.

4) At this moment in time GHC is already a dependency for compiling the 
Yhc compiler. The idea of making Yhc boot-strap compiled has been thrown 
around but it hasn't happened yet and even if it did most people would 
still rather compile Yhc with GHC for the performance boost.

Plus being a GHC back-end would virtually make Yhc 'self-compiling' for 
free; after all it's still entirely possible to compile the Yhc 
interpreter without going near GHC (it's just C code).

5) GHC includes lots of nice high-level optimisations. If we took GHC 
Core and converted it to Yhc core and then did the Yhc things we'd get 
all of these for free.

6) Yhc would still be adding something useful to GHC, the idea of a 
simple portable bytecode that is easy for people to experiment and play 
with, and all the fun dynamic tricks you can do with a portable bytecode.

--- AGAINST ----------------------------------------------------------

1) "Too much work"

A reasonable objection, but at the moment vast amounts  of time and 
effort are being spent essentially just to catch up with GHC. As it 
stands I think we are losing: the GHC team is too big and we're too 
small and otherwise busy.

If we look forward towards Haskell prime this becomes even more true.

2) "We should stay a separate compiler"

Well Yhc has never really been a 'separate' compiler. I originally wrote 
Yhc as an experiment. I based it on nhc98 because of the history of York 
and nhc98, and because that was what I was looking at at the time. I 
never imagined Yhc would become as popular as it has - otherwise I would 
have probably thought about it more carefully.

Also there are a lot of Haskell compilers but in practice most people 
use GHC for serious work, and Hugs for simple things. How many Haskell 
front-ends does the world need?

Plus there is always the idea 'If you can't beat them, join them' :-)

3) "It would involve learning a lot about the internals of GHC".

A kind of sub-query to "Too much work". Really all we'd need to know is 
how to convert GHC Core to Yhc Core, and I don't imagine that's so hard.

Plus I'd need to convert the bytecode compiler from using nhc98 
PosLambda to Yhc Core. They aren't very different so again not too bad, 
plus it should really be done anyway.

4) "People have put a lot of work into Yhc, we don't want to see it lost"

This is also a reasonable objection, but most of the work on Yhc has 
gone into the back-end. Partly that's because that's the interesting bit 
of Yhc and partly because no-one understands the front-end well enough 
to go near it.

The various bytecode interpreters would remain. So would all of Neil's 
Core stuff and everything that derives from it. Andrew's work on the 
build system might be lost, but then it might not.

-------------------------------------------------------------------

As I stated at the top, I think moving to being a GHC back-end is 
something that we should seriously discuss as a community. So all 
thoughts, comments and suggestions are welcome.

Thanks


Tom