From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: Srfi-159/166 - monadic formatting for guile Date: Tue, 11 Jun 2019 18:01:27 -0400 Message-ID: <87pnnj7pd9.fsf@netris.org> References: 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="102607"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: guile-user@gnu.org To: Linus =?utf-8?Q?Bj=C3=B6rnstam?= Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jun 12 00:16:21 2019 Return-path: Envelope-to: guile-user@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 1hap3z-000QYm-Ne for guile-user@m.gmane.org; Wed, 12 Jun 2019 00:16:19 +0200 Original-Received: from localhost ([::1]:55612 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hap3w-0002FV-Sr for guile-user@m.gmane.org; Tue, 11 Jun 2019 18:16:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43634) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hap1Q-0000qu-Kz for guile-user@gnu.org; Tue, 11 Jun 2019 18:13:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1haorp-00007t-Tb for guile-user@gnu.org; Tue, 11 Jun 2019 18:03:48 -0400 Original-Received: from world.peace.net ([64.112.178.59]:42828) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1haorp-000074-Py for guile-user@gnu.org; Tue, 11 Jun 2019 18:03:45 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1haorn-00016l-4w; Tue, 11 Jun 2019 18:03:43 -0400 In-Reply-To: ("Linus \=\?utf-8\?Q\?Bj\=C3\=B6rnstam\=22's\?\= message of "Sun, 02 Jun 2019 15:38:50 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15546 Archived-At: Hi Linus, Linus Bj=C3=B6rnstam writes: > I just ported the reference implementation of SRFI-159/166 (166 being > the successor of 159) from the reference implementation in chibi > scheme. The srfi document is here: > https://srfi.schemers.org/srfi-166/srfi-166.html > > SRFI-166 is like (ice-9 format) on steroids, drenched in molasses. It > can do a lot more than (ice-9 format), but about 3x slower. I haven't > started trying to make it fast just yet, but there are some low > hanging fruit (like speeding up simple cases). I will wait with > optimization until the srfi is finalized (and also maybe hear with > Alex what he has in mind before trying to half-ass it myself). > > Anyway, the repo is here: https://bitbucket.org/bjoli/guile-srfi-159 > . I haven't ported the tests, but playing with it in guile and chibi > scheme produces the same result. Tests are up, but I'm travelling > without computer the next week, so there is no time. I would be in favor of integrating this into Guile at some point, although first I would like to make a careful review of the implementation to make sure that it integrates well with Guile's related mechanisms, e.g. custom record printers, printer options, and print states, and that it supports all Guile data types. In particular, I remember finding it difficult to properly implement cycle detection while supporting Guile's existing mechanisms. I'm not sure it can be done without modifying Guile's built-in printer. I'll also want to take a close look at the numeric formatter, to make sure that it achieves the same properties as our built-in printer, e.g. that it prints inexacts with the minimal number of digits required to ensure that the same number will be read back in (unless specifically asked to limit the precision). Anyway, thanks very much for sharing this! Regards, Mark