Re: scm_cur_loadp in an error hander

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> > So, please try this instead:
> > 
> >   computer> cat >.guile
> >   (debug-enable 'debug)
> >   (read-enable 'positions)
> >   (hello)
> 
> I can't do that by mistake :)

No, you're right.  :)

Notice the two levels here: Some errors occur in the reader already
before even having created a (valid or invalid) expression, but most
errors occur when evaluating expression.  The support for the latter
kind of errors is reasonably good, but not the support for the former.

> I want to get these locations detected by the loader.  Any good idea?

Just F.Y.I: This is the current chain of events at an error:

1. The error is detected by ordinary code.

2. Ordinary code calls one of the error routines (such as
   scm_misc_error).

3. The error routine throws the error using scm_ithrow.

4. The throw is caught by a "lazy-handler" which is special in that
   the stack isn't popped before the handler is executed.

5. The "lazy-handler" records information about the error.  It creates
   a representation of the stack using scm_make_stack and stores it in
   the last-stack fluid.  It then throws the error.
   (scm_internal_stack_catch sets up such a handler automatically.)

6. The stack pops and the throw is caught by an error reporting
   handler, either the one in boot-9.scm or one provided to
   scm_internal_stack_catch.

But in this case, the best solution is probably that we extend the
reader to supply more detailed information (such as filename and
position) at point 2 above.  (Maybe we could use the last "rest"
argument for this?)

This information should then probably be stored away in a new fluid at
point 5.  (This is so that the debugger will be able to access it
later.)  Maybe we could also store the stack in this fluid in the
future in order to avoid having two fluids with error information.

Note, however, that the reader is a critical component concerning fast
loading of code, so we can't make changes which will slow it down.

> > We could also consider if maybe the debugging evaluator and position
> > information should be enabled by default while reading .guile.
> 
> Adding an option like --debug-init may be enough.
> Not helpful for beginners, though.

Let's do that!