Difference between revisions of "Haddock/Development ideas"
< Haddock
Jump to navigation
Jump to search
(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 (#).