Haddock/Development ideas
From HaskellWiki
(Difference between revisions)
(Request for more operators) |
m (typo) |
||
| Line 1: | Line 1: | ||
There would be a number of benefits if [[GHC]]'s parser were extended to understand the [[Haddock]] documentation markup and then Haddock changed to use the [[GHC/As a library|GHC API]]: | There would be a number of benefits if [[GHC]]'s parser were extended to understand the [[Haddock]] documentation markup and then Haddock changed to use the [[GHC/As a library|GHC API]]: | ||
| - | * Haddock would get full | + | * Haddock would get full support for GHC's various syntactic extensions. |
* Haddock would understand <code>{#- LINE -#}</code> pragmas which would allow it to generate links to the original source code. | * Haddock would understand <code>{#- LINE -#}</code> pragmas which would allow it to generate links to the original source code. | ||
* Haddock would get much better error messages. | * Haddock would get much better error messages. | ||
Revision as of 19:31, 1 January 2007
There would be a number of benefits if GHC's parser were extended to understand the Haddock documentation markup and then Haddock changed to use the GHC API:
- Haddock would get full support for GHC's various syntactic extensions.
- Haddock would understand
{#- LINE -#}pragmas which would allow it to generate links to the original source code. - Haddock would get much better error messages.
- Haddock could infer types for functions with no explicit type signature.
- GHCi and IDEs like hIDE and Visual Haskell would be able to display API documentation in more convenient ways like in this Haste screenshot:
It would be good to have a recursive flag that would operate on all the .hs and .lhs files under a single directory.
It would be nice if haddock is able to parse more user defined operators like (#).
