Re: Inconsistant Results

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

Jim Blandy <jimb@savonarola.red-bean.com> writes:

> > 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?"

Well, I have no reason to blush since I know

1. that Dybvig's implementation has good time complexity and that the
   parsing and coloring of code could be done a lot more efficiently
   in C (at least until we have a decent Scheme compiler)

2. that there is an alternative way to implement syntax case macros
   based on how SCM implements its R4RS high-level macros which has
   even less overhead than Dybvig's scheme based on marking and
   unmarking

I think we should go for this second solution.

In any case, there is simply no way that interpreted Scheme code alone
could implement an efficient hygienic macro system.

> 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?

Yes, but currently only in a convoluted way.  It is easy to add a new
primitive (or extend an old one) to enable efficiently reading out
only the last stack frame, though.