Ticket #71 (closed enhancement: fixed)

Opened 6 years ago

Last modified 10 months ago

Derive portability information from pragmas

Reported by: haddock@… Owned by:
Priority: minor Milestone:
Version: Keywords:
Cc: haddock@…

Description

It's too easy to write wrong Portability information in the Portability field of a module's haddock header. I wish that Portability information is automatically derived from a LANGUAGE or OPTIONS_GHC pragma, e.g. when no Portability field is specified. Somehow related to ticket #33.

Change History

Changed 6 years ago by anonymous

  • cc haddock@… added

Changed 6 years ago by waern

  • milestone changed from 2.5.0 to 2.6.0

It would be nice if the portability status of a module could be automatically inferred, yes. There is plan to implement something like this in Cabal. See:

http://hackage.haskell.org/trac/hackage/ticket/370

Cabal could easily pass this information via a command-line flag to Haddock. Now the question is: is it worth doing this in Haddock as well, for those cases when Cabal is not used to invoke Haddock? It might be, but we should not prioritise this issue much, IMHO.

If we'd do it, we could look directly in the DynFlags? (The GHC data type that represents compiler options) to determine exactly which extensions are used, so that we don't miss extensions turned on via the command line.

Changed 2 years ago by anonymous

  • milestone 2.6.0 deleted

Milestone 2.6.0 deleted

Changed 10 months ago by Fūzetsu

I totally missed existence of this issue and implemented it as {-# OPTIONS_HADDOCK show-extensions #-}. It shows as a separate field to Portability however. I always thought Portability was for things like OS dependencies &c.

I'll close this in the next few days if no one has anything to add.

Changed 10 months ago by Lemming

I think it is ok to call the Field "Extensions". I guess that "Portability" would also be the right field for portability between OSs.

Changed 10 months ago by Fūzetsu

  • status changed from new to closed
  • resolution set to fixed

Alright, great, I'll close this then: now Extensions is an (optional) automatically-derived field with extensions used in the module while Portability stays as-is, open for the programmer to put anything in.

Note: See TracTickets for help on using tickets.