From: Mikael Djurfeldt <mikael@djurfeldt.com>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: guile 3 update, halloween edition
Date: Thu, 31 Oct 2019 15:17:31 +0100 [thread overview]
Message-ID: <CAA2XvwJAERXFeAGc8S5ufWRR0z+ujpGvw0JDA94bL_0k_fyu-w@mail.gmail.com> (raw)
In-Reply-To: <87o8xyhtz6.fsf@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 4867 bytes --]
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 <wingo@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
>
>
[-- Attachment #2: Type: text/html, Size: 5786 bytes --]
next prev parent reply other threads:[~2019-10-31 14:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 20:13 guile 3 update, halloween edition Andy Wingo
2019-10-30 21:19 ` Christopher Lemmer Webber
2019-10-31 0:01 ` Chris Vine
2019-10-31 16:20 ` Andy Wingo
2019-10-31 17:27 ` Chris Vine
2019-10-31 1:31 ` Nala Ginrut
2019-10-31 1:47 ` Thompson, David
2019-10-31 14:17 ` Mikael Djurfeldt [this message]
2019-10-31 16:13 ` Andy Wingo
2019-10-31 14:46 ` David Pirotte
2019-10-31 16:44 ` Sjoerd van Leent
2019-11-02 5:20 ` Mark H Weaver
2019-11-02 19:33 ` Mark H Weaver
2019-11-03 19:16 ` Andy Wingo
2019-11-03 20:18 ` Mark H Weaver
2019-11-15 9:03 ` Ludovic Courtès
2019-11-15 10:23 ` Andy Wingo
2019-11-16 15:26 ` Ludovic Courtès
2019-11-17 19:33 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA2XvwJAERXFeAGc8S5ufWRR0z+ujpGvw0JDA94bL_0k_fyu-w@mail.gmail.com \
--to=mikael@djurfeldt.com \
--cc=guile-devel@gnu.org \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).