Killing off nhc

Neil Mitchell

15 Jun 2007 15 Jun '07

8:01 a.m.

Hi, After discussions with Malcolm, there are a number of things that need to be done before Yhc can replace nhc: 1) Performance: Yhc must perform faster than nhc, we used to, but we don't anymore. Tom is going to investigate. 2) Buildability: Malcolm still can't build on his Mac, due to library issues. Tom is going to remove all dependencies on all libraries, which should enable this. Even so, we need some work on the build system to get the libraries working for him. I think Malcom is the only person who has build system problems, so perhaps we can fix this for him. 3) Libraries: We need to move to the Haskell.org libraries. This may mean increasing our build stuff, or moving to Cabal. 4) Compatability: We need to compile more programs than nhc, this probably comes down to primitives and libraries. 5) Bootstrapping: We need to bootstrap Yhc with itself. Moving to one nhc/Yhc derivative is clearly a good thing. If anyone wants to take on any of these tasks, or has insights into how we can do this more quickly, we'd love to hear! Thanks Neil

Show replies by date

Creighton Hogg

15 Jun 15 Jun

8:16 a.m.

On 6/15/07, Neil Mitchell wrote:

...

Hi,

After discussions with Malcolm, there are a number of things that need to be done before Yhc can replace nhc:

1) Performance: Yhc must perform faster than nhc, we used to, but we don't anymore. Tom is going to investigate.

2) Buildability: Malcolm still can't build on his Mac, due to library issues. Tom is going to remove all dependencies on all libraries, which should enable this. Even so, we need some work on the build system to get the libraries working for him. I think Malcom is the only person who has build system problems, so perhaps we can fix this for him.

3) Libraries: We need to move to the Haskell.org libraries. This may mean increasing our build stuff, or moving to Cabal.

4) Compatability: We need to compile more programs than nhc, this probably comes down to primitives and libraries.

5) Bootstrapping: We need to bootstrap Yhc with itself.

Moving to one nhc/Yhc derivative is clearly a good thing. If anyone wants to take on any of these tasks, or has insights into how we can do this more quickly, we'd love to hear!

Well, what's really the problem stopping Yhc from bootstrapping itself yet? Are there spots where Yhc relies on GHC type extensions? Cheers, Creighton

Neil Mitchell

8:56 a.m.

...

...
5) Bootstrapping: We need to bootstrap Yhc with itself.

Well, what's really the problem stopping Yhc from bootstrapping itself yet? Are there spots where Yhc relies on GHC type extensions?

No, we've been very careful with avoiding extensions. We just rely on things like Data.Map, which last time we looked into bootstrapping, didn't exist in Yhc. Now they do, so its entirely possible that Yhc is now bootstrapping, but we just haven't checked. Its the last thing on the list - once we get the build system and libraries sorted I suspect bootstrapping will fall out for free. Thanks Neil

Stefan O'Rear

9:55 a.m.

On Fri, Jun 15, 2007 at 07:16:04AM -0500, Creighton Hogg wrote:

...

On 6/15/07, Neil Mitchell wrote:

...
5) Bootstrapping: We need to bootstrap Yhc with itself.

Moving to one nhc/Yhc derivative is clearly a good thing. If anyone wants to take on any of these tasks, or has insights into how we can do this more quickly, we'd love to hear!

Well, what's really the problem stopping Yhc from bootstrapping itself yet? Are there spots where Yhc relies on GHC type extensions?

Sorta kinda. Yhc uses MTL (afair), which uses undecidable instances to implement a feature Yhc doesn't use. Somebody really ought to split up MTL, but there doesn't seem to be an easy way for people without direct access to split packages... Stefan

Neil Mitchell

9:57 a.m.

...

Sorta kinda. Yhc uses MTL (afair), which uses undecidable instances to implement a feature Yhc doesn't use. Somebody really ought to split up MTL, but there doesn't seem to be an easy way for people without direct access to split packages...

Ross is doing that, there will soon be mtl-extras and mtl-base. As it stands, nhc already has mtl, just not the bits that Yhc doesn't use. I doubt mtl will give us much hassle. Thanks Neil

Stefan O'Rear

10:12 a.m.

On Fri, Jun 15, 2007 at 01:01:01PM +0100, Neil Mitchell wrote:

...

After discussions with Malcolm, there are a number of things that need to be done before Yhc can replace nhc:

1) Performance: Yhc must perform faster than nhc, we used to, but we don't anymore. Tom is going to investigate.

2) Buildability: Malcolm still can't build on his Mac, due to library issues. Tom is going to remove all dependencies on all libraries, which should enable this. Even so, we need some work on the build system to get the libraries working for him. I think Malcom is the only person who has build system problems, so perhaps we can fix this for him.

That you mention this *now* implies that Malcolm is having issues with libgmp as well as libffi, which means that (per your plan mentioned on IRC yesterday) Malcolm will get 32 bit Integers. Why didn't he have this problem with nhc?

...

3) Libraries: We need to move to the Haskell.org libraries. This may mean increasing our build stuff, or moving to Cabal.

Increasing our build stuff, maybe not; I'm a strong opponent of GHC's extralibs :) Supporting Cabal is an absolute must if we want to take over any sizable chunk of the Haskell implementation's market; for implementation I recommend http://haskell.org/pipermail/libraries/2007-May/007507.html. It might be an issue, that yhc unlike nhc cannot generate executables. We should look at what Hugs' cabal support uses. It would also be Pretty Cool if yhc proper became the first Haskell compiler buildable with cabal! :)

...

4) Compatability: We need to compile more programs than nhc, this probably comes down to primitives and libraries.

5) Bootstrapping: We need to bootstrap Yhc with itself.

...

Moving to one nhc/Yhc derivative is clearly a good thing. If anyone wants to take on any of these tasks, or has insights into how we can do this more quickly, we'd love to hear!

(words of encoragement, I'm very pleased with this development) Stefan

Neil Mitchell

10:19 a.m.

...

That you mention this *now* implies that Malcolm is having issues with libgmp as well as libffi, which means that (per your plan mentioned on IRC yesterday) Malcolm will get 32 bit Integers. Why didn't he have this problem with nhc?

Libraries, build system, makefile vs scons - its not incredibly well understood. Malcolms machine is also not able to become a buildbot (its behind a firewall) and is a 64 bit Mac (I think) - if someone could provide us with such a buildbot we'd have a better chance at diagnosing it.

...

...
3) Libraries: We need to move to the Haskell.org libraries. This may mean increasing our build stuff, or moving to Cabal.

Increasing our build stuff, maybe not; I'm a strong opponent of GHC's extralibs :)

I mean our build infrastructure, not building more libraries by default necessarily - just allowing it to be done.

...

Supporting Cabal is an absolute must if we want to take over any sizable chunk of the Haskell implementation's market; for implementation I recommend http://haskell.org/pipermail/libraries/2007-May/007507.html.

Waiting for Cabal improvements may slow things down a lot. Cabal is obviously a very nice way to go, but may require lots of hacking to Cabal - which isn't the worlds nicest code base. If someone stepped forward saying that really like hacking Cabal and wanted to use Yhc as a case study that would be great!

...

It might be an issue, that yhc unlike nhc cannot generate executables. We should look at what Hugs' cabal support uses.

I don't think so, unlikely Hugs we can generate something that's nearly an executable, and we can go closer (bytecode linking) if necessary. Thanks Neil

Stefan O'Rear

6:07 p.m.

On Fri, Jun 15, 2007 at 03:19:18PM +0100, Neil Mitchell wrote:

...

Hi

...
That you mention this *now* implies that Malcolm is having issues with libgmp as well as libffi, which means that (per your plan mentioned on IRC yesterday) Malcolm will get 32 bit Integers. Why didn't he have this problem with nhc?

Libraries, build system, makefile vs scons - its not incredibly well understood. Malcolms machine is also not able to become a buildbot (its behind a firewall) and is a 64 bit Mac (I think) - if someone could provide us with such a buildbot we'd have a better chance at diagnosing it.

Why is that an issue? I thought buildbots communicated using email.

...

...
...
3) Libraries: We need to move to the Haskell.org libraries. This may mean increasing our build stuff, or moving to Cabal.

Increasing our build stuff, maybe not; I'm a strong opponent of GHC's extralibs :)

I mean our build infrastructure, not building more libraries by default necessarily - just allowing it to be done.

Ah, ok.

...

...
Supporting Cabal is an absolute must if we want to take over any sizable chunk of the Haskell implementation's market; for implementation I recommend http://haskell.org/pipermail/libraries/2007-May/007507.html.

Waiting for Cabal improvements may slow things down a lot. Cabal is obviously a very nice way to go, but may require lots of hacking to Cabal - which isn't the worlds nicest code base. If someone stepped forward saying that really like hacking Cabal and wanted to use Yhc as a case study that would be great!

...
It might be an issue, that yhc unlike nhc cannot generate executables. We should look at what Hugs' cabal support uses.

I don't think so, unlikely Hugs we can generate something that's nearly an executable, and we can go closer (bytecode linking) if necessary.

Not sure I understand - how does runhugs Foo.hs differ from yhi Foo-linked.hbc, from an API standpoint? Stefan

6549

Age (days ago)

6549

Last active (days ago)

List overview

Download

7 comments

3 participants

participants (3)

Creighton Hogg
Neil Mitchell
Stefan O'Rear

Killing off nhc

tags

participants (3)