Re: Making Guile slower?

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

Marius Vollmer <mvo@zagadka.ping.de> writes:

> In my view, the conservative thing would have been to alias the
> existing macros to names including SLOPPY, to introduce STRICT
> variants of these macros (that include the SCM_NIMP test) and then
> gradually change the NIMP && SLOPPY combos to STRICT, with amble
> public testing on the way, and backward compatability.  When no
> references to the old names (without SLOPPY or STRICT) are present,
> you could then rename the STRICT variants to the old, simple names.
> The resulting machine code of Guile would stay unaffected all the
> time, but the clarity of the source would be improved.

I agree that this is the right approach.  While my slugbrain slowly
begins to accept the basic idea of Greg's change (in my interpretation
to replace NIMP + FOOP with FOOP *but also* to replace FOOP with
SLOPPY_FOOP) as very good, I would have liked all SLOPPY_FOOP cases to
be treated manually.  Your strategy would have been excellent in doing
this.

We also have the stability to think about.  Guile has been really
stable for the last couple of years.  It's a great strength if you can
trust the interpreter.  You really have to be extremely careful when
messing around with it, because if you aren't, things will be messy
when you've finished messing.  The SCM_NECONSP macro, e.g., wasn't
bugfixed even after it was bugfixed, and that was three lines of
code...  [not saying that Greg is stupid; saying that these are
difficult things which requires carefulness]