unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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 --]

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