1 / 17

Visual Studio / Haskell

Visual Studio / Haskell. Simon Marlow Krasimir 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!)

sheryl
Download Presentation

Visual Studio / Haskell

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. GHC The obligatory block diagram VSIP COM interfaces Babel COM interfaces Visual Studio Babel Haskell Service Direct to VSIP for project support C/C++ Haskell

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

More Related