Literate code with #

Any literate script where the hash symbol # is in the first column of a file does not compile in ghc.

For example,

> foo = 1 + 2

#

will give rise to the following error:

lexical error at character '\n'

This is rather annoying, since # is used in markup languages as a heading delimiter. The example compiles fine using hugs.

Trac metadata

Trac field	Value
Version	6.10.4
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (Parser)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import parser labels

Note that the # makes it though the unlit into the .hspp code. Then of course it's not valid Haskell.

closed

This is as intended, so that you can put CPP directives in the literate comments. e.g.

#ifdef ENBABLE_FOO

> .... foo ....

#endif

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedWon'tFix

Wouldn't it be better if these were written as

> #ifdef ENABLE_FOO

> ... foo ...

> #endif

instead?

It seems counter productive that in a literate file that there is no allowance for # at the beginning of a line, without some special meaning to ghc; since literate files should be, well, literate! If a CPP directive should be fed through into ghc, wouldn't it be better on the end of a Bird track?

In the meantime, is there a way of turning off the # as CPP directive functionality?

Replying to [ticket:3719#comment:38046 simonmar]:

This is as intended, so that you can put CPP directives in the literate comments.

Shouldn't we be running CPP before unlit?

Replying to [ticket:3719#comment:38048 duncan]:

Shouldn't we be running CPP before unlit?

It's always been done this way around, and I imagine the reason for it has been lost in the mists of time. Maybe we'd discover why if we tried to switch them around...

mentioned in issue #4836

unlit already has shebang filtering: https://github.com/ghc/ghc/blob/master/utils/unlit/unlit.c#L184

Why not give a -filter-cpp option to it, so that all lines with whitespace followed by '#' are filtered out?

Then GHC (when invoked with -XNoCPP) would just pass on -filter-cpp to unlit.

My use-case is an emacs org-mode document with embedded literate Haskell like this:

#+begin_src literate-haskell

> expr2final :: (Arith' repr, Cond repr) => Expr a -> repr a
> expr2final (Lit i) = lit' i
> expr2final (e `Plus` e') = expr2final e `plus'` expr2final e'
> expr2final (e `Cmp` e') = expr2final e `cmp` expr2final e'
> expr2final (If c e e') = if' (expr2final c) (expr2final e) (expr2final e')

#+end_src

This results in the same error

lexical error at character '+'

and is pretty annoying. Org-mode expects the '#' in the first column, so indenting does not help here.

added Pnormal label