Title: Visual Studio Haskell
1Visual Studio / Haskell
- Simon Marlow
- Krasimir Angelov
- others
2Background
- We all use a development environment of one kind
or another - Emacs
- Vi
- Notepad
- WinHugs
3Existing 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
4Problems
- 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 Haskell98FFI,
hierarchical modules, CPP, literate. - Jumping to an error often misses (compilers dont
have good source loc info). - No real compile support
- Many, many, many more things an IDE can do
5What were 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.
6Background 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/customisa
tion. - free access to the integration APIs
- Windows only
7Status 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
8Demo
9Features 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
10More 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??
11Implementation
- 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
12The obligatory block diagram
VSIP COM interfaces
Babel COM interfaces
Visual Studio
Babel
Haskell Service
C/C
Haskell
Direct to VSIP for project support
13What weve done so far
- Infrastructure
- Use H/Direct for accessing COM APIs (about 15
bugs in H/Direct found so far!) - Multi-threading support in GHCs RTS (parsing
colouring run in separate OS threads) - Accurate source location info in GHCs internal
abstract syntax (phew) - Support in GHC to build GHC as a package
- Krasimir basic project support, more to come
14GHC 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
15Conclusion
- What features would you like to see in an IDE?
What would make it compelling enough for you to
use? - Well ship GHC as a package soon.
- VS plugin will be available at some point (help
needed!)
16GHCs API
data ModuleGraph ModSummary data ModSummary
- contains module name, location, imports data
CmState cmInit GhcMode -gt DynFlags -gt IO
CmState -- Stuff for -make, basic GHCi
operation cmDepAnal CmState -gt FilePath -gt
IO ModuleGraph cmLoad CmState -gt
ModuleGraph -gt IO (CmState, Bool,
String) cmUnload CmState -gt IO CmState --
Visual Studio -- - Project knows the
ModuleGraph -- - Dont need to fully compile
modules data ErrMsg cmAnalyse CmState -gt
ModuleGraph -gt Module -gt IO (CmState,
Either ErrMsg ModuleInfo) cmModuleChanged
CmState gt Module -gt 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 -gt
ModuleInfo -gt Maybe Type defnOfId SrcLoc -gt
ModuleInfo -gt Maybe SrcLoc topDecls ModuleInfo
-gt (SrcSpan, String)