Visual Studio Haskell Simon Marlow Krasimir Angelov others

Visual Studio / Haskell Simon Marlow Krasimir Angelov + others

Background n We all use a development environment of one kind or another… n n n Emacs Vi Notepad Win. Hugs …

Existing Haskell IDEs n Some of these have some Haskell support: n n n n 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

Problems n n n 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: Haskell 98+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 more things an IDE can do…

What we’re doing n n 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.

Background: Visual Studio n n Development shell, with several language plugins: VC++, VC#, VJ#, VB. Very rich feature set n n n n 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

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

Demo

Features we want n (in rough order of increasing difficulty…): n n n n 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

More features we want n n Integrate with Ha. Re Project support: n n n n 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? ?

Implementation n Visual Studio Integration Program n set of COM APIs for integrating new functionality into VS: n n n 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

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

What we’ve done so far n Infrastructure: n n n 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

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

Conclusion n 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!)

GHC’s API data Module. Graph = [Mod. Summary] data Mod. Summary –- contains module name, location, imports data Cm. State cm. Init : : Ghc. Mode -> Dyn. Flags -> IO Cm. State -- Stuff for cm. Dep. Anal : : cm. Load : : cm. Unload : : –-make, Cm. State basic GHCi operation: -> [File. Path] -> IO Module. Graph -> IO (Cm. State, Bool, [String]) -> IO Cm. State -- Visual Studio: -- Project knows the Module. Graph -- Don’t need to fully compile modules data Err. Msg cm. Analyse : : Cm. State -> Module. Graph -> Module -> IO (Cm. State, Either [Err. Msg] Module. Info) cm. Module. Changed : : Cm. State –> Module -> IO Cm. State

-- Should we provide access to the complete abstract syntax -- (perhaps in a simplified form? THSyntax? Iface. Syn? ) or just -- accessors? data Src. Loc data Src. Span type. Of. Id : : Src. Loc -> Module. Info -> Maybe Type defn. Of. Id : : Src. Loc -> Module. Info -> Maybe Src. Loc top. Decls : : Module. Info -> [(Src. Span, String)]