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