[Haskell] ANNOUNCE: jhc 0.7.1

[John Meacham]

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/