Saying this without having looked at your code and also without currently promising to do any work:
How does the record subtyping relate to GOOPS? I do realize that there are issues related to keeping bootstrapping lean, but shouldn't record types and classes share mechanisms? Best regards, Mikael On Wed, Oct 30, 2019 at 9:55 PM Andy Wingo <wi...@pobox.com> wrote: > 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 > >
