Re: guile bugs

[Mikael Djurfeldt <mdj AT mdj-pc.nada.kth.se>]

Greg Badros <gjb@cs.washington.edu> writes:

> Jim Blandy <jimb@red-bean.com> writes:
> 
> > > Any guile person want to remind me why SCM_BOOL_F was not made to be 0?
> > > I know the tagging scheme is complex, but I'd certainly design it so
> > > that I could have 0 be #f.
> > 
> > So that pointers can be used directly, for speed.  Probably not a good
> > argument; if you subtract off the tag, that'll get added into whatever
> > offset you're using to fetch a structure element...
> 
> Hmmm... yea, it sure would've saved a lot of bugs in Scwm (especially
> early on) if Scheme booleans could be treated as C booleans.  I
> hypothesize that three changes would find a ton of bugs in Guile and Scwm:
> 
> 1) SCM_BOOL_F should be 0 so it is false in C

I don't like this argument.  It's not true that this change would
eliminate bugs.  Using SCM values directly in C is a violation of the
abstraction barrier and clearly a bug. The suggested change would, in
fact, multiply them.  It would make code with this type of bug work,
so that they are harder to find.

You may say that it's not a serious bug, but I say it is.  If we, in
the future, reorganize the interpreter, we may find strong reasons not
to represent SCM_BOOL_F as 0.  It wouldn't be nice then if 50% of all
applications break when we make the change.

What is important is to consider which representation gives most
efficient code.  There is a risk that subtracting a tag does affect
efficiency of the compiled code, because many pointer references in
Guile is made with offset 0.  (However, on some processors,
referencing with offset 0 is as efficient as referencing with other
small constant offsets.)  Note also that pointer references are made
much more often than boolean values are tested.  I would say the ratio
is 50:1.  But what really would make pointer tag != 0 slow, is that
you would need to *add* the tags when consing.