gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] RE: [Maxima] Re: Maxima cmucl patch


From: Steve Haflich
Subject: Re: [Gcl-devel] RE: [Maxima] Re: Maxima cmucl patch
Date: Mon, 02 Feb 2004 08:52:26 -0800

   From: Richard Fateman <address@hidden>
   
   (trace foo) works by redefining the program foo,
   essentially doing
   
   (setf old-program (symbol-function 'foo))
   (setf (symbol-function 'foo)  (tracing-program old-program))
   ;; plus a lot of checking so that (untrace) works and reloading works..

Don't depend on this model, as it is not universal across all
implementations.  There are at least two ways trace can be
implemented.

  The more common way is as you describe above, where some sort of
tracing encapsulation replaces the definition bound to the function
name.

  The alternative is to modify the first-class function object itself,
changing the pointer to its machine code to point to an encapsulation
wrapper.  In effect this modifies the function object itself rather
than modifying the binding referenced by the name of the function.

Both systems require the bookkeeping you mention so that there are no
surprises e.g. when functions are redefined (usually programmers
expect them to stay traced).  The systems may behave differently under
certain boundary cases of redefinition and trace/untrace, and on
self-recursive calls.  The advantage of the second approach (on
implementations whose architecture can support it without performance
penalty) is that tracing does not depend on resolving the binding of
name to function at execution time.  If a function object (not the
name of a function) is captured and stored somewhere, such as in the
callback slot of some GUI widget, it can still be traced and untraced
(either by its name and by reference to it as a first-class object).
Even closure functions, and perhaps even individual instances of
closures, can be traced.  It is very hard to make this work in the
first scheme.

Recent versions of Allegro use the second model.  We've found its
advantages worth the implementation hair (since it does require a
little low-level platform-dependent support).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]