Trying to get a NN code going

Richard A. O'Keefe ok@atlas.otago.ac.nz
Wed, 3 Mar 1999 12:34:47 +1300 (NZDT)


	> What I *do* expect from a Pascal or Ada compiler is that it will
	> tell me not just where the 'index out of range' was detected, but
	> WHERE IT CAME FROM, e.g. a backtrace of some kind.

	Ah, I see the confusion. You say you expect such things from the
	compiler, where I would expect such things from the compiled program
	or from the run time system. A matter of terminology perhaps.
	
Let me rephrase what I wrote:

    What I do expect from any language compiler is that it
    will bring it about that a run time error will result
    in adequate information about the location of the error.

On a UNIX system, it is the *compiler's* responsiblity to put debugging
information in the object files (as described in the DWARF specification,
if one's using ELF object format).  The error report and backtrace will
_happen_ at run time, but they will only happen if the _compiler_ does
something to _make_ them happen.

In a computer language processing system that does not rely on native
object files, the run time system might have a larger share of the
responsibility, but Clean on a SPARC is not such a system.

There's an old technique which can provide useful information even in
the presence of tail recursion and other optimisations.  Keep a circular
buffer of procedure identifications (such an identification might be a
pointer to a read-only record containing a file name and line number
and possibly a function name).  At the entry point of each procedure,

    if this procedure identification is not the last entry in
    the circular buffer (or possibly even "not among the last
    N entries") then push it.

When the program gets a run time error, print the buffer.  This isn't
a backtrace, but it's a useful approximation of one, and it involves
absolutely no dependence on the method used to implement procedure calls.