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

jutaro jnf at arcor.de
Thu Apr 2 08:27:10 EDT 2009


Hi Simon,
you quite nicely describe what leksah is doing already. Try to find find the
source code for all installed packages by locating cabal files, parse the
module sources via the Ghc API (actually not so much the API), using info
from cabal files for this (which is a dark art). It extracts comments and
locations. It's quite an ad hoc solution. On my machine it's 97% successful,
but its a notorious support theme, because it depends so much on the
environment. 
Jürgen


Simon Marlow-7 wrote:
> 
> 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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 

-- 
View this message in context: http://www.nabble.com/Announcement%3A-Beta-of-Leksah-IDE-available-tp22816032p22846713.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.



More information about the Haskell-Cafe mailing list