On 25-Nov-1999, George Russell <[EMAIL PROTECTED]> wrote: > I think the GHC developers have got their priorities about right. Yes, GHC > is slow, hard to build, and big. That's because it's a research project. I rather expect the *research* project to compile to something like, say, lambda-like machine, this machine to be *interpreted* then. And it would be easy to intstall, to understand and develop such compiler, to port it to various systems, to develop the interactive system and dynamic modules. And the compiler will be fast and small. And of course, there in no need to generate the C code. Probably, Hugs is so. Only, to my mind, Hugs always needed more effort to put to make it more reliable, more "supported". And something to be done to increase the interpreter performance (only not C coding!). If GHC put in this direction 1/10 of effort it puts into various things, then we would have soon such a clear compiler. This is, probably, the C compiler who takes these immense resources to produce the object code. The "research" here is in symbolic program transformation, nothing to do with the C coding and various technical matters. Fergus Henderson <[EMAIL PROTECTED]> wrote on 26 Nov 1999 > Personally I think the main reason that the Clean team has managed to > achieve such a fast compiler that still generates fast code is because > they wrote their compiler in C. A compiler written in C hardly ever has right to be called a functional compiler. A functional compiler should be written in the same language it compiles - and so, to be itself an object of symbolic program manipulator hidden in this compiler. Otherwise, it may be small and fast, but it would be a small and fast nothing. ------------------ Sergey Mechveliani [EMAIL PROTECTED]
