This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Inconsistant Results
- To: Jim Blandy <jimb at savonarola dot red-bean dot com>
- Subject: Re: Inconsistant Results
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 22 Jun 2000 02:38:39 +0200
- Cc: guile at sourceware dot cygnus dot com
- Cc: djurfeldt at nada dot kth dot se
- References: <Pine.LNX.4.21.0006211602550.7528-100000@marvin.ida.ing.tu-bs.de><xy7k8fjvxdn.fsf@mdj.nada.kth.se><m3zooepy15.fsf@savonarola.red-bean.com>
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.