RE: Mixture of Integer and Float arithmetic without "fromIntegral "?
| > OK, OK, I've just added -fno-monomorphism-restriction to GHC. | | Great! Will there also be a similar option for Stg Hugs? Yes. But it'll be GHCi, the interactive version of GHC, rather than STG Hugs. (GHCi is the revised Plan.) Incidentally, GHCi is just about working. It acts as a compiler with a built-in 'make' too. This is good, not because it figures out dependencies, which is easy, but because it remembers the results of one compilation for the next. This about doubles the speed of compilation for large systems. Mixed interpreted/compiled code is on the way. Simon
On Fri, Dec 08, 2000 at 12:37:59AM -0800, Simon Peyton-Jones wrote:
(GHCi is the revised Plan.)
Incidentally, GHCi is just about working. It acts as a compiler with a built-in 'make' too. This is good, not because it figures out dependencies, which is easy, but because it remembers the results of one compilation for the next. This about doubles the speed of compilation for large systems. Mixed interpreted/compiled code is on the way.
Will it be easy to add support for preprocessors? Classic Hugs has a flag -F for specifying a preprocessor for all source files, and I've hacked an option to redefine the set of source file suffixes. Then the preprocessor can be written to do different things depending on the suffix. Is this sort of thing compatible with GHCi?
Simon Peyton-Jones wrote: | Incidentally, GHCi is just about working. It acts as | a compiler with a built-in 'make' too. Great! | Mixed interpreted/compiled code is on the way. This puzzles me a bit. From talking with people at the Haskell Workshop, I understood that GHCi would only be an interactive compiler. The disadvantage with that is that compilation time might be very long. But it was said that that is the price we pay. The only advantage I can see with interpreted code is the fact that it can be compiled (or "processed") much faster. Will GHCi reach speeds up to Hugs level? One bad thing with Hugs is that, for large systems, the loading/processing time gets longer, and, worse, is repeated every time one loads the system. This is especially bad when using "runhugs". Hopefully GHCi will work better in that case! Another thing that worries me is that Hugs will die. Not only because I like Hugs a lot, but also that it is yet another Haskell system that is dying. Soon we will just have GHC and NHC left. (I have to consider HBC as dead by now, since nobody is fixing bug reports.) I know of nobody who is starting to implement a Haskell compiler from scratch. What do people think: is this a worrying situation? Regards, Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 mailto:koen@cs.chalmers.se ----------------------------------------------------- Chalmers University of Technology, Gothenburg, Sweden
Koen Claessen wrote:
Another thing that worries me is that Hugs will die. Not only because I like Hugs a lot, but also that it is yet another Haskell system that is dying. Soon we will just have GHC and NHC left. (I have to consider HBC as dead by now, since nobody is fixing bug reports.)
I know of nobody who is starting to implement a Haskell compiler from scratch. What do people think: is this a worrying situation?
Yes. But not the fact that this or that implementation of Haskell dies. Inchaa Allah, we are all mortal... It is the question of having offsprings. Gofer generated Hugs. HBC - perhaps - incited Lennart to work on exotic spices. I suspect very strongly that something is germinating. Perhaps something interesting (and faster than actual Haskell) will come up from the cross-breeding between H. and Clean? And, anyway, the success of Gofer and Hugs proves *ONCE MORE* that interpreters of a serious language (forget the interpreters of C...) are always badly needed, if only for pedagogical purposes. Jerzy Karczmarczuk
participants (4)
-
Jerzy Karczmarczuk -
Koen Claessen -
Ross Paterson -
Simon Peyton-Jones