[Haskell-cafe] Re: Announcement: Beta of Leksah IDE available

[Simon Marlow]

David Waern wrote:
> 2009/4/2 Duncan Coutts <duncan.coutts at worc.ox.ac.uk>:
>> On Wed, 2009-04-01 at 22:13 +0200, David Waern wrote:
>>> 2009/4/1 jutaro <jnf at arcor.de>:
>>>> I guess you mean the dialog which should help leksah to find sources
>>>> for installed packages. It needs this so you can go to all the definitions
>>>> in the base packages ... This is very handy if it works. Look to the manual
>>>> for details.
>>> Maybe could add support to Cabal for installing sources? Should be
>>> very useful to have in general.
>> http://hackage.haskell.org/trac/hackage/ticket/364
> 
> Jutaru, perhaps a nice Hackathon project? :-)

I think there's some design work to do there.  See the discussion on the 
GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/2630.

In short: just keeping the source code around isn't enough.  You need some 
metadata in order to make sense of the source code - for example, you can't 
feed the source code to the GHC API without knowing which additional flags 
need to be passed, and those come from the .cabal file.  Also you probably 
want to stash the results of the 'cabal configure' step so that you can get 
a view of the source code that is consistent with the version(s?) you 
compiled.  We need to think about about backwards and 
forwards-compatibility of whatever metadata format is used.

And then you'll need Cabal APIs to extract the metadata.  So we need to 
think about what APIs make sense, and the best way to do that is to think 
about what tool(s) you want to write and use that to drive the API design.

Perhaps all this is going a bit too far.  Maybe we want to just stash the 
source code and accept that there are some things that you just can't do 
with it.  However, I imagine that pretty soon people will want to feed the 
source code into the GHC API, and at that point we have to tackle the build 
metadata issues.

Cheers,
	Simon