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: [PATCH] Per-port read options, reader directives, SRFI-105 Date: Fri, 26 Oct 2012 23:21:14 +0200 Message-ID: <874nlh2alx.fsf@gnu.org> References: <87a9vmvh9s.fsf@tines.lan> <87mwzdzpqf.fsf@tines.lan> <87r4onwv9e.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1351286492 27234 80.91.229.3 (26 Oct 2012 21:21:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2012 21:21:32 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Oct 26 23:21:40 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 1TRrLY-0002ya-CC for guile-devel@m.gmane.org; Fri, 26 Oct 2012 23:21:40 +0200 Original-Received: from localhost ([::1]:37932 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRrLQ-0004Sk-GI for guile-devel@m.gmane.org; Fri, 26 Oct 2012 17:21:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRrLO-0004Sf-HP for guile-devel@gnu.org; Fri, 26 Oct 2012 17:21:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRrLM-0006cD-OQ for guile-devel@gnu.org; Fri, 26 Oct 2012 17:21:30 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:56352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRrLM-0006c7-E7 for guile-devel@gnu.org; Fri, 26 Oct 2012 17:21:28 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TRrLS-0002vB-5q for guile-devel@gnu.org; Fri, 26 Oct 2012 23:21:34 +0200 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2012 23:21:34 +0200 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2012 23:21:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 153 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 5 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 User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) Cancel-Lock: sha1:cAsj9XgKS96PSzK5+BX87dLSbPM= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:15051 Archived-At: Hi! Regarding SRFI-105, I’m skeptical about a couple of things. First, $bracket-apply$, $nfx$, and $bracket-list$ need to be user-defined, but implementations are allowed to provide a pre-defined version of these. This sounds like an opportunity for incompatibilities (which the document describes as a shortcoming of Guile’s infix module.) It’s also unhygienic, in the sense that programs that need it would typically have to start with a definition of $nfx$ & co., although these identifiers never appear literally in the neoteric code. Bracket lists (and $bracket-list$) are another opportunity for incompatibilities, IMO. The SRFI reads: several Scheme implementations follow the R6RS specification that accepts [...] as a synonym for (...), GNU Kawa interprets [...] as the redefinable constructor ($bracket-list$ ...) But I fail to see why R6 syntax would influence SRFI-105 syntax. That said... Mark H Weaver skribis: > From 3345a52824c2ae0e6ffe64ec7e07609d1bc362ef Mon Sep 17 00:00:00 2001 > From: Mark H Weaver > Date: Wed, 24 Oct 2012 14:50:16 -0400 > Subject: [PATCH 3/3] Implement SRFI-105 curly infix expressions. > > * libguile/private-options.h: Add SCM_CURLY_INFIX_P macro, and increment > SCM_N_READ_OPTIONS. > > * libguile/read.c (sym_nfx, sym_bracket_list, sym_bracket_apply): New > symbols. > (scm_read_opts): Add curly-infix reader option. > (scm_t_read_opts): Add curly_infix_p and neoteric_p fields. > (init_read_options): Initialize new fields. > (CHAR_IS_DELIMITER): Add '{', '}', '[', and ']' as delimiters if > curly_infix_p is set. > > (set_port_square_brackets_p, set_port_curly_infix_p): New functions. > > (scm_read_expression_1): New internal static function, which contains > the code that was previously in 'scm_read_expression'. Handle curly > braces when curly_infix_p is set. If curly_infix_p is set and > square_brackets_p is unset, follow the Kawa convention: > [...] => ($bracket-list$ ...) > > (scm_read_expression): New function body to handle neoteric > expressions where appropriate. > > (scm_read_shebang): Handle the new reader directives: '#!curly-infix' > and the non-standard '#!curly-infix-and-bracket-lists'. > > (scm_read_sexp): Handle curly infix lists. > > * module/ice-9/boot-9.scm (%cond-expand-features): Add srfi-105 feature > identifier. > > * doc/ref/srfi-modules.texi (SRFI-105): Add stub doc for SRFI-105. > > * doc/ref/api-evaluation.texi (Scheme Read): Add documentation for the > 'curly-infix' read option, and the '#!curly-infix' and > '#!curly-infix-and-bracket-lists' reader directives. > > * doc/ref/api-options.texi (Runtime Options): Add 'curly-infix' to the > list of read options. > > * test-suite/Makefile.am: Add tests/srfi-105.test. > > * test-suite/tests/srfi-105.test: New file. Besides, the patch is OK to apply for me, modulo the minor comments below. > +Guile also implements the following non-standard extension to SRFI-105: > +if @code{curly-infix} is enabled but the @code{square-brackets} read > +option is turned off, then lists within square brackets are read as > +normal lists but with the special symbol @code{$bracket-list$} added to > +the front. To enable this combination of read options within a file, > +use the reader directive @code{#!curly-infix-and-bracket-lists}. For > +example: Do you think it would be possible, or even desirable, to be able to turn off this extension? > scm_t_option scm_read_opts[] = { Can you move that brace on the next line? > @@ -98,6 +105,8 @@ struct t_read_opts { Ditto. > + /* (len == 0) case is handled above */ > + if (len == 1) > + /* Return directly to avoid re-annotating the element's source > + location with the position of the outer brace. Also, it > + might not be possible to annotate the element. */ > + return scm_car (ans); /* {e} => e */ > + else if (len == 2) > + ; /* Leave the list unchanged: {e1 e2} => (e1 e2) */ > + else if (len >= 3 && (len & 1)) > + { > + SCM op = scm_cadr (ans); Can you add a comment above this line describing what case this corresponds to? Like: This is a longer list; check whether it contains mixed infix operators, or if it’s an improper list. > +scm_read_expression_1 (SCM port, scm_t_read_opts *opts) What about calling it ‘read_inner_expression’, for instance? > -#define READ_OPTIONS_NUM_BITS 14 > +#define READ_OPTIONS_NUM_BITS 16 I think I had missed that one. Can you add a comment above to describe it? > +(define-module (test-srfi-105) > + #:use-module (test-suite lib) > + #:use-module (srfi srfi-1)) > + > +#!curly-infix > + > +(with-test-prefix "curly-infix" > + (pass-if (equal? '{n <= 5} '(<= n 5))) This is testing both the #! syntax and the actual infix parsing. Something like ‘with-read-options’ from reader.test could be used, but perhaps that’s an unnecessary complication. > + ;;(pass-if (equal? '#1=f(#1#) '#1=(f #1#))) Not implemented yet? > + ;;(pass-if (equal? '#1={a + . #1#} '($nfx$ . #1=(a + . #1#)))) Same? This sounds like a great test suite. However, could you add a few tests regarding source location tracking, by reading from a string port? Thanks! Ludo’.