[Openmcl-devel] STEP function

[Ron Garret]

Since the topic has been raised, why does cheap-eval-in-environment still exist then?  And could this be used to bootstrap a STEP function?

On Jan 9, 2010, at 5:00 PM, Gary Byers wrote:

> Just to fill in the blanks a bit (with stuff that may be painfully
> obvious):
> 
> Historically, most CL implementations contained an interpreter as well
> as a compiler.  (ANSI CL defines compilation in terms of things like
> how EVAL-WHEN is handled and when macroexpansion takes place; it's not
> necessary for an implemenation's "compiler" to ever generate machine-
> or byte-code; likewise, there's no requirement that EVAL be
> implemented in terms of an interpreter - "evaluating a form" should
> always have the same general effects as "compiling that form and
> calling the resulting function", except in some fairly pathological
> cases.)  So, the first sentence above should be read as something
> like "historically, most CL implementations contained an interpreter
> that evaluated lisp forms at runtime, and a compiler which translated
> those forms to functionally equivalent machine code for a real or
> virtual machine."
> 
> For other (mostly historical) reasons, it was typically the case that
> forms typed interactively (or LOADed from a source file) were
> processed by the interpreter and functions defined in those
> environments were "interpreted functions"; compiled functions were
> generally only produced by calling COMPILE explicitly or by loading
> the binary (FASL) file produced by COMPILE-FILE.  Some of the reasons
> for this strategy had to do with resource constraints: compilers were
> (relatively speaking) big and slow components of a lisp system, and
> compiling things that were defined interactively was likely (or was
> seen as likely) to disrupt the interactive development process.
> Interpreters were also more likely to offer better debugging
> facilities than were available in compiled code (for instance, the
> mapping between variable names and values was more likely to be
> available at runtime) and pre-ANSI CL defined interfaces to the
> interpreter (EVALHOOK, APPLYHOOK, and friends) that could be used
> by the interpreter (to implement STEP) and/or the user.
> 
> When MCL was being developed (on 68K Macs with at most a few MB of
> memory) in the mid-late '80s, resource constraints were certainly
> a factor, but we evaluated the tradeoffs differently.  The compiler
> was (relatively) small and fast, compiled functions were not only
> much faster than their interpreted equivalents but were often much
> smaller as well, and that was a very, very important consideration
> in those days.  We supported interpreted functions (largely in order
> to support STEP), but because of the way that some things were 
> implemented and some design decisions, debugging in the presence
> of interpreted functions was generally worse than it was in their
> absence (backtrace would show internal interpreter functions and
> not the functions that the interpreter was working on, etc.)
> 
> MCL offered the ability to turn off the automatic compilation
> of things defined interactively; the primary reason for doing
> this was to use STEP for debugging.  Some people might have
> preferred to run with automatic compilation turned off for that
> reason, but it tended to make things slower, bigger, and otherwise
> harder to debug.  There was an option (that may still be present
> in CCL) to compile definitions but leave the lambda expression
> attached to the resulting function, so that STEP could work on
> compiled code (by interpreting that lambda expression.)  That
> worked fairly well much of the time, but could fail if (for instance)
> macro definitions that were present at compile time were different
> or missing at runtime.
> 
> Aside from the issues of how to arrange for code to be STEPpable
> (well, perhaps related to them), there were real question as to
> how useful STEP is/was as a debugging tool.  One often does debugging
> by binary search - "everything's OK at point A, something's wrong at
> point B, so I need to try again and take a closer look at what happens
> between those points."  MCL's stepper possibly could have offered
> better support for this kind of thing than it did, but I think that
> many people (not all) found that the facilities that it did offer -
> "step into", "step over", "step out of" - weren't often adequate
> to debug non-trivial problems (and having to run large bodies of
> code under an interpreter also made it impractical to use STEP to
> debug non-trivial problems.)  Not everyone shared this opinion -
> there were/are users who found it useful - but I think that I 
> successfully used STEP to find a real bug exactly once in several
> attempts over more than 10 years, and I think that many people
> (including most people involved in the implementation) thought of
> it as a toy.
> 
> OpenMCL inherited all of this from MCL, and at some point 5-6 years
> ago I ran into a bug in the interpreter, and the simplest fix (given
> that the interpreter existed only to support STEP, the limited utility
> of STEP, and the cost of trying to maintain the interpreter) was to
> simply excise the interpreter (and the concept of "interpreted
> functions").  Part of the justification for doing that is that since
> we're in practice primarily (if not entirely) a compiled-only
> implementation, it's of more benefit to improve facilities for
> debugging compiled code than it is to provide parallel facilities
> (STEP and interpreted code) that don't seem to scale well enough
> to be useful.
> 
> Debugging facilities for compiled code have probably improved some
> over the last few years, but the work that Bill's referring to - the
> ability to do STEP-like things on compiled code - would likely be a
> more dramatic improvement.  One prerequisite for this - the ability to
> map between points in a function's source code and corresponding points
> in its machine code - is in place, though there are obviously other
> issues and that correspondence may be less precise than it would be
> in an interpreter.  If the tradeoffs are that you can do at least
> some STEP-like debugging (enough to be useful) in aggressively
> optimized code and lots of useful debugging of code compiled under
> less agressive settings, that seems far preferable to the traditional
> interpreter-based approach.
> 
> 
> 
> 
> On Sat, 9 Jan 2010, Bill St. Clair wrote:
> 
>> I think the only reason we don't do it is because nobody has yet
>> considered it important enough to pay for. We've probably done at
>> least part of the work with Gail's coverage facility. Gail, how much
>> effort do you think STEP would be?
>> 
>> -Bill
>> 
>> On Sat, Jan 9, 2010 at 3:58 PM, Philippe Sismondi <psismondi at arqux.com> wrote:
>>> I am just now trying to improve my beginner's skills at interactive debugging in CL. As far as I can tell the ccl STEP fn does nothing but evaluate the form. I see that this is permitted by the spec.
>>> 
>>> If that is correct, is there any likelihood that STEP will be more fully implemented in ccl? Is "single stepping" not considered useful in CL debugging?
>>> 
>>> Best,
>>> 
>>> - Phil -
>>> 
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>> 
>> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel