On Wed, Jun 24, 2009 at 10:10:53AM -0400, Isaac Dupree wrote:
Evangelism (the honest sort), so that you have some users.
I am not so good at Evangelism, it makes me feel a little dirty :)
In your release announcement I would like to hear - that there are finally enough bugs fixed that JHC is usable. - that it's as easy to use as GHC for normal coding [can you make a Haskell-Platform-with-JHC to install?] getting a lot closer, the fact that containers,applicative,filepath and others compile without a hitch implies to me that it is getting quite usable as far as outstanding bugs go.
- Which extensions are implemented.
It supports quite a few extensions, but they don't always exactly line up with GHC. some are CPP, UnboxedTuples, EmptyDataDecls, TypeSynonymInstances, Arbitrary Rank N Types, RULES pragmas some more interesting ones in various stages of completion are: fully impredicative type system, [forall a . a] is a valid type for instance. first class existentials (exists a . a) is a valid type as well. unboxed values. working with unboxed values is almost as straightforward and elegant as working with boxed values. "strict" boxed values. values of kind !. they are boxed, but guarenteed evaluated. They are fully polymorphic unlike unboxed values. user defined kinds. top level IO actions Now, an issue is that even when jhc implements the same extension as ghc, it may not be exactly the same. as in, jhc's type system is different than ghcs. they both as rank-n types, but since there is no formal description of the ghc type system as it isn't in a language standard, I am sure there are programs ghc accepts and jhc doesn't and vice versa. In practice, these cases are probably rare but until haskell' is formalized they will be an issue.
If you get on the haskell-iphone list, you'll have more concentrated interest of people because the existing/past GHC overhead [and poorness at cross-compiling] matters more there. But make sure all of Haskell knows what's going on!
P.S. for my purposes, the Haskell Platform (including cabal-install) would be most important: its release made it 10x easier for me to get a working release of GHC! Then the only barrier might be if I needed some extension that Jhc didn't provide.
Unfortunately, the way cabal is designed makes it very difficult to use for compilers that don't share a codebase with ghc. The main issue is that when cabal files refer to something like 'base', they don't mean something compatible with base, they mean the precise 'base' that is on hackage. Furthurmore, cabal files refer to many ghc specifics, like 'split-base'. This is clearly an issue for something like jhc, which has its own base (that will likely be split up between several libraries, and perhaps not even called 'base'). We can have every package on cabal add explicit support for jhc, but those dependency lists are already getting complicated just to support a couple different versions of ghc. imagine 15 years down the road, with a half dozen new ghc versions, 3 uhc versions, 5 lhc ones and a dozen jhc releases that all need to be taken into account in every cabal file. Not scalable at all. Also, I couldn't bring myself to ask everyone to add explicit jhc support, it is just putting a band-aid on the problem and I don't like to do band-aids. All in all, cabal has a closed-world assumption which isn't true. It assumes all haskell code is on hackage and we can enumerate all compilers and language extensions in cabal itself. This makes haskell development more insular, rather than standardizing new versions of the language, people are dissuaded from using alternate versions by the design of the tools. Now, there are a couple paths... - wait for Haskell', let cabal packages depend on 'haskell'' rather than a specific implementation of it. Hope Haskell' is expansive enough for this to work out. - Lie to cabal, hack cabal's jhc support to pretend jhc has packages it doesn't and hope for the best. - Merge base with ghc base. No good at all. jhc has wildly different primitive concepts than ghc, files would be giant #if statements and I'd somehow have to coordinate releases and code repositories with ghc libraries. Also, it does not solve the issue, it just kludges around it. The inherent non-scalability is still there. - Use a better packaging system like 'franchise' that can understand cabal files and handle their dependencies cleanly. not great, but probably doable. implement a franchise-install. Now, all isn't that dire. jhc actually can do something much nicer than cabal-install due to the way its libraries work. jhc libraries are identified by a unique hash generated from their external interface, this means you don't actually have to worry about all the versioning issues that cabal handles or proscribe a specific version number format, if the hashes match, the libraries are compatible, if they don't, the libraries arn't. Multiple libraries implementing the same thing can coexist peacefully. A jhc-pkg install need only find the hash that matches a given name, download said file, and recursively look up each of its dependencies and download them. No compilation is necessary as the only thing needed to do to install an hl file is drop it in a directory. Think of something like arch-linuxes 'pacman' installer, very simple and it works. The only issue here is bootstrapping the hl files in the first place, the good news is that since hl files are portable, We are no longer constrained by cabal's least common denominator build system. You can use whatever the best tools for the job are and as long as you can produce an hl file, you can distribute it for all architectures. So, a combination of franchise and jhc-pkg could work together quite well. So, the short answer is, cabal is tricky. But jhc can do something like 'cabal install' but much better and that is mainly what people want out of it. Making transparent use of cabal packages on hackage is an open problem but 'franchise' gives us the start of a solution.
also I wonder, what is JHC's stance on monomorphism? (e.g. MonomorphismRestriction, MonoPatBinds, etc.)
No particular stance. It lets you turn on or off the monomorphism restriction with -fno-monomorphism-restriction. It doesn't seem to make too much different in the compiled code as the jhc optimizer is good at specialization, so I guess that is a data point in favor of dropping the monomorphism restriction. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/