From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: guile 3 update, halloween edition Date: Thu, 31 Oct 2019 15:17:31 +0100 Message-ID: References: <87o8xyhtz6.fsf@pobox.com> Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005e7a5205963583ff" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="219949"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Oct 31 15:35:40 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iQBY3-000v7s-MW for guile-devel@m.gmane.org; Thu, 31 Oct 2019 15:35:39 +0100 Original-Received: from localhost ([::1]:50760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQBY0-0002i3-QD for guile-devel@m.gmane.org; Thu, 31 Oct 2019 10:35:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45873) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQBGm-00057j-GJ for guile-devel@gnu.org; Thu, 31 Oct 2019 10:17:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iQBGk-0002hR-88 for guile-devel@gnu.org; Thu, 31 Oct 2019 10:17:48 -0400 Original-Received: from mail-vs1-f41.google.com ([209.85.217.41]:40160) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iQBGk-0002e2-2A for guile-devel@gnu.org; Thu, 31 Oct 2019 10:17:46 -0400 Original-Received: by mail-vs1-f41.google.com with SMTP id v10so4171544vsc.7 for ; Thu, 31 Oct 2019 07:17:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=TUqknH3mUd0yPWeDPibLlOXbJPUJSyiY7re4zSlBTEg=; b=mYLqe/rRIEhCFhXwDYEDehOI+8ExkEqGVeHj/nhabpqHleN1vMwYpvLaf16wT6YOHL 5IRNt1GtDQi4R0Eh5zM5wp6VtaUASaddQzUGNXrxws9Og5QzsrlXsPVWPJQv9PRxOoih iLnsVNzTFv5ees7pUJwbDey8aUcadtzXMXU5jZ6T76oFSUF1ApuRbzxAJJBcf5o5BUsw bJHZ6lwnxwXEiO0s9k2dT5OguKkalFS9p7EMgUvfqR3mjPitTOJgFcDogW55+gL07unR VYcGjMzHqbFdIqsowNMoq1+5E5Rhd/bivufKoRzTZlcRDKP2e/DEWFwD21UORzgjhoZR 58xQ== X-Gm-Message-State: APjAAAWKpHZ/K8CAtbYNwlPbeObmj7mWCjVxiZ3hIa7r5SBIkoi3NEN/ b0oX3r8FpLonDOQGrnYnJnAjN9I0uHjgaqRctRk= X-Google-Smtp-Source: APXvYqyfLFjxv6VaNCV9QbFHNNdAdsII6MKrstvNQHCRlX3Lr+V5KH/EcfYGZchPvelK3nslCrPRfcarkpPLUPICpU4= X-Received: by 2002:a67:8841:: with SMTP id k62mr2961439vsd.101.1572531464992; Thu, 31 Oct 2019 07:17:44 -0700 (PDT) In-Reply-To: <87o8xyhtz6.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.217.41 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:20133 Archived-At: --0000000000005e7a5205963583ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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=C3=B6ran 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 > > --0000000000005e7a5205963583ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Saying this without having looked at your code and al= so without currently promising to do any work:

How= does the record subtyping relate to GOOPS? I do realize that there are iss= ues related to keeping bootstrapping lean, but shouldn't record types a= nd 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.=C2=A0 Do take a look at
https://git.savannah.gnu.org/cgit/guile.git/tre= e/NEWS to see where we've
come; basically the JIT is done, and we're ready to release soonish.
However!=C2=A0 Here begins a long chain of yak-shaving:

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

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

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

However!=C2=A0 R7RS, like R6RS and like SRFI-35/SRFI-34, and also like
Racket, specifies an error-handling system in terms of "raise" an= d
"with-exception-handler".=C2=A0 Guile uses "throw" and = "catch".=C2=A0 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<= br> 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.=C2=A0 And when you come to think of it, throw/catch/with-throw-handler is also a bit trash.=C2=A0 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.=C2=A0 (Or condition= s,
or whatever we choose to call them.=C2=A0 I find the "condition" = name a bit
weird but maybe that's just a personal problem.)=C2=A0 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).=C2=A0 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!=C2=A0 Now we have bootstrapping problems; how to get the implementatio= n
in boot-9?=C2=A0 Exceptions in SRFI-35, R6RS, R7RS, and Racket are these hierarchical things: they form a DAG of subtypes.=C2=A0 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.=C2=A0 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.=C2=A0 This is all now in the manual and will b= e
in NEWS.

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

So, now the pending task is to somehow get a condition/exception
hierarchy into Guile core.=C2=A0 I will try to mostly push things off to si= de
modules but it won't always be possible.=C2=A0 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!=C2=A0 Also: should these structured error objects be name= d
exceptions or conditions?=C2=A0 SRFI-35, R6RS, and R7RS say "condition= s", but
racket and my heart say "exceptions"; wdyt?

Cheers,

Andy

--0000000000005e7a5205963583ff--