guile 3 update, halloween edition

[Andy Wingo <wingo@pobox.com>]

Hey folks!

I wanted to send out an update on Guile 3.  Do take a look at
https://git.savannah.gnu.org/cgit/guile.git/tree/NEWS to see where we've
come; basically the JIT is done, and we're ready to release soonish.

However!  Here begins a long chain of yak-shaving:

I wanted good benchmarks.  Generally up to now, we haven't really been
doing good incremental benchmarks.  Ideally we could see some benchmark
results historically, on every commit, and against other Scheme
implementations.  To a degree it's been possible with
https://ecraven.github.io/r7rs-benchmarks/, but those benchmarks have a
few problems:

 (1) They use unsafe optimizations on e.g. Chez and Gambit
 (2) They are infrequently run
 (3) They rely on R7RS, adding their own little compat layer for Guile,
     which isn't optimal.

Now, regarding (3), probably Guile should just have its own R7RS layer.
And it should be easier to enable R6RS too.  So I added an --r6rs
option, and started importing some R7RS code from Göran Weinholt
(thanks!), with the idea of adding --r7rs.  That way we can just
benchmark the different implementations, just passing --r7rs or whatever
to get the behavior we want.  We can reduce the set of other scheme
implementations to just the high-performance ones: Gambit, Larceny,
Chez, and Racket.

However!  R7RS, like R6RS and like SRFI-35/SRFI-34, and also like
Racket, specifies an error-handling system in terms of "raise" and
"with-exception-handler".  Guile uses "throw" and "catch".  There is a
pretty good compatibility layer in Guile's R6RS exceptions/conditions
code, but it's not shared by SRFI-35/SRFI-34, and unless we built R7RS
in terms of R6RS -- something I prefer not to do; these things should be
layered on Guile core directly -- we'd have to duplicate the mechanism.

Which, of course, is a bit trash.  And when you come to think of it,
throw/catch/with-throw-handler is also a bit trash.  It is too hard to
handle exceptions in Guile; the addition of `print-exception' a few
years back improved things, but still, making any sense out of the
"args" corresponding to a "key" is a mess.

All this made me think -- Guile should probably switch to
raise/with-exception-handler and structured exceptions.  (Or conditions,
or whatever we choose to call them.  I find the "condition" name a bit
weird but maybe that's just a personal problem.)  Racket does this too,
for what it's worth, though they have their own historical baggage.

But, we need to maintain compatibility with throw/catch, because that's
not going anywhere any time soon (if ever).  So I hacked a bit and
eventually came up with a decent implementation of throw/catch on top of
raise/with-exception-handler, and I think it's compatible in all the
weird ways that it needs to be.

But!  Now we have bootstrapping problems; how to get the implementation
in boot-9?  Exceptions in SRFI-35, R6RS, R7RS, and Racket are these
hierarchical things: they form a DAG of subtypes.  But core records in
Guile aren't subtypeable, so what to do?

Well, my thinking was that we needed to sedimentarily deposit down into
Guile core those commonalities between the different record
implementations in Guile: SRFI-35 conditions, R6RS records, and SRFI-9
records.  So core now has the notion of field mutability on the record
layer (as opposed to the struct layer), a notion of subtyping, a notion
of extensibility, and so on.  This is all now in the manual and will be
in NEWS.

With that, we now have just one implementation of records!!!  I am very
pleased about this.  Now you can use core record introspection
facilities on any record in Guile.  Cool.  This also helped untangle
some knots in the R6RS inter-module graph.

So, now the pending task is to somehow get a condition/exception
hierarchy into Guile core.  I will try to mostly push things off to side
modules but it won't always be possible.  There will be bijections
between a Guile's "throw" arguments and structured exceptions, mostly
inspired with what Julian did in the R6RS layer already.

Thoughts welcome!  Also: should these structured error objects be named
exceptions or conditions?  SRFI-35, R6RS, and R7RS say "conditions", but
racket and my heart say "exceptions"; wdyt?

Cheers,

Andy