Visual Studio / Haskell

Simon MarlowKrasimir Angelov

+ others

Background

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

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

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…

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.

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

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

Demo

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

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??

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

The obligatory block diagram

Visual Studio

Babel

VSIP COM interfaces

HaskellService

C/C++ Haskell

Babel COM interfaces

GHC

Direct to VSIP for project

support

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

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…

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

GHC’s API

data ModuleGraph = [ModSummary]data ModSummary –- contains module name, location, importsdata CmState

cmInit :: GhcMode -> DynFlags -> IO CmState

-- Stuff for –-make, basic GHCi operation:cmDepAnal :: CmState -> [FilePath] -> IO ModuleGraphcmLoad :: CmState -> ModuleGraph -> IO (CmState, Bool, [String])cmUnload :: CmState -> IO CmState

-- Visual Studio:-- - Project knows the ModuleGraph-- - Don’t need to fully compile modules

data ErrMsgcmAnalyse :: CmState -> ModuleGraph -> Module -> IO (CmState, Either [ErrMsg] ModuleInfo)cmModuleChanged :: CmState –> Module -> IO CmState

-- Should we provide access to the complete abstract syntax-- (perhaps in a simplified form? THSyntax? IfaceSyn?) or just -- accessors?

data SrcLocdata SrcSpan

typeOfId :: SrcLoc -> ModuleInfo -> Maybe TypedefnOfId :: SrcLoc -> ModuleInfo -> Maybe SrcLoctopDecls :: ModuleInfo -> [(SrcSpan, String)]