Haddock/Development ideas
From HaskellWiki
(Difference between revisions)
(document parameters of function arguments) |
(ch haste ln) |
||
| (2 intermediate revisions not shown.) | |||
| Line 5: | Line 5: | ||
* Haddock would get much better error messages. | * Haddock would get much better error messages. | ||
* Haddock could infer types for functions with no explicit type signature. | * 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 [ | + | * GHCi and IDEs like [[hIDE]] and [[Visual Haskell]] would be able to display API documentation in more convenient ways like in this [[Haste]]] screenshot: |
[[Image:Haste_screenshot_hovering.png]] | [[Image:Haste_screenshot_hovering.png]] | ||
| Line 13: | Line 13: | ||
* Haddock should emit the documentation about instances. For example, it's important to document that the Data.Map instance of Foldable only folds over the values and not the keys. | * Haddock should emit the documentation about instances. For example, it's important to document that the Data.Map instance of Foldable only folds over the values and not the keys. | ||
* There should be an annotation to include a function's entire definition in the documentation. This would be useful for functions like <hask>(.)</hask> and <hask>mapM</hask> where the definition is the clearest possible documentation, and for QuickCheck properties that specify the behavior of a library. | * There should be an annotation to include a function's entire definition in the documentation. This would be useful for functions like <hask>(.)</hask> and <hask>mapM</hask> where the definition is the clearest possible documentation, and for QuickCheck properties that specify the behavior of a library. | ||
| + | * There should be an option to include a simplified implementation of a function that is equivalent to the one in the code. For instance, instead of showing a complex implementation of List.length that makes use of stream fusion we could show a simple one based on foldl'. | ||
| + | * Optionally [http://www.haskell.org/pipermail/haskell-cafe/2008-January/038211.html show qualifications of identifiers], that is print <hask>Sequence.map</hask> rather than <hask>map</hask>, <hask>Music.T</hask> rather than just <hask>T</hask>. The option for haddock could be <code>--qualification QUAL</code> | ||
| + | ** <code>none</code> (default) strip off qualification (just <hask>map</hask>) | ||
| + | ** <code>orig</code> show the identifiers as they are written in the module (e.g. <hask>map</hask> or <hask>List.map</hask>) | ||
| + | ** <code>full</code> show all identifiers with full qualification (<hask>Data.List.map</hask>) | ||
* It should be possible to [http://www.haskell.org/pipermail/haskell-cafe/2007-August/030390.html document parameters of function arguments]. | * It should be possible to [http://www.haskell.org/pipermail/haskell-cafe/2007-August/030390.html document parameters of function arguments]. | ||
<haskell> | <haskell> | ||
| Line 20: | Line 25: | ||
-> a {- ^ global output -} | -> a {- ^ global output -} | ||
</haskell> | </haskell> | ||
| + | : This is also of interest for other type constructors like the pair type constructor <hask>(,)</hask>. | ||
Revision as of 02:24, 26 March 2008
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:
- Haddock could accept module parameters with space after "-- #" ("-- #hide" is accepted nowadays, but "-- # hide" not)
- It would be good to have a recursive flag that would operate on all the .hs and .lhs files under a single directory.
- Haddock should emit the documentation about instances. For example, it's important to document that the Data.Map instance of Foldable only folds over the values and not the keys.
- There should be an annotation to include a function's entire definition in the documentation. This would be useful for functions like and(.)where the definition is the clearest possible documentation, and for QuickCheck properties that specify the behavior of a library.mapM
- There should be an option to include a simplified implementation of a function that is equivalent to the one in the code. For instance, instead of showing a complex implementation of List.length that makes use of stream fusion we could show a simple one based on foldl'.
- Optionally show qualifications of identifiers, that is print rather thanSequence.map,maprather than justMusic.T. The option for haddock could beT
--qualification QUAL-
none(default) strip off qualification (just)map -
origshow the identifiers as they are written in the module (e.g.ormap)List.map -
fullshow all identifiers with full qualification ()Data.List.map
-
- It should be possible to document parameters of function arguments.
fix :: ( a {- ^ local argument -} -> a {- ^ local output -} ) -> a {- ^ global output -}
- This is also of interest for other type constructors like the pair type constructor .(,)

