[ANNOUNCE] yhc - York Haskell Compiler
Announcing the York Haskell Compiler - a Haskell 98 compiler with roots in nhc98. It's not totally finished, but is getting there quickly, and could well be of interest to Haskell developers. Webpage: http://www-users.cs.york.ac.uk/~ndm/yhc/ Project Blog: http://yhc06.blogspot.com/ Project Wiki: http://haskell.org/hawiki/Yhc Darcs: darcs get http://www.cs.york.ac.uk/fp/darcs/yhc As many of you now know, the York Haskell Compiler project is now getting well and truely off the ground. For those of you that don't know, I'll give you a quick summary. Over the last few months Tom Shackell has rewritten the back end of nhc98, to create the yhc compiler. The new compiler is extremely lightweight, runs fast, and generates code that runs at a speed roughly midway between hugs and ghc. Better than that though, the compiler generates bytecode to be run on a virtual machine, and thus can create portable binaries! The virtual machine is written in C and thus can bootstrap the whole compiler system on just about any platform (it's already known to work on linux, windows and OS X). Several problems that nhc had have been addressed in the rewrite including the hi-mem bug, and making it work on Windows (without cygwin). There is still a lot of work to do though - contributions welcome! Thanks Tom Davie (and the rest of the yhc team)
At Fri, 11 Nov 2005 01:11:17 +0000, Thomas Davie wrote:
Announcing the York Haskell Compiler - a Haskell 98 compiler with roots in nhc98. It's not totally finished, but is getting there quickly, and could well be of interest to Haskell developers.
Is there some trick to getting it to build ? $ make /usr/bin/make -C src/compiler98 make[1]: Entering directory `/root/projects/haskell/yhc/src/compiler98' make[1]: *** No rule to make target `LexStr.hs', needed by `../../inst/bin/yhcc'. Stop. make[1]: Leaving directory `/root/projects/haskell/yhc/src/compiler98' make: *** [compiler] Error 2 I had to make a lot of changes to the compiler98 Makefile to get it to build... ~/projects/haskell/yhc.old/src/compiler98 # darcs diff Makefile 3c3 < MergeSort.hs AssocTree.hs LexStr.hs LexLow.hs \ ---
MergeSort.hs AssocTree.hs Parse/LexStr.hs Parse/LexLow.hs \ 5,9c5,9 < Id.hs PrettyLib.hs SyntaxPos.hs ParseLex.hs \ < ParseLib.hs Parse2.hs MkSyntax.hs Syntax.hs \ < TokenId.hs LexPre.hs Lex.hs OsOnly.hs \ < SysDeps.hs HbcOnly.hs PrettySyntax.hs ParseCore.hs \ < Parse.hs Lexical.hs Error.hs Flags.hs \
Id.hs PrettyLib.hs SyntaxPos.hs Parse/ParseLex.hs \ Parse/ParseLib.hs Parse/Parse2.hs MkSyntax.hs Syntax.hs \ TokenId.hs Parse/LexPre.hs Parse/Lex.hs OsOnly.hs \ SysDeps.hs HbcOnly.hs PrettySyntax.hs Parse/ParseCore.hs \ Parse/Parse.hs Parse/Lexical.hs Error.hs Flags.hs \ 14c14 < Bind.hs Rename.hs ParseI.hs Import.hs \
Bind.hs Rename.hs Parse/ParseI.hs Import.hs \ 19,24c19,24 < TypeData.hs TypeSubst.hs TypeUtil.hs TypeEnv.hs \ < TypeUnify.hs TypeLib.hs TypeCtx.hs Extract.hs \ < Remove1_3.hs Type.hs SccModule.hs RmClasses.hs \ < DeriveLib.hs DeriveBinary.hs DeriveBounded.hs \ < DeriveIx.hs DeriveEnum.hs DeriveRead.hs DeriveShow.hs \ < DeriveOrd.hs DeriveEq.hs Derive.hs FFITrans.hs \
Type/Data.hs Type/Subst.hs Type/Util.hs Type/Env.hs \ Type/Unify.hs Type/Lib.hs Type/Ctx.hs Extract.hs \ Remove1_3.hs Type/Type.hs SccModule.hs RmClasses.hs \ Derive/Lib.hs Derive/Binary.hs Derive/Bounded.hs \ Derive/Ix.hs Derive/Enum.hs Derive/Read.hs Derive/Show.hs \ Derive/Ord.hs Derive/Eq.hs Derive/Derive.hs FFITrans.hs \ 26,28c26,28 < BCWrap.hs BCPeep.hs BCRelative.hs BCGraph.hs \ < BCFlatten.hs BCAnalysis.hs BCShow.hs BCCompile2.hs \ < BCode.hs BCWrite.hs Depend.hs StateMonad.hs
ByteCode/Wrap.hs ByteCode/Peep.hs ByteCode/Relative.hs ByteCode/Graph.hs \ ByteCode/Flatten.hs ByteCode/Analysis.hs ByteCode/Show.hs \ ByteCode/Write.hs Depend.hs StateMonad.hs 45,46c45 < <
j.
Just so that people don't get the wrong idea ... - Yhc is a working title and it's still not totally decided what it's relation to nhc98 is. It may be merged back into nhc98, it may replace nhc98 or it may end up as an entirely seperate project from it. - It's very much work in progress, indeed the source code in the darcs repository as of today is currently somewhat disfunctional as is in between changes (hence why the Makefile is broken). - It's just an experiment of mine with the backend that turns out to have sparked some interest. It seems to compile most of Haskell 98 (at least it did when it last worked ;-)) but it's in no way an industrial strength compiler yet. - It's just me and a few other students (who are or were recently at York) working part time. It's in no way an "official" release. That said people are free to have a play around and comments, suggestions or ports are all welcome. I'll try and get the code in darcs to a reasonable state ASAHP. Hope that helps settle any confusions :-) Tom Shackell On 11/11/05, Thomas Davie <tatd2@kent.ac.uk> wrote:
Announcing the York Haskell Compiler - a Haskell 98 compiler with roots in nhc98. It's not totally finished, but is getting there quickly, and could well be of interest to Haskell developers.
Webpage: http://www-users.cs.york.ac.uk/~ndm/yhc/ Project Blog: http://yhc06.blogspot.com/ Project Wiki: http://haskell.org/hawiki/Yhc Darcs: darcs get http://www.cs.york.ac.uk/fp/darcs/yhc
As many of you now know, the York Haskell Compiler project is now getting well and truely off the ground. For those of you that don't know, I'll give you a quick summary.
Over the last few months Tom Shackell has rewritten the back end of nhc98, to create the yhc compiler. The new compiler is extremely lightweight, runs fast, and generates code that runs at a speed roughly midway between hugs and ghc. Better than that though, the compiler generates bytecode to be run on a virtual machine, and thus can create portable binaries! The virtual machine is written in C and thus can bootstrap the whole compiler system on just about any platform (it's already known to work on linux, windows and OS X).
Several problems that nhc had have been addressed in the rewrite including the hi-mem bug, and making it work on Windows (without cygwin). There is still a lot of work to do though - contributions welcome!
Thanks
Tom Davie (and the rest of the yhc team)
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On Fri, Nov 11, 2005 at 12:24:49PM +0000, Neil Mitchell wrote:
- It's very much work in progress, indeed the source code in the darcs repository as of today is currently somewhat disfunctional as is in between changes (hence why the Makefile is broken).
It may be a good idea to have yhc-stable and yhc-devel repositories, where yhc-stable should be functional most of the time. That's how darcs' repos are organized. Best regards Tomasz
Yes that's a good idea, I would have tidied things up somewhat if I'd known it was going to be announced on the mailing list :-) Cheers Tom Tomasz Zielonka wrote:
On Fri, Nov 11, 2005 at 12:24:49PM +0000, Neil Mitchell wrote:
- It's very much work in progress, indeed the source code in the darcs repository as of today is currently somewhat disfunctional as is in between changes (hence why the Makefile is broken).
It may be a good idea to have yhc-stable and yhc-devel repositories, where yhc-stable should be functional most of the time. That's how darcs' repos are organized.
Best regards Tomasz _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On 11/11/05, Neil Mitchell <ndmitchell@gmail.com> wrote:
Just so that people don't get the wrong idea ...
- It's just an experiment of mine with the backend that turns out to have sparked some interest. It seems to compile most of Haskell 98 (at least it did when it last worked ;-)) but it's in no way an industrial strength compiler yet.
I'm curious. Can you be more specific about what you thought wanted/needed changing in nhc98's VM and/or compiler? I haven't played around with nhc98 yet, but I was intrigued by its small size and its (modestly-sized and simple) bytecoded implementation. Should I now be more interested in Yhc instead? ;-) I'd like to build a web-publishing framework in Haskell that is totally self-contained, very portable, and easy to bootstrap ... and nhc98 or Yhc might be a nice place to start. Are you documenting your thoughts about the Yhc implementation somewhere? Cheers, - David -- There's more than one way to do it: the Perl way, and the _right_ way.
On 11 Nov 2005, at 23:09, David Frech wrote:
On 11/11/05, Neil Mitchell <ndmitchell@gmail.com> wrote:
Just so that people don't get the wrong idea ...
- It's just an experiment of mine with the backend that turns out to have sparked some interest. It seems to compile most of Haskell 98 (at least it did when it last worked ;-)) but it's in no way an industrial strength compiler yet.
I'm curious. Can you be more specific about what you thought wanted/needed changing in nhc98's VM and/or compiler?
I haven't played around with nhc98 yet, but I was intrigued by its small size and its (modestly-sized and simple) bytecoded implementation. Should I now be more interested in Yhc instead? ;-)
I'd like to build a web-publishing framework in Haskell that is totally self-contained, very portable, and easy to bootstrap ... and nhc98 or Yhc might be a nice place to start.
Are you documenting your thoughts about the Yhc implementation somewhere?
You should find us documenting our work in the blog... yhc06.blogspot.org. Bob
Sorry, I could have done with answering a bit more there... On 11 Nov 2005, at 23:09, David Frech wrote:
I'm curious. Can you be more specific about what you thought wanted/needed changing in nhc98's VM and/or compiler? Basically, nhc98's backend had several problems, most notably not being portable to windows, and the high memory bug (which I have on reliable sources would have been pretty nasty to fix). I can't really say anything more about Tom's reasons for rewriting it, because I don't know how much he wants to be public. Suffice to say, there are more benefits to the rewrite :).
I haven't played around with nhc98 yet, but I was intrigued by its small size and its (modestly-sized and simple) bytecoded implementation. Should I now be more interested in Yhc instead? ;-) As far as the YHC team is concerned, yes... As far as the nhc team is... I'm not sure, perhaps Malcolm or Colin would be kind enough to tell us.
I'd like to build a web-publishing framework in Haskell that is totally self-contained, very portable, and easy to bootstrap ... and nhc98 or Yhc might be a nice place to start. Yhc is certainly a good place to start - it's extremely easy to bootstrap on many many platforms.
Thanks Bob
Thomas Davie wrote:
I haven't played around with nhc98 yet, but I was intrigued by its small size and its (modestly-sized and simple) bytecoded implementation. Should I now be more interested in Yhc instead? ;-)
As far as the YHC team is concerned, yes... As far as the nhc team is... I'm not sure, perhaps Malcolm or Colin would be kind enough to tell us.
I think the implied division here is an artificial one. Tom Shackell's work on a new back-end for nhc98 is a welcome development and looks very promising. It is a good idea to pursue a more portable and compact bytecode. Also, the back-end of the currently distributed nhc98 has hosted several experiments in memory management, profiling, tracing etc so stripping back to a more minimal run-time system is also attractive. However, the new back-end is still under development. It does not yet support everything that the current nhc98 back-end does. So in the short term, I'd still recommend application developers to use the standard nhc98 distribution if it runs on their computing platform. In the medium-to-long term, it makes little sense to dissipate the efforts of a small number of York Haskell people by trying to maintain two distinct compilers with a common root. When the new back-end is tried and tested, with the addition of profiling and tracing*, I hope it will become part of the nhc98 mainstream. As for the name: Malcolm has been maintaining and distributing first nhc, then nhc98, from York for several years, and by now it has a lot of York-written code in it; but we kept the name nhc by way of acknowledgement to Niklas R\"{o}jemo, the original author, who brought nhc to York when he was a post-doc here in the mid '90s. Colin R (and Malcolm W) ----------- * Part of Tom's motivation for the new back-end is a nice implementation of his Hat G-machine for tracing.
Hello Colin, Monday, November 14, 2005, 2:51:44 PM, you wrote: CR> * Part of Tom's motivation for the new back-end is a nice implementation CR> of his Hat G-machine for tracing. i'm interested whether this sort of things is possible as back-end for GHC? it will be great if current front-end for GHC which supports number of widely used extensions can be used together with new sorts of back-ends, including debugging and super-optimizing (like jhc) ones -- Best regards, Bulat mailto:bulatz@HotPOP.com
Bulat,
CR> * Part of Tom's motivation for the new back-end is a nice implementation CR> of his Hat G-machine for tracing.
i'm interested whether this sort of things is possible as back-end for GHC?
it will be great if current front-end for GHC which supports number of widely used extensions can be used together with new sorts of back-ends, including debugging and super-optimizing (like jhc) ones
I am aware of some experiments with alternative back-ends for ghc, but I don't know of any work on a ghc back-end generating portable bytecode. A few years ago some work was done towards a ghc-hugs fusion, but in the end hugs remained separate and the ghc people developed ghci. Perhaps ghc and/or hugs developers can comment further? So far as debugging back-ends for ghc are concerned, Robert Ennals and Simon PJ did a stop-and-look style debugger using speculative evaluation which perhaps is still distributed? For systems that record a complete computational trace, a modified abstract machine is an attractively efficient alternative to source-to-source transformation, but inevitably demands more cooperation from the front-end to provide the extra information needed. Colin R
David Frech wrote:
I'm curious. Can you be more specific about what you thought wanted/needed changing in nhc98's VM and/or compiler?
Well there were a number of issues: - nhc98's existing VM had a very substantial bug because it was originally designed to use the top bit of an address to store information the VM doesn't work on any system that allocates memory in the high-mem area (which is quite common now days). This was built into the runtime pretty deeply. - nhc98's bytecode worked by writing a C file that contained an array with all the bytes in it. i.e. unsigned char bytecodes[] = { ... }; This was used to get linking for free but has several disadvantages. Most of all it ensures that while the bytecode is in theory portable the binaries that nhc produces aren't. - nhc98's runtime is written in a less than obvious way. Rewriting it quite substantially reduced the size, and increased the readability of the code. - the bytecode itself could be very much simplified. The original nhc98 bytecode had instructions for directly manipulating both stack and heap. Yhc simplifies this by moving all the work to be on the stack and then having simple instructions to build heap nodes using data on the stack. This gives quite a substantial reduction in the number of instructions needed to do something. - Reducing the number of instructions, so leaving more space for specialised versions of simple instructions (e.g. a PUSH_1 instructions rather than PUSH, 1), this means almost all instructions fit in a single byte, improving performance.
I haven't played around with nhc98 yet, but I was intrigued by its small size and its (modestly-sized and simple) bytecoded implementation. Should I now be more interested in Yhc instead? ;-)
Well things are still in an early stages of development but it could certainly be worth considering :-)
I'd like to build a web-publishing framework in Haskell that is totally self-contained, very portable, and easy to bootstrap ... and nhc98 or Yhc might be a nice place to start.
That's the idea ;-)
Are you documenting your thoughts about the Yhc implementation somewhere?
There's the blog, the wiki and the webpage (all mentioned in an earlier post). We're in a period of documenting things. The implementation is not ideally documented at the moment but that's something I hope to fix soon. Thanks Tom
Am Samstag, 12. November 2005 00:09 schrieb David Frech:
[...]
I'd like to build a web-publishing framework in Haskell that is totally self-contained, very portable, and easy to bootstrap ... and nhc98 or Yhc might be a nice place to start.
Can you tell me/us more about this web-publishing framework?
[...]
Best wishes, Wolfgang
On 11/13/05, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
Am Samstag, 12. November 2005 00:09 schrieb David Frech:
[...]
I'd like to build a web-publishing framework in Haskell that is totally self-contained, very portable, and easy to bootstrap ... and nhc98 or Yhc might be a nice place to start.
Can you tell me/us more about this web-publishing framework?
At the moment, no. ;-) But only because I'm not sure what I want yet. I've been looking around for a way to do personal publishing (which basically for me means running an integrated wiki & blog), but I don't want to be limited to that. I want something small and simple, so most "web frameworks" are out of the question. (I also toyed with using DocBook XML but it seemed a bit heavy for my intended use.) I don't want to use templating, because I think it's wrong. I'd like to use Haskell because I'm new to it and want to use it for something "real world". I've also been influenced by Jon Udell's ideas - esp by his O'Reilly book _Practical Internet Groupware_ (sadly now out of print). One of his ideas is to put a small, embedded web server on everyone's desktop. All kinds of small peer-to-peer applications then become possible. So that means that my little run-anywhere bundle should include a small & simple web server. For higher-intensity applications I'm warming to FastCGI, since it's agnostic to web server choice (unlike using mod_perl or mod_python). So I'd like that too. ;-) And, unlike many wiki or blog engines I've tried, I want my tools to generate valid XHTML. I'm not willing to compromise on this. Cheers, - David
[...]
Best wishes, Wolfgang _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
-- There's more than one way to do it: the Perl way, and the _right_ way.
participants (11)
-
Bulat Ziganshin -
Colin Runciman -
David Frech -
Jeremy Shaw -
Neil Mitchell -
Thomas Davie -
Thomas Davie -
Thomas Shackell -
Tom Shackell
-
Tomasz Zielonka -
Wolfgang Jeltsch