From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: guile 3 update, halloween edition Date: Wed, 30 Oct 2019 21:13:49 +0100 Message-ID: <87o8xyhtz6.fsf@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="176337"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Oct 30 21:55:46 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 1iPv0L-000jkG-H6 for guile-devel@m.gmane.org; Wed, 30 Oct 2019 21:55:45 +0100 Original-Received: from localhost ([::1]:44314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPv0J-0005El-Mu for guile-devel@m.gmane.org; Wed, 30 Oct 2019 16:55:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49816) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPuMG-0007zD-NI for guile-devel@gnu.org; Wed, 30 Oct 2019 16:14:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iPuME-00072Q-S5 for guile-devel@gnu.org; Wed, 30 Oct 2019 16:14:20 -0400 Original-Received: from fanzine.igalia.com ([178.60.130.6]:40170) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iPuMD-00070h-5G for guile-devel@gnu.org; Wed, 30 Oct 2019 16:14:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=Qd83wVwJQNDGlUVnj8hQ5vNheFC5hF3WDzMQ4GSoM8s=; b=auDCdyoj2XjeQSJhza8APZLGFaiFVTlaa7ecTD9cWIVhKfi3YvYw7DSC/eiCLE2OuMDOh5ZbZhGYe0JPt9vIk59x3RdaoWUqu6jUVi7FXc9pYrOp15fkGSYI7el4u1/MacqC7voFQd6fwzeEykxWuZPbW364w0rFETm2A095SVAvlqhizN4p9oqZqAaLrjdQU1wiKe8xHW5WSIVsvqF+PkdL6pjEBTDKGMBJsuDqibgEwY6BSd3nm2z9RKKuJxvTR3CdNI9aygf1p6NsAS2bcBBuVKgsvv+3jH3+/UGgAQBQ6xwR9jdfzR7lu28jfYK0yuD3VWrca+5/ppCu3fx05w==; Original-Received: from cha74-2-88-160-189-213.fbx.proxad.net ([88.160.189.213] helo=sparrow) by fanzine.igalia.com with esmtpsa (Cipher TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim) id 1iPuM8-0000Op-PY for ; Wed, 30 Oct 2019 21:14:12 +0100 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 178.60.130.6 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:20128 Archived-At: 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