[jhc] what to work on next?

[John Meacham]

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/