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: [PATCH] Implement SRFI-105 curly infix expressions. Date: Thu, 18 Oct 2012 17:09:44 -0400 Message-ID: <87d30fpjvr.fsf@tines.lan> References: <87hapxxvhv.fsf@tines.lan> <87y5j6xvbm.fsf@gnu.org> <87ipaatanh.fsf@tines.lan> <87txtrydg2.fsf@gnu.org> 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 1350594622 23258 80.91.229.3 (18 Oct 2012 21:10:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Oct 2012 21:10:22 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Oct 18 23:10:30 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 1TOxML-0006ve-3Z for guile-devel@m.gmane.org; Thu, 18 Oct 2012 23:10:29 +0200 Original-Received: from localhost ([::1]:53890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOxMD-0003i9-Ku for guile-devel@m.gmane.org; Thu, 18 Oct 2012 17:10:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOxM9-0003ht-Vv for guile-devel@gnu.org; Thu, 18 Oct 2012 17:10:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOxM7-0005bC-Ic for guile-devel@gnu.org; Thu, 18 Oct 2012 17:10:17 -0400 Original-Received: from world.peace.net ([96.39.62.75]:32946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOxM7-0005Y1-Et; Thu, 18 Oct 2012 17:10:15 -0400 Original-Received: from turntable.mit.edu ([18.160.0.29] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TOxLv-0003XV-3G; Thu, 18 Oct 2012 17:10:03 -0400 In-Reply-To: <87txtrydg2.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 18 Oct 2012 18:03:57 +0200") 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 (newer, 3) 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:15005 Archived-At: ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> ludo@gnu.org (Ludovic Court=C3=A8s) writes: >>> My understanding was that the sweet-expressions folks already had >>> something, no? >> >> The implementation they have (which they call a "demo") reimplements the >> entire reader from scratch. There are several problems with this, the >> worst of which is that it strongly discourages anyone from using the >> syntax in code that they'd like to deploy. You can't simply publish a >> module with '#!curly-infix' at the top and have people use it. You have >> to ask them to install the sweet-expressions implementation first, and >> then ask them to somehow arrange for your code to be read using the >> special reader. > > Would it help if it were distributed as part of Guile? That=E2=80=99s so= mething > we could do when the implementation is considered reasonably stable. That wouldn't work, because #!curly-infix (like any other reader directive) can appear anywhere that comments are permitted, at any depth within an s-expr, and must affect all tokens that follow until the end of the file. Even if we somehow figured out a way around that problem, the other problem is that it would require us to maintain two almost identical readers that implement all of the functionality our reader supports (e.g. arrays, source properties, read-hash-extend, all of our other read options, etc), and keep these two implementations in sync with each other. Regards, Mark