A program for evaluating a Haskell expression step-by-step
|LICENSE||token LICENSE file|
stepeval operates on haskell-src-exts ASTs, performing a single evaluation step (e.g. pattern matching, function application) at a time. stepeval comes bundled with an executable that can operate as a command-line utility or a CGI script. In either case it takes an expression input as a string and displays each step of its evaluation, until it reaches weak head normal form or, in the case of the CGI script, a time limit expires. stepeval is very much incomplete; it has a raft of unimplemented features and three failing testcases, one of which is pretty basic. Use at your own risk! Contact: haskell at benmachine dot co dot uk or via IRC: benmachine on Freenode or QuakeNet If you want to see things in action without downloading anything, try http://bm380.user.srcf.net/cgi-bin/stepeval.cgi where an example instance of the CGI script is usually running. BUILD NOTES: The version constraints are conservative - only things that I've personally tested with. If you are told your version of whatever doesn't fit into them, relax them; if it works, tell me! TODO: Rewrite from scratch, after having read the literature about how to evaluate functional languages properly. Perhaps leaving it in syntax form is basically unsatisfactory, and the first thing I should do is a visualisation of the program's graph. I need to think about how function application is done. Problem is we can't easily show how guards are stepped through etc. because we can't modify the original definition. Perhaps we introduce the funbind to a local let binding and then modify that. The testsuite has no means for requiring that evaluation stop at a given point. In function application, results aren't always shared as much as they should be. Basically evaluation is often non-strict instead of lazy, as in the classic example let double x = x + x in double (double 10) Better support for primitive operations like arithmetic. This may be related to class instance resolution. EnumFrom syntax is not at all supported Type inference would be nice, to resolve class instances. It would be nice to have a UI in which one could easily change either the expression to be stepped or the environment it is being stepped in. Everywhere in the program I have emphasised correctness and simplicity of code over performance. In a lot of small ways and a few big ones the efficiency of the algorithms involved is much poorer than it needs to be. FIXME: Nested let-scopes aren't properly supported. If you use an external definitions file, the evaluator doesn't know that those definitions can't be changed, so pattern bindings that require evaluation may go wrong. This isn't really a big deal though because such files are intended mainly for functions, which don't have this problem.