Changes between Version 73 and Version 74 of NewGhciDebugger


Ignore:
Timestamp:
Apr 10, 2007 12:19:35 PM (7 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NewGhciDebugger

    v73 v74  
    376376=== Stopping at a breakpoint at runtime in the byte code interpreter === 
    377377 
    378 Unfortunately this story is somewhat complicated, ''c'est la vie''. 
     378Unfortunately this part of the story is somewhat complicated, ''c'est la vie''. 
    379379 
    380380To understand what happens it is necessary to know how GHCi evaluates an expression at the command line. When the user types in an expression (as a string) it is parsed, type checked, and compiled, and then run. In `main/GHC.hs` we have the function: 
     
    382382   runStmt :: Session -> String -> IO RunResult 
    383383}}} 
    384 The `Session` argument contains the piles of environmental information which is important to the compiler. The `String` is what the user typed in, and `RunResult` is the answer that you get back if the execution terminates. 
     384The `Session` argument contains the gobs of environmental information which is important to the compiler. The `String` is what the user typed in, and `RunResult` is the answer that you get back if the execution terminates. `RunResult` is defined like so: 
     385{{{ 
     386   data RunResult 
     387      = RunOk [Name]                -- names bound by this evaluation 
     388      | RunFailed                   -- statement failed compilation 
     389      | RunException Exception      -- statement raised an exception 
     390      | forall a . RunBreak a ThreadId BreakInfo (IO RunResult) 
     391}}} 
     392The first three constructors are part of the original code, and the last one, `RunBreak` was added for the debugger. Hopefully the first three are self-explanatory; we will explain `RunBreak` in due course. 
    385393 
    386394Normally what happens is that `runStmt` forks a new thread to handle the evaluation of the expression. It then blocks on an `MVar` and waits for the thread to finish. When the thread finishes it fills in the `MVar`, which wakes up `runStmt`, and it returns a `RunResult`. Ultimately this gets passed back to the GHCi command line. Actually, GHCi is merely a ''client'' of the API, and other clients could also call `runStmt` if they wanted something evaluated.