1. Visual Studio / Haskell Simon Marlow Krasimir Angelov + others

2. Background We all use a development environment of one kind or another… Emacs Vi Notepad WinHugs …

3. Existing Haskell IDEs Some of these have some Haskell support: syntax colouring indentation (hard in Haskell!) jump to errors menu of top-level declarations jump to definition interactive compilation/evaluation display type of an identifier

4. Problems Language support tends to be unreliable, because these environments are not using a real Haskell front-end. eg. Colouring support in Emacs is really bad. Different language flavours: Haskell98+FFI, hierarchical modules, CPP, literate. Jumping to an error often misses (compilers don’t have good source loc info). No real compile support Many, many, many more things an IDE can do…

5. What we’re doing Integrating GHC with Visual Studio to make a decent Haskell IDE Specifying a programatic interface to GHC so that it can be re-used in other IDE-like contexts.

6. Background: Visual Studio Development shell, with several language plugins: VC++, VC#, VJ#, VB. Very rich feature set Lots of support for language integration Projects: multi-file applications/libraries Solutions: multiple projects Debugging Integrated documentation, context-sensitive help etc. Lots of support for automation/extension/customisation. “free” access to the integration APIs Windows only

7. Status of Haskell Plugin We have: Syntax colouring Parsing/renaming/type-checking as you type (in a separate thread) accurate indication of erroneous subexpressions beginnings of project support

8. Demo

9. Features we want (in rough order of increasing difficulty…): Bracket matching (inc. let/in) Drop-down menu of top-level decls Outlining Jump to definition (or docs for library fns) Easy access to documentation Code model (programatic access to the source code from a macro) Type tooltips Type of subexpression

10. More features we want Integrate with HaRe Project support: Multi-module support (automatically discover dependencies, build support etc.) Library-infrastructure support (import/export library infrastructure metadata gives a nice way to package & ship a project) Auto-Haddocking for a project Integrated FFI tools??.NET integration?? Debugging?? GUI Builder??

11. Implementation Visual Studio Integration Program set of COM APIs for integrating new functionality into VS: Language support in the editor Project Tools “freely available” SDK APIs are highly detailed, flexible & HUGE Babel (Daan Leijen) provides a simpler abstraction layer for integrating simple language support

12. The obligatory block diagram Visual Studio Babel VSIP COM interfaces Haskell Service C/C++Haskell Babel COM interfaces GHC Direct to VSIP for project support

13. What we’ve done so far Infrastructure: Use H/Direct for accessing COM APIs (about 15 bugs in H/Direct found so far!) Multi-threading support in GHC’s RTS (parsing & colouring run in separate OS threads) Accurate source location info in GHC’s internal abstract syntax (phew) Support in GHC to build GHC as a package Krasimir: basic project support, more to come

14. GHC as a library What interface should GHC export? Needs to support these front-ends: GHCi --make -e Visual Studio others… Tell me what you need…

15. Conclusion What features would you like to see in an IDE? What would make it compelling enough for you to use? We’ll ship GHC as a “package” soon. VS plugin will be available at some point (help needed!)

16. GHC’s API data ModuleGraph = [ModSummary] data ModSummary –- contains module name, location, imports data CmState cmInit :: GhcMode -> DynFlags -> IO CmState -- Stuff for –-make, basic GHCi operation: cmDepAnal :: CmState -> [FilePath] -> IO ModuleGraph cmLoad :: CmState -> ModuleGraph -> IO (CmState, Bool, [String]) cmUnload :: CmState -> IO CmState -- Visual Studio: -- - Project knows the ModuleGraph -- - Don’t need to fully compile modules data ErrMsg cmAnalyse :: CmState -> ModuleGraph -> Module -> IO (CmState, Either [ErrMsg] ModuleInfo) cmModuleChanged :: CmState –> Module -> IO CmState

17. -- Should we provide access to the complete abstract syntax -- (perhaps in a simplified form? THSyntax? IfaceSyn?) or just -- accessors? data SrcLoc data SrcSpan typeOfId :: SrcLoc -> ModuleInfo -> Maybe Type defnOfId :: SrcLoc -> ModuleInfo -> Maybe SrcLoc topDecls :: ModuleInfo -> [(SrcSpan, String)]