Changes between Version 14 and Version 15 of GhciDebugger


Ignore:
Timestamp:
Dec 1, 2006 5:31:15 PM (9 years ago)
Author:
mnislaih
Comment:

General comments on maintainability && Fix links to source files

Legend:

Unmodified
Added
Removed
Modified
  • GhciDebugger

    v14 v15  
    33
    44= Report of the implementation of the GHCi debugger =
    5 During the Summer of 2006 I have been working on this project sponsorized by the[http://code.google.com/soc Google SoC] initiative. My mentors were Simon Marlow and David Himmelstrup (lemmih).
     5During the Summer of 2006 [mailto:[email protected] I] have been working on this project sponsorized by the[http://code.google.com/soc Google SoC] initiative. My mentors were Simon Marlow and David Himmelstrup (lemmih).
    66
    77It has been a lot of fun, and I've learnt a huge amount of things, but the reader must be warned that I am still a beginner in many aspects, and that my knowledge of ghc is very shallow. So please take my words with a bit of perspective.
     
    1717}}}
    1818
    19 The term datatype is defined at a module `RtClosureInspect` in the ghci folder. This datatype represents a partially evaluated Haskell value as an annotated tree:
     19The term datatype is defined at  [[GhcFile(compiler/ghci/RtClosureInspect.hs)]]. This datatype represents a partially evaluated Haskell value as an annotated tree:
    2020{{{
    2121data Term = Term { ty        :: Type
     
    130130Ideally, we want to lift this restriction on ghci some day. For now, the tyvars are instantiated to a family of dummy types, indexed by kind arity, which live in GHC.Base: `Unknown`, `Unknown1`,`Unknown2`, etc.
    131131
    132 The interactive ui uses `GHC.obtainTerm` to implement the :print and :sprint command. The difference is that :print, additionally, binds suspended values.
     132The interactive ui uses `obtainTerm` from the ghc-api, which lives at  [[GhcFile(compiler/ghci/RtClosureInspect.hs)]], to implement the :print and :sprint command. The difference is that :print, additionally, binds suspended values.
    133133Thus, suspensions inside semievaluated terms are bound by `:print` to _t,,xx,, names in the interactive environment, available for the user.
    134134
    135 This is done at `InteractiveUI.pprintClosure`, which takes responsibility of instantiating tyvars with  members the `GHC.Base.Unknown` family. A  an associated Show instance is provided that instructs the user to `seq` them to recover the type.
     135This is done at `pprintClosure`in  [[GhcFile(compiler/ghci/Debugger.hs)]], which takes responsibility of instantiating tyvars with  members the `GHC.Base.Unknown` family. A  an associated Show instance is provided that instructs the user to `seq` them to recover the type.
    136136
    137137There are two quirks with the current solution:
     
    193193There is probably an easy to formulate optimum criteria, but I can't figure it out for now :(
    194194
     195One more thing, newtypes need to be flattened before doing the unification; type reconstruction may not be able to recover the newtype representation.
     196
    195197=== Pretty printing of terms ===
    196198We want to customize the printing of some stuff, such as Integers, Floats, Doubles, Lists, Tuples, Arrays, and so on.
    197 At the `RtClosureInspect` module there is some infrastructure to build a custom printer, with a basic custom printer that covers the enumerated types.
    198 
    199 In InteractiveUI.hs the function `pprintClosure` takes advantage of this and makes use of a custom printer that uses Show instances if available.
     199At the  [[GhcFile(compiler/ghci/RtClosureInspect.hs)]] module there is some infrastructure to build a custom printer, with a basic custom printer that covers the enumerated types.
     200
     201In  [[GhcFile(compiler/ghci/Debugger.hs)]] the function `pprintClosure` takes advantage of this and makes use of a custom printer that uses Show instances if available.
    200202
    201203
     
    328330== The D in Dynamic Breakpoints ==
    329331
    330 In order to implement the 'isAutoBkptEnabled' record, when a breakpoint is hit GHCi must find out whether that site is enabled or not. GHCi thus stores a boolean matrix of enabled breakpoint sites. This scheme is realized in [http://darcs.haskell.org/SoC/ghc.debugger/compiler/main/Breakpoints.hs Breakpoints.hs]:
     332In order to implement the 'isAutoBkptEnabled' record, when a breakpoint is hit GHCi must find out whether that site is enabled or not. GHCi thus stores a boolean matrix of enabled breakpoint sites. This scheme is realized in [ [[GhcFile(compiler/main/Breakpoints.hs)]]]:
    331333{{{
    332334data BkptTable a  = BkptTable {
     
    338340Since this structure needs to be accessed every time a breakpoint is hit and is modified extremely few times in comparison, the goal is to have as fast access time as possible. All of the overhead in our debugger is going to be caused by this operation.
    339341
    340 It's too bad that I haven't explored alternative designs. (Using bits instead of Bools in the matrix? discard the matrix thing and use an IORef in every breakpoint? some clever trick using the FFI?).
     342Alternative designs should be explored. (Using bits instead of Bools in the matrix? discard the matrix thing and use an IORef in every breakpoint? some clever trick using the FFI?). Suggestions are welcome.
    341343
    342344= Pending work =
     
    345347
    346348
    347 Rewrite of the Term pretty printer at RtClosureInspect.hs
     349Rewrite of the Term pretty printer at  [[GhcFile(compiler/ghci/RtClosureInspect.hs)]]
    348350Rewrite of the type recovery code
    349351''Put together all the small todos here''
     352
     353= General Comments =
     354== Maintaining the debugger ==
     355The '''closure viewer''' is a delicate piece of code, as it depends on:
     356 * The Type System of GHC Haskell. Changes to the typechecker interface or data structures will most likely kill it.
     357 * The runtime representation, which may vary between versions but also architectures
     358An extensive suite of tests should be needed to easily detect when it lags back changes in GHC. Fortunately the code itself isn't too long nor spread.
     359
     360The '''breakpoint instrumentation''' on the contrary is spread everywhere the desugarer, but is less likely to break and in less spectacular ways if it does. For instance, one might lose access to implicit parameters in a breakpoint, or things like that. Tricky stuff are Template Haskell, 'deriving' generated code, breakpoint coalescing..
     361
     362The '''breakpoint desugaring''' depends only on the Core representation, which I think is stabilizing soon with System Fc. This is the less likely piece to break in my opinion, and the easiest to restore.
     363
     364The '''debugger''' itself, i.e. the user interface offered by InteractiveUI, should virtually maintain itself once it is bug-free (which I don't claim it is), as long as future changes to ghci itself respect the few things it assumes.