Re: Inconsistant Results

[Jim Blandy <jimb at savonarola dot red-bean dot com>]

[was on bug-guile]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> 
> > Thus, you see, guile should not have accepted that macro as a parameter
> > for reduce.  However, stupidly, guile accepted it and then 'rewrote' that
> > function in memory.  Thus, (procedure-source reduce) before and after
> > passing that macro looked different.
> 
> Yes.
> 
> However, I don't think we should try to fix this problem in the
> current system.  There are further problems with Guile macros.
> The problem is not so much in the implementation as in the design of
> the current Guile macros.
> 
> The correct solution is to write a new hygienic macro system.
> 
> We have that in the (ice-9 syncase) module, but it should be rewritten
> in C (and probably in a different way).

Setting aside the possibility of implementing the macros in a
completely different way:

I was talking to Chris Hanson about macro systems, complaining that
the syntax-case system was slow, and saying that we should
re-implement it in C.  Chris then said the obviously sensible thing,
making me blush: "Don't you think you should find out where it's
spending its time before you rewrite the whole thing?"

I'd love to see some profiling support added to Guile.  When we're
using the debugging allocator, could a handler for SIGPROF get access
to the backtrace?