cross-package, Plan A

I think my next step should be the simpler bit: extend .haddock files to contain their docs. (After doing that, I might have a better guess where best to thread in the type-signatures.)

Which means,

#1. That we need to write the info to .haddock files
#2. that we can parse it.
#3. that InstalledInterface can hold it
#4. find out if there’s anything we need to do to make use of the new info in InstalledInterface… well obviously there is :-)

A test case would be a package, that imports and re-exports anything that has a doc-string.  I could probably download haskell98 from hackage and use it as a test case.

This is out of order I’m sure: at least writing the info probably means we have to change InstalledInterface first, for example.  That’s what plans are for: trying them and refactoring them when they fail!

P.S. I’m doing an awful job at synchronizing my sleep cycle with SimonMar’s… it’s 2 a.m. U.S. East Coast time here, time for me to go to bed (or past time rather :-)

About these ads

2 Responses to “cross-package, Plan A”

  1. David Waern Says:

    The doc strings are already in the .haddock files. The relevant field is instDocMap in InstalledInterface.

  2. David Waern Says:

    I’m not completely right. We have the docs for everything in the .haddock file except the docs inside types. That is, we lack the docs for function arguments. We can solve this either by storing them in the .haddock file using an indexing scheme or by adding the comments to the types in GHC’s TyThings.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: