From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Improving the API for read options Date: Tue, 06 Nov 2012 20:01:28 +0100 Message-ID: <87zk2usghj.fsf@gnu.org> References: <1352073544-24166-1-git-send-email-a.rottmann@gmx.at> <87objceixe.fsf@tines.lan> <87625kuec5.fsf@gnu.org> <87y5ifb2tw.fsf_-_@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1352228518 18140 80.91.229.3 (6 Nov 2012 19:01:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Nov 2012 19:01:58 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Nov 06 20:02:04 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TVoPS-00019u-UP for guile-devel@m.gmane.org; Tue, 06 Nov 2012 20:02:03 +0100 Original-Received: from localhost ([::1]:60781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVoPK-00016k-0G for guile-devel@m.gmane.org; Tue, 06 Nov 2012 14:01:54 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVoPD-00016U-S6 for guile-devel@gnu.org; Tue, 06 Nov 2012 14:01:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TVoP7-0004CQ-Nw for guile-devel@gnu.org; Tue, 06 Nov 2012 14:01:47 -0500 Original-Received: from [2a01:e0b:1:123:ca0a:a9ff:fe03:271e] (port=47831 helo=xanadu.aquilenet.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVoP7-00049q-FU for guile-devel@gnu.org; Tue, 06 Nov 2012 14:01:41 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by xanadu.aquilenet.fr (Postfix) with ESMTP id C851DA80F; Tue, 6 Nov 2012 20:01:29 +0100 (CET) Original-Received: from xanadu.aquilenet.fr ([127.0.0.1]) by localhost (xanadu.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6PnZu2Gvhtz; Tue, 6 Nov 2012 20:01:29 +0100 (CET) Original-Received: from pluto (reverse-83.fdn.fr [80.67.176.83]) by xanadu.aquilenet.fr (Postfix) with ESMTPSA id 05F91A80E; Tue, 6 Nov 2012 20:01:28 +0100 (CET) X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 16 Brumaire an 221 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87y5ifb2tw.fsf_-_@tines.lan> (Mark H. Weaver's message of "Tue, 06 Nov 2012 02:36:11 -0500") User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2a01:e0b:1:123:ca0a:a9ff:fe03:271e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15114 Archived-At: Mark H Weaver skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: >>> I've been avoiding adding a public API for this, because I feel that the >>> current 'read-options' API is poorly-designed and I'd rather take the >>> opportunity to come up with a clean design. >> >> What about just mapping the existing =E2=80=98read-options=E2=80=99 to s= omething like: >> >> (set-port-read-options! PORT OPTIONS) >> >> where OPTIONS would be a list of symbols, as for =E2=80=98read-options= =E2=80=99? This >> seems to me like the obvious API extension, but maybe I=E2=80=99m overlo= oking >> something. [...] > One problem I have with the existing API has to do with its treatment of > square brackets. There are multiple things that one might want to do > with square brackets, but since 'square-brackets' is a boolean option, For that particular problem, I=E2=80=99d propose: (set-port-read-options! PORT OPTIONS) but with OPTIONS being an list of option/value pairs, or: (set-port-read-option! PORT OPTION VALUE) where OPTION is a symbol. Nothing fancy, but that should do the job while being reasonably future-proof, no? [...] > I haven't yet had time to think this through, but my gut instinct is > that I would prefer an API closer to this: > > * We provide an opaque type 'read-options' which we reserve the right to > change at any time, and a set of predefined read-options objects such > as 'inherit-all-read-options', 'guile-default-read-options', > 'r6rs-read-options', etc. > > * We provide procedures to set! and retrieve the read-options object > to/from a port, and perhaps to/from a global setting. We might also > provide a parameter. > > * For each user-visible (high-level) read option, we provide a set of > predicates and mutators for 'read-options' objects. > > * We provide a way to explicitly pass a 'read-options' object to the > reader. > > * We define the order in which the 'read-options' objects are checked, > e.g. first from the explicit parameter (if any), then the per-port > options, then the fluid (if we add one), then the globals. > > * We provide a way for user-defined token readers to accept the > 'read-options' object from the reader, so that it can be propagated > properly to subordinate readers. > > * We need to think about whether (and how) to expose inheritance to the > user. We might want to provide ways to reset an option to "inherit" > mode and to test whether an option is in "inherit" mode. However, in > other contexts the user may just want to know about the applicable > option. > > This kind of API would give us more freedom to enhance and generalize > the reader in the future, while providing an easy-to-use and stable API > that users can rely upon. Right. However, it seems to be addressing a lot more problems (more like Guile-Reader) than what we were initially discussing, which is to provide a way for users to set per-port options. I was really hoping that a dumb solution as I proposed would be enough. :-) WDYT? (Regarding reader extensibility, I=E2=80=99ve become dubious about the whole idea of reusable and composable token readers. I think readers should rather be generated from SILex-style declarations, and we could have several of them pre-generated. And the =E2=80=98scm_t_read=C2=A0opts=E2=80= =99 may not scale well in terms of cyclomatic complexity.) Thanks, Ludo=E2=80=99.