Re: [ANNOUNCE] yhc - York Haskell Compiler

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Jeremy Shaw
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.
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Neil Mitchell
> Is there some trick to getting it to build ?

I've never used the Makefile, but it should work as is!

One way to build it, the way I use is:
$ cd /root/projects/haskell/yhc/src/compiler98
$ ghc --make -cpp Main -o yhc

Thanks

Neil
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Neil Mitchell
In reply to this post by Jeremy Shaw
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 <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell
>
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Tomasz Zielonka
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Thomas Shackell
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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell

_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

David Frech
In reply to this post by Neil Mitchell
On 11/11/05, Neil Mitchell <[hidden email]> 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.
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Thomas Davie

On 11 Nov 2005, at 23:09, David Frech wrote:

> On 11/11/05, Neil Mitchell <[hidden email]> 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

_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Thomas Davie
In reply to this post by David Frech
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

_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Thomas Shackell
In reply to this post by David Frech
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
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Wolfgang Jeltsch
In reply to this post by David Frech
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
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Colin Runciman
In reply to this post by Thomas Davie
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.

_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re[2]: [ANNOUNCE] yhc - York Haskell Compiler

Bulat Ziganshin
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:[hidden email]



_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Colin Runciman
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

_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

David Frech
In reply to this post by Wolfgang Jeltsch
On 11/13/05, Wolfgang Jeltsch <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell
>


--
There's more than one way to do it: the Perl way, and the _right_ way.
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] yhc - York Haskell Compiler

Simon Peyton Jones
In reply to this post by Jeremy Shaw
| 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?

GHCi does indeed generate byte code, but we have never gotten around to
trying to dump it into files and reload it.  That might be an
interesting project -- but it only gives a constant performance factor
over loading the source files in the first place, so it's not clear that
it's a major win.

GHC is available now as a Haskell library (just say "import GHC").  The
idea is to make it possible for people to import GHC, use it to parse
and typecheck the program, and then process the result in whatever way
they want.  The interface is still evolving, but that evolution will be
strongly guided by what people want. It's in the HEAD only at the
moment, not any released compiler, but I do encourage interested parties
to give it a whirl.

| 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?

It's still available in Rob's CVS branch, but definitely not supported.
The entire speculative evaluation thing was tremendously interesting and
provocative, but it was just a bit too complicated to fold into the main
GHC head.

As Simon mentioned, though, another thing we'd like to see done is to
modify GHCi so that it always does cost-centre profiling.  That way,
every thunk would record who built it, and that would give quite a
powerful jumping off point for building a quick-and-dirty debugger.
There'd be a perf cost, but the effect would be muffled by the fact that
GHCi is an interpreter anyway.  Anyone?

Simon

_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] yhc - York Haskell Compiler

Lennart Augustsson
Simon Peyton-Jones wrote:

> | 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?
>
> GHCi does indeed generate byte code, but we have never gotten around to
> trying to dump it into files and reload it.  That might be an
> interesting project -- but it only gives a constant performance factor
> over loading the source files in the first place, so it's not clear that
> it's a major win.

The major win with having the byte code in a file is that you could
have a stand alone byte code interpreter (and runtime system).
That would make bootstrapping GHC a much less daunting task.

        -- Lennart

_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell
Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] yhc - York Haskell Compiler

Simon Marlow
In reply to this post by Jeremy Shaw
On 15 November 2005 10:37, Lennart Augustsson wrote:

> Simon Peyton-Jones wrote:
>>> 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?
>>
>> GHCi does indeed generate byte code, but we have never gotten around
>> to trying to dump it into files and reload it.  That might be an
>> interesting project -- but it only gives a constant performance
>> factor over loading the source files in the first place, so it's not
>> clear that it's a major win.
>
> The major win with having the byte code in a file is that you could
> have a stand alone byte code interpreter (and runtime system).
> That would make bootstrapping GHC a much less daunting task.

This would be nice, but for a couple of reasons it isn't entirely
straightforward to do.

  - our byte code doesn't include primitives, because we rely on
    the base package always being compiled.  If we were to interpret
    the base package, then we have to implement 200+ primitives in the
    byte code.  Maybe we could cleverly map them to FFI calls and
    auto-generate the C implementations, or something.

  - to get portable byte code, the original Haskell code has to be
    platform-independent.  Lots of Haskell code in GHC and the base
    package has #ifdefs.  There was a thread a few months back on
    glasgow-haskell-users in which we counted the #ifdefs with a view
    to improving portability, you might want to look it up.  The upshot
    was that the vast majority of #ifdefs were Windows-vs-Unix, so
    restricting portability to just Unix would be much easier than
    complete platform-independence.

Cheers,
        Simon
_______________________________________________
Haskell mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell