We have put a large list in double quotes and used "read" to convert the large literal string (too big for hugs, though) into the needed list. This reduced compile time drastically, but I don't know how the runtime changed. (Also errors can only occur at runtime.) Christian Ketil Malde wrote:

Hi,

I've recently tried to compile some data into my program, and suddenly I realize why people tend to complain about the speed of GHC.

For a benchmark, I'd like to include a bit of data in the form of a list of integer matrices (i.e. [[[Int]]]). While I have about 10000 of them, sized about twenty square, even 100 of them takes extremely long to compile. Is there a trick to make this faster?

(For short lists (1-8 matrices), time seems to scale linarly, but the 100-matrix took much longer than expected from a simple extrapolation)

Also, it takes a long time before any error is produced, it'd be nice if syntactical problems were reported as quickly as possible (perhaps they are?)

-kzm

On Thu, 27 May 2004, Ketil Malde wrote:

Christian Maeder writes:

...

We have put a large list in double quotes and used "read" to convert the large literal string (too big for hugs, though) into the needed list. This reduced compile time drastically, but I don't know how the runtime changed. (Also errors can only occur at runtime.)

Yes, that seemed to do the trick! Don't think there was much of a runtime cost, certainly less than the previous compile cost.

This is something I was playing with a little while ago. I had a large data structure that took a long time to build at runtime, so I thought I might try compiling the data in using Template Haskell. When I tried compiling it, though, GHC spun its wheels for several minutes before quitting (don't have the source code online, so I can't find the exact error message). If anyone's got an idea how to do this sort of thing in a reasonable amount of time, I'd be grateful. (My best current idea (actually Don Stewart's) is to build it using one program, then serialise it and dump it to disk. It's a bit hacky, though: it'd be much more pleasant to do it all inside TH.) Cheers, Mark -- i'm an old testament kind of guy i like my coffee black and my parole denied -- The Dismemberment Plan, Sentimental Man

In article <1085634303.3012.107.camel@JustTesting.cse.unsw.edu.au>, Manuel M T Chakravarty wrote:

On Fri, 2004-05-21 at 10:07, John Sharley wrote:

...

I note this remark on the Microsoft Research site (http://research.microsoft.com/projects/ilx/fsharp.aspx) <quote> Purely functional languages like Haskell are excellent within certain niches, but unfortunately some simple programming exercises can quickly turn into problems that require a PhD. to solve. </quote>

Are the Microsoft Research people working on GHC or anyone else on this list also of this opinion? If so, why?

This is a clear case of FUD:

http://en.wikipedia.org/wiki/FUD

I agree. It's been changed now, however: "Purely functional languages like Haskell are excellent within certain niches, but non-trivial problems exist with language interoperability between lazy and strict languages." Given your work on FFI, would you care to comment? I wonder if F# really is as obviously preferable to a "Haskell#" as they claim? -- Ashley Yakeley, Seattle WA

In article <1086095569.2461.161.camel@JustTesting.cse.unsw.edu.au>, Manuel M T Chakravarty wrote:

Generally, phrases such as "XYZ is excellent within certain niches" sounds like cheap propaganda to me. If you replace Haskell by Linux, I am sure you'll find similar statements on other Microsoft web pages ;-)

Doubtless. I think if they're casting about for excuses not to use Haskell, they're unlucky not to have hit on time/space issues. Anyway, I've rewritten it for them: "Purely functional languages like Haskell are excellent to write in, but non-trivial work is involved with implementing a lazy language in a strict run-time environment. ..." -- Ashley Yakeley, Seattle WA