On Sep 28, 2009, at 12:21 , Duncan Coutts wrote:

On Sun, 2009-09-27 at 21:06 +0100, John Millikin wrote:

...

According to <http://www.haskell.org/haskellwiki/ Literate_programming>, the following should compile properly because the second block of code will be ignored by GHC:

\begin{code} main = putStrLn "Hello world!" \end{code}

\begin{code}% main = -- TODO \end{code}%

It looks to me like the advice on that wiki page is incorrect.

The Haskell98 report states:

An alternative style of literate programming is particularly suitable for use with the LaTeX text processing system. In this convention, only those parts of the literate program that are entirely enclosed between \begin{code}...\end{code} delimiters are treated as program text; all other lines are comment. More precisely:

* Program code begins on the first line following a line that begins \begin{code}. * Program code ends just before a subsequent line that begins \end{code} (ignoring string literals, of course).

The key phrases is "a line that begins \begin{code}". In other words, a line "\begin{code}%" does indeed begin a code block.

Isn't the better solution to this something like \let\uncode\code \let\enduncode\endcode then use \begin{uncode} .. \end{uncode} ? (depends on how the code environment is defined) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Mon, 2009-09-28 at 12:53 -0700, John Millikin wrote:

In that case, I'll update my code and the wiki to use an alternative code style.

Ok.

On Mon, Sep 28, 2009 at 09:21, Duncan Coutts wrote:

...

Your local Cabal version is older than the one Hackage is using and that older version lets haddock (ie ghc) do the pre-processing where as in the current version Cabal does the unlitting before running haddock. That explains the difference you observe.

Since Hackage is using an unstable development build of Cabal, I'd like to force it to use a released version to prevent such an issue from occurring again. I've added the following line to my .cabal file:

cabal-version: >= 1.6 && < 1.7

However, when testing with Cabal 1.7.3 (which is the version used by Hackage), I am warned that:

------------- Warning: dbus-core.cabal: This package requires Cabal version: >=1.6 && <1.7 Distribution quality errors: This package requires Cabal version: >=1.6 && <1.7 Note: the public hackage server would reject this package. -------------

Does this mean that it's impossible to require an earlier version of Cabal in Hackage-published packages? If so, the use of a development version of Cabal in the auto-build system seems unwise.

There's two separate issues. One is whether the package is readable by the later Cabal versions and the other is if it can be built. The hackage server itself must be able to handle the .cabal file. If that .cabal file declares that it cannot be used with a later Cabal version then we cannot do that, and we cannot accept that package on hackage. We need to be able to use later versions of Cabal on hackage than are in general use so that we can add new QA checks etc. The auto-builder is a separate matter. It's widely acknowledged that using a single builder is not a good idea. The new server will allow there to be many build clients and they can run a variety of versions of Cabal. What we really want is to version the package spec separately from the default build system. Upper bounds on the package spec make no sense where as upper bounds on the build system version make some sense sometimes. Duncan