how to get a new front-end - idea
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Front-end meaning parser and type-checker, from which Yhc would extract an untyped representation) Perhaps we can steal one from another compiler like Jhc? Maybe it's separate enough from the rest of the compiler that the code can be shared without too much modification; I haven't looked very closely. It seems it could be beneficial not to have too many different Haskell front-end implementations, especially for projects like us that don't seem particularly interested in that area(?). (I'm biased in favor of Jhc's because it handles recursive modules transparently in the front-end - and I don't think this is inherently connected to full program transformations; Jhc can precompile libraries after all) (Then there's always license issues: Jhc is GPL'd, what is Yhc currently?, does that matter?) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7/LvHgcxvIWYTTURAqx4AKCgCifSfSETsxH80XcmTlSIwtPgYACgjs8i vinPbpDsALA5tpazTlJrSl0= =ZVPi -----END PGP SIGNATURE-----
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
Hi Throwing away Yhc would be a bit depressing - I think we can come up with a different front end with different goals and different priorities. I think we can structure it differently, and contribute something fresh in some places. It is also important for GHC to have a competitor, just to keep Haskell "Clean" - a standard with one implementation is like a democracy without voting :) However in the meantime having some way to use GHC as a front end will be a definate benefit, therefore I propose: 1) Add a GHC <-> Yhc Core translator (me, unless someone else volunteers!) 2) Make our bytecode back end work from Yhc Core (Tom) 3) Add a -ghc-front-end flag, that skips our front end (should be quite easy) With these three changes, we're not throwing away anything, and we still have a separate compiler which does not depend on GHC, but users can (if they wish) use the GHC front end. Thanks Neil
Hi,
Throwing away Yhc would be a bit depressing - I think we can come up with a different front end with different goals and different priorities. I think we can structure it differently, and contribute something fresh in some places. It is also important for GHC to have a competitor, just to keep Haskell "Clean" - a standard with one implementation is like a democracy without voting :)
Please don't throw away YHC I think it's important to have various implementations of Haskell around. We don't want the language to become stale.
However in the meantime having some way to use GHC as a front end will be a definate benefit, therefore I propose:
1) Add a GHC <-> Yhc Core translator (me, unless someone else volunteers!)
What I would find very useful is a standard interface to all Haskell front ends. Would it not be a better idea to make the API for GHC and YHC appear the same? That way one could plug a ghc or yhc front end onto their system and it would just work with the minimum of change. I say this because porting HaRe to GHC (from programatica) proved to be an enormous job. It would have been made so much easier if both front ends at least some common structures remaining the same. Regards, Chris.
Please don't throw away YHC I think it's important to have various implementations of Haskell around. We don't want the language to become stale.
I'm not suggesting throwing away Yhc, I'm simply suggesting a change of front end. Currently Yhc uses the nhc98 front end, but this is proving to be rather unsatisfactory so I suggest moving to using GHC as the front end. This is particularly 'not killing' Yhc because Yhc is really a back-end modification, so it doesn't have a front end 'of its own'.
What I would find very useful is a standard interface to all Haskell front ends. Would it not be a better idea to make the API for GHC and YHC appear the same? That way one could plug a ghc or yhc front end onto their system and it would just work with the minimum of change. I say this because porting HaRe to GHC (from programatica) proved to be an enormous job. It would have been made so much easier if both front ends at least some common structures remaining the same.
Interchangeable front ends is a laudable goal but pretty difficult to achieve. In fact the easiest way to achieve it is for both compilers to use the GHC front-end ;-) Tom
On 08/03/07, Tom Shackell
Please don't throw away YHC I think it's important to have various implementations of Haskell around. We don't want the language to become stale.
I'm not suggesting throwing away Yhc, I'm simply suggesting a change of front end. Currently Yhc uses the nhc98 front end, but this is proving to be rather unsatisfactory so I suggest moving to using GHC as the front end.
This summer I was hoping to implement a new type checker for Yhc under SoC. Do you think this would be a bad idea?
participants (6)
-
C.M.Brown -
charles blundell -
Isaac Dupree -
Neil Mitchell -
Thomas Shackell -
Tom Shackell