Mon Sep 24 14:15:54 CEST 2007
yes, i am at fault here. never really gave it much thought, but it's
starting to become a problem. my error reporting sucks.
one of the most dramatic problems is the loss of line numbers to
relate errors to original code. a solution for this is to use syntax
second is the way errors are handled in the assembler. currently i
have some code that's a bit hard to understand: i got used to hygienic
macros, and symbol capture looks convoluted to me. maybe i just need
to rewrite that first?
hmm.. what about systematicly replacing 'raise' with something more
highlevel. one of the things that is necessary is a stack trace. there
was some talk on the plt list about this recently. let's have a look.
there is (lib "trace.ss") which doesn't really do what i need, since
it's active. what about taking this error reporting seriously, and
giving it its own module? would be good to eventually document all
possible errors etc.
what about the following strategy: every dubiously reported error will
be fixed, no matter what it takes.
#<case-lambda-procedure>: no clause matching 1 argument: (qw)
this is a stack underflow error
i was thinking about installing an error translator in rep.ss, but
this kills the tail position. therefore, errors need to be translated
at the top entry point, which in this case is in prj.ss
it's really not such a simple problem.. need to define what
information i'd like to get: errors need to b e reported at
'interface' level which is either compile/run of files/words.
compile errors are most problematic since they need to be related to