[jhc] what to work on next?
ml at isaac.cedarswampstudios.org
Thu Jun 25 01:00:51 EDT 2009
John Meacham wrote:
> 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 :)
yeah I know, me too :-) i'm explaining my "cooperative" perspective on
it I guess :)
>> 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.
and it will naturally be incremental improvement like that. I mean,
this is objective progress after all, it's worth listing in release
notes (and online docs or wherever)
>> - Which extensions are implemented.
> It supports quite a few extensions, but they don't always exactly line
> up with GHC.
not responding to this in particular, but, in general;
I think a lot of the Haskell community (including me I guess) will be
coming from somewhat of a GHC perspective. And most of the available
libraries will too (e.g. extensions required by Hackage packages are
sometimes excessive). Do treasure your differences, don't just throw
them away wantonly, but don't underestimate the value of working
together! You've made a wonderful tool that is a compiler, but just
think all the horrors of Unicode and threading and Windows and who knows
what bugs GHC and its base libraries have been dealing with in the past
years! (I mean I've tried things like maintaining unicode code, but I'm
only one person and I have a lot of interests! It's usually just better
in the end to increase code sharing, therefore bug-reports and patches
and all those good things.). so... I think where possible it'd be good
to try and share a code-base for libraries, and put effort into
improving that. (okay I admit it's frustrating too, since GHC momentum
will make it harder to start getting involved hacking. But things are
IMHO less bad than the ghc-6.4 days when I entered haskell) Anyway also
for the extensions that do line up JHC-GHC, at least you can try and
give them the same names/understanding, which it looks like you're doing.
> 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
> first class existentials (exists a . a) is a valid type as well.
interesting. GHC has had such a hard time finding a *good* scheme for
impredicative type inference, and there have been lots of papers written
(so I hear) on the subject. Is JHC's current scheme described
somewhere? (including limitations. Which mostly means "which type
signatures you need to specify", IIRC).
> unboxed values. working with unboxed values is almost as
> straightforward and elegant as working with boxed values.
a possible pitfall of making them more usable, is it may become less
obvious where they're evaluated (since the point of unboxed values, was
to make sure not to rely on the optimizer, I think?)
> "strict" boxed values. values of kind !. they are boxed, but guarenteed
> evaluated. They are fully polymorphic unlike unboxed values.
yay! I want this in ghc :-P
> 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.
yeah, that'll happen slowly now and then. Documenting individual
extensions is a good thing, even when not part of finishing haskell'. I
suspect haskell' won't exist until a non-GHC compiler looks likely to
ever support it though!
> 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.
GHC/cabal folks seem to be moving towards a more portable model. e.g.,
separate "ghc-base" from "base" (which for GHC would depend on
"ghc-base") so that Jhc could export an equivalent base (and maybe there
the code divergence would be small enough that "base" itself could just
use ifdefs, since most code would be in "jhc-base" or portable packages).
More importantly IMHO, they *want* to be interoperable and if you try to
cooperate with them, they'll be more than happy to have a non-GHC
compiler with which to fix their bad assumptions!
> All in all, cabal has a closed-world assumption which isn't true. It
> assumes all haskell code is on hackage
to some extent yes, the "hackage" centralisation seems like a bad thing,
but it's also a great boon! (Any opinions on perl's CPAN and the like?)
> 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.
The overhead isn't that great, and it makes you document each language
extension at least a bit, so that other compilers might at least have a
*chance* of implementing the same thing...
> 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.
that's true (but also think how many convenient features cabal is
getting). I suspect the path through cabal to be the reasonable long
term answer, as you'll then get smart people (e.g. libraries at haskell.org
!) asking tough questions about what their tools need to do!
More information about the jhc