Re: Making Guile slower?

["Greg J. Badros" <gjb at cs dot washington dot edu>]

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

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

Once again, if I believed that FOOP should turn into SLOPPY_FOOP in all
places, I would have done it this way.  I do *NOT* believe this, since
it's better to use the safe (STRICT_FOOP in Marius terminonlogy) version
whereever the SLOPPY version is not *needed* for performance.

I agree I was aggressive in this change, but Guile needs improvements in
lots of places so it needs more aggression and less discussion.  I think
a lot of the problems with my pervasive change wouldn't seem like such a
big deal if there were two development branches so people weren't
stressed about short-term things that'll get fixed.

Could we please just redirect our typing time into adding docstrings and 
improving the regression tests to find bugs?

<snip>

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

I'm glad you're avoiding calling me stupid since that might insult me,
but you are calling me careless.  With over 30,000 lines of diffs to
Guile (~ 500 pages), you gotta expect there's gonna be some bugs I
introduced.  But as I pointed out, there are also plenty of bugs that I
eliminated, and the potential for many more as the code is now more
readable, and will soon be better-checked statically.  (Hell, I'd be
done with that work by now if I weren't so busy defending my changes
here).  

Let's take the bugs that are now available as reasons to improve the
regression test suite.

Greg