Ticket #2776 (new bug)
Document -pgmL (Use cmd as the literate pre-processor)
| Reported by: | Syzygies | Owned by: | |
|---|---|---|---|
| Priority: | lowest | Milestone: | 7.6.2 |
| Component: | Documentation | Version: | 6.10.1 |
| Keywords: | pgmL literate | Cc: | |
| Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
| Type of failure: | Difficulty: | Unknown | |
| Test Case: | Blocked By: | ||
| Blocking: | Related Tickets: |
Description
The GHC option -pgmL (Use cmd as the literate pre-processor) is undocumented, and behaves differently than -pgmF (Use cmd as the pre-processor).
While one can count on the first three arguments to a -pgmF command giving file names, with optional arguments coming later, the last three arguments to a -pgmL command give the file names. An undocumented "-h" argument always comes before these file arguments, throwing off any command designed according to the documentation for -pgmF. Moreover, an optional argument provided using -opL comes before any of these arguments.
The undocumented "-h" reminds me of the passage in Real World Haskell, how only one reasonable program could have type "(a, b) -> a", because there isn't enough information to do anything clever. Here, GHC wants the -pgmL command to emit standard Haskell, but for all it knows, the literate program is in Swahili. GHC isn't really in a good position to be offering advice via options on this conversion, because it has no idea what conversion is taking place. So the "-h" is inexplicable.
Also, the example command in GHC manual section 5.10.4. doesn't use argument $1, and probably wants to use $1 rather than $2 for the echo, if in fact it is possible to create circumstance where $1 and $2 differ.

