From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Precedence for reader extensions Date: Thu, 21 Feb 2013 21:52:47 -0500 Message-ID: <87k3q183gg.fsf@tines.lan> References: <87mwv1nqns.fsf@tines.lan> <87a9r0gvld.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 1361501612 17271 80.91.229.3 (22 Feb 2013 02:53:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2013 02:53:32 +0000 (UTC) Cc: guile-devel To: mikael@djurfeldt.com Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Feb 22 03:53:54 2013 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 1U8ilm-0006jq-1W for guile-devel@m.gmane.org; Fri, 22 Feb 2013 03:53:54 +0100 Original-Received: from localhost ([::1]:47737 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8ilR-0006rn-OO for guile-devel@m.gmane.org; Thu, 21 Feb 2013 21:53:33 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8ilA-0006qn-SA for guile-devel@gnu.org; Thu, 21 Feb 2013 21:53:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8il2-0001sA-Lc for guile-devel@gnu.org; Thu, 21 Feb 2013 21:53:16 -0500 Original-Received: from world.peace.net ([96.39.62.75]:56227) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8il2-0001rk-Ej for guile-devel@gnu.org; Thu, 21 Feb 2013 21:53:08 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U8ikt-0005DZ-M8; Thu, 21 Feb 2013 21:52:59 -0500 In-Reply-To: (Mikael Djurfeldt's message of "Tue, 19 Feb 2013 17:58:14 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:15796 Archived-At: Mikael Djurfeldt writes: > The API you suggest would compose much easier, but to me it feels like > just another specialized solution. What we would really need is > something like Ludovic's guile-reader. I agree that we should ideally have a much more general way of defining customized readers. In the meantime, my primary concern is to find a solution to your problem without committing us to supporting an overly general mechanism that fails to provide basic guarantees to other users of 'read'. As you pointed out, the current code *almost* supports overriding standard syntax for things like "#!". However, it has been broken for a long time. The same bug is in Guile 1.8, and I haven't seen anyone complaining about it. Therefore, I'm more inclined to remove this broken functionality than to fix it. Mikael Djurfeldt writes: > But I won't be stubborn regarding this. If someone else wants to > implement another way of supporting #!optional and #!rest that is fine > by me. Thanks. I hope to cook up a patch in the next few days. Ludovic Court=C3=A8s writes: > This is basically DSSSL keyword syntax. What about adding a new keyword > style to read.c? Sounds like the easiest solution for this particular > problem. This is a tempting solution, but I see a problem with this proposal: We'd have to make exceptions for things like #!fold-case and #!curly-infix, as well as for things like #!/usr/bin/guile. Also, it could potentially turn existing scsh-style block comments into syntax errors. Ludovic Court=C3=A8s writes: > In general, I think it should be easy to create new readers that derive > from the standard syntax without having to write them from scratch. >=20 > However, in hindsight, I=E2=80=99m not sure Guile-Reader=E2=80=99s API is= the right > approach. It=E2=80=99s an improvement, because it addresses this need; b= ut its > API is not ideal: =E2=80=9Ctoken readers=E2=80=9D with different delimite= r syntax don=E2=80=99t > compose well, for instance. I'd be very interested to hear your current thoughts on what a better API should look like. Regards, Mark