ANNOUNCE: jhc 0.7.1
Hi, I am happy to announce the jhc optimizing haskell compiler version 0.7.1. Information on installing jhc is here: http://repetae.net/computer/jhc/building.shtml And the Main page is here: http://repetae.net/computer/jhc There have been a lot of changes since the last public release, Some notable ones are: * The use of a general compiler cache by default rather than object files. This means work done by jhc is shared between projects, jhc uses cryptographic hashes internally to never compile the same piece of code more than once. This has numerous benefits, a notable one being speed. * Reworked library support. Jhc libraries are now much more general, when linking only the bits needed are loaded from the hl file, libraries are allowed to re-export modules from other libraries, making versioning or providing multiple interfaces to the same functionality a lot simpler. Library conflicts are 'lazy', like ambiguity errors now. * Updated Manual, clearer build instructions * Support for writing pure C libraries in Haskell. * numerous library updates, filled out many IO routines that were stubs before * Smart progress meters when compiler for a better user experience * performs all typechecking before compilation, for a faster edit-compile loop when writing code with jhc. * various bug fixes * Cross Compilation improvements, for instance you can compile for windows transparently on a linux box. Or for an embedded target that is independent of the host. * Better Mac OSX Support, as both a host and target. If you are wondering about the large version number bump since the last release, It is because several versions were released only internally to the jhc list for testing. If you are interested in jhc, join the list at: http://www.haskell.org/mailman/listinfo/jhc John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Hi John,
On Mon, Aug 24, 2009 at 11:13 PM, John Meacham
Hi, I am happy to announce the jhc optimizing haskell compiler version 0.7.1.
Information on installing jhc is here: http://repetae.net/computer/jhc/building.shtml And the Main page is here: http://repetae.net/computer/jhc
Cheers! Thanks for the great work. It took me 5 minutes between downloading the tarball and compiling "hello world", and this is my first time. There should be no excuses for not giving jhc a whirl. : ) Paulo
There should be no excuses for not giving jhc a whirl.
Agreed. In a lot of ways, jhc seems like a Haskell compiler done right. It generates very fast and lean binaries - using C as an intermediary language - which makes it a natural cross-compiler and indicates it should not be too difficult to write a back-end for the CIL and the jvm. On the other hand, it is still far away from GHC features-wise. So there is definitively room for people looking to contribute to a compiler with a high potential. Wouldn't that be fun? Sylvain.
WOW! Congratulations, I am impressed: I ran it on a small example
program and jhc produced output that was 3x faster than ghc -O2!
Serious stuff.
However: I tried it on a different very simple program (a projecteuler one):
module Main where
isReversible n | n`mod`10 == 0 = False
| otherwise = all (`elem` "1357") . show $ (n +
(read.reverse.show$n))
main = putStrLn . show . length . filter isReversible $ [1..1000000::Int]
ghc took 6s on this one, whereas jhc took 2 minutes real time (of
which 5s user time and 5s system time), which also froze the system
completely! Most probably it allocated a ton of memory, because the
system was very slow for a while after the program completed.
Same thing happened with a different but bigger number-crunching program.
Also: I tried to build a program that uses uvector, and for that I
needed an uvector.hl file: I unarchived the package and did this:
jkff@jkff-laptop:~/.cabal/packages/hackage.haskell.org/uvector/0.1.0.4/uvector-0.1.0.4$
jhc --build-hl uvector.cabal
jhc --build-hl uvector.cabal
jhc 0.7.1 (0.7.0-13)
Creating library from description file: "uvector.cabal"
Reading: "uvector.cabal"
Finding Dependencies...
Using Ho Cache: '/home/jkff/.jhc/cache'
Typechecking...
Compiling...
Writing Library: uvector-0.1.0.4.hl
jkff@jkff-laptop:~/.cabal/packages/hackage.haskell.org/uvector/0.1.0.4/uvector-0.1.0.4$
ls -l uvector-0.1.0.4.hl
-rw-r--r-- 1 jkff jkff 1248 2009-08-25 10:58 uvector-0.1.0.4.hl
(is it correct that actually no compilation occured at all?)
jkff@jkff-laptop:~/projects/for-fun/haskell/mandelbrot$ jhc -p
/home/jkff/.cabal/packages/hackage.haskell.org/uvector/0.1.0.4/uvector-0.1.0.4/uvector-0.1.0.4.hl
Low.hs
jhc -p /home/jkff/.cabal/packages/hackage.haskell.org/uvector/0.1.0.4/uvector-0.1.0.4/uvector-0.1.0.4.hl
Low.hs
jhc 0.7.1 (0.7.0-13)
Finding Dependencies...
Using Ho Cache: '/home/jkff/.jhc/cache'
Library was not found
'/home/jkff/.cabal/packages/hackage.haskell.org/uvector/0.1.0.4/uvector-0.1.0.4/uvector-0.1.0.4.hl'
Now this seems strange.
The documentation to jhc was not of much help. What should be done to
use libraries from hackage?
Would it be hard to give jhc some integration with ghc's package.conf?
2009/8/25 John Meacham
Hi, I am happy to announce the jhc optimizing haskell compiler version 0.7.1.
Information on installing jhc is here: http://repetae.net/computer/jhc/building.shtml And the Main page is here: http://repetae.net/computer/jhc
There have been a lot of changes since the last public release, Some notable ones are:
* The use of a general compiler cache by default rather than object files. This means work done by jhc is shared between projects, jhc uses cryptographic hashes internally to never compile the same piece of code more than once. This has numerous benefits, a notable one being speed. * Reworked library support. Jhc libraries are now much more general, when linking only the bits needed are loaded from the hl file, libraries are allowed to re-export modules from other libraries, making versioning or providing multiple interfaces to the same functionality a lot simpler. Library conflicts are 'lazy', like ambiguity errors now. * Updated Manual, clearer build instructions * Support for writing pure C libraries in Haskell. * numerous library updates, filled out many IO routines that were stubs before * Smart progress meters when compiler for a better user experience * performs all typechecking before compilation, for a faster edit-compile loop when writing code with jhc. * various bug fixes * Cross Compilation improvements, for instance you can compile for windows transparently on a linux box. Or for an embedded target that is independent of the host. * Better Mac OSX Support, as both a host and target.
If you are wondering about the large version number bump since the last release, It is because several versions were released only internally to the jhc list for testing. If you are interested in jhc, join the list at: http://www.haskell.org/mailman/listinfo/jhc
John
-- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Eugene Kirpichov Web IR developer, market.yandex.ru
On Mon, 2009-08-24 at 21:13 -0700, John Meacham wrote:
Hi, I am happy to announce the jhc optimizing haskell compiler version 0.7.1.
Congratulations on getting a public release out. A few comments: 1. Would it be possible to have a machine-readable form of: jhc --list-libraries It's possible to parse the output of course but the worry is always that the format will change again. 2. In older jhc versions it was possible to specify .hl libraries by name and version, eg jhc -p filepath-1.0.1.1. In the latest release it is only possible by name. Is this intentional? I know jhc uses hashes to uniquely identify installed packages, perhaps it should be possible to specify packages by hash for the case that one has several instances of the same package (possibly different versions, or built against different versions of various dependencies). 3. Related to 1 and 2, what does the jhc --list-libraries output look like when there are several packages of the same version but with a different hash? Maybe a machine readable --list-libraries should list the hash too. 4. Is there a way to get back the library/package description that jhc bakes into the .hl files? There's a --show-ho. Perhaps we want a --show-hl that dumps the library description? I guess that should also tell us the package hash. 5. The ./configure doesn't check for the Haskell readline package. Duncan
On Tue, Aug 25, 2009 at 02:15:14PM +0100, Duncan Coutts wrote:
1. Would it be possible to have a machine-readable form of: jhc --list-libraries
It's possible to parse the output of course but the worry is always that the format will change again.
Good Idea, I'll modify the output to be a proper YAML file with a few guarenteed fields, that will leave room for expansion later and backwards compatability.
2. In older jhc versions it was possible to specify .hl libraries by name and version, eg jhc -p filepath-1.0.1.1. In the latest release it is only possible by name. Is this intentional? I know jhc uses hashes to uniquely identify installed packages, perhaps it should be possible to specify packages by hash for the case that one has several instances of the same package (possibly different versions, or built against different versions of various dependencies).
Ah, this is an unintentional regression. I intended to keep the behavior of being able to specify a library name/version or file name. Being able to specify a hash is also a good idea.
like when there are several packages of the same version but with a different hash? Maybe a machine readable --list-libraries should list the hash too.
4. Is there a way to get back the library/package description that jhc bakes into the .hl files? There's a --show-ho. Perhaps we want a --show-hl that dumps the library description? I guess that should also tell us the package hash.
--show-ho will also work on hl files, which probably isn't mentioned anywhere in the manual. I think I will add a verbose mode to --list-libraries that will also spit out much of this meta-info (in the aforementioned YAML format)
5. The ./configure doesn't check for the Haskell readline package.
Yeah, I am currently only checking for the purpose of ghc 6.8/6.10 compatibility, but adding checks for all dependencies is a good idea. As an aside, here are the principles that guided the design of the new library system and ho cache. The main motivations were ameliorating two notable shortcomings of jhc, its speed and compatibility with other compilers: * Ho files will only affect speed of compilation, never results. No matter what. This allows the shared ho cache and decoupling the unit of caching from module granularity. * Only the interface of libraries explicitly mentioned on the command line shall affect code compiled by jhc. For instance, a libraries implementation can use an alternate prelude without hurting its compatibility with haskell 98 code. * From the users perspective, a library defines an interface, which is not necessarily coupled to the implementation. I have thought long and hard on the problem of being able to maintain some level of compatibility with ghc and hackage without sacrificing jhc's ability to innovate, or tying its development to the ghc libraries. Making libraries logical 'interfaces' rather than 'implementations' decouples compatibility issues from the compiler itself, anyone can write a library that emulates a particular interface. For instance, a compat-ghc-base3 library might have things like 'Reexport: Compat.Haskell98.Prelude as Prelude, Compat.Ghc.Base3.Monad as Control.Monad, ... '. Or more interestingly, you might create your own library that does a 'Reexport: MyApplicativePrelude as Prelude' to get your own prelude. (this is not fully realized yet in 0.7.1, but will be in a point release soon. The mechanism and framework is there though.) * Stateless. There is no such thing as hidden libraries, libraries mentioned on the command line are available, libraries not mentioned are not. Since libraries can re-export modules this won't cause a command line explosion. For instance, a -phaskell-platform could pull in and make available all the libraries in the haskell platform. * Adding libraries, even incompatible ones, won't break working builds unless said libraries are explicitly mentioned by the build in a non-precise way. This is necessary so a theoretical 'jhc-pkg' tool need only worry about adding required libraries, not cleaning up or worrying about finding consistent sets of libraries. A simple recursive download on dependencies suffices as a rudimentary cabal-install style tool. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
participants (5)
-
Duncan Coutts -
Eugene Kirpichov -
John Meacham -
Paulo Tanimoto -
sylvain