[Haskell] ANNOUNCE: jhc 0.7.1
john at repetae.net
Tue Aug 25 21:13:11 EDT 2009
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
> 2. In older jhc versions it was possible to specify .hl libraries by
> name and version, eg jhc -p filepath-188.8.131.52. 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
* 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 Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
More information about the Haskell