Re: [PATCH] Implement SRFI-105 curly infix expressions.

[Ludovic Courtès]

Hi,

Mark H Weaver m...@netris.org skribis:

 l...@gnu.org (Ludovic Courtès) 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’s something
we could do when the implementation is considered reasonably stable.

Then the current read.c would just need to be extended to dispatch the
#! thing.

WDYT?

(I have nothing against your approach either, but I like the idea of
less work for us, and less C.  ;-))

Thanks,
Ludo’.

Re: [PATCH] Implement SRFI-105 curly infix expressions.

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

 Mark H Weaver m...@netris.org skribis:

 l...@gnu.org (Ludovic Courtès) 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’s something
 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

Re: [PATCH] Implement SRFI-105 curly infix expressions.

[Ludovic Courtès]

Hi!

My understanding was that the sweet-expressions folks already had
something, no?

And there as also this preliminary patch:

  http://lists.gnu.org/archive/html/guile-devel/2012-03/msg00129.html

What about applying first, then one above, then anything beyond?

Ludo’.

Re: [PATCH] Implement SRFI-105 curly infix expressions.

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) 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.

 And there as also this preliminary patch:

   http://lists.gnu.org/archive/html/guile-devel/2012-03/msg00129.html

 What about applying first, then one above, then anything beyond?

With respect to nalaginrut, that patch was only the beginning, and was
never turned into a full implementation.  I have a fully-functional
patch that implements the full spec, complete with documentation, test
suite, and everything needed to enable people to easily use and deploy
curly-infix in their programs.

 Mark

[PATCH] Implement SRFI-105 curly infix expressions.

[Mark H Weaver]

Hello all,

Here's a patch to implement curly infix expressions in Guile's core
reader, based on the current draft of SRFI-105.  It depends upon the
per-port reader options patches that I posted here a few minutes ago.

With this patch, although curly-infix expressions are not enabled by
default, they will be automatically enabled on a per-port basis when
'read' encounters the #!curly-infix reader directive.  They can also
be enabled globally by enabling the 'curly-infix' reader option.

David: if you would be willing to produce a set of SRFI-105 expressions
(along with their s-expression equivalents) to add to our test suite,
that would be very helpful.

It's probably not appropriate to commit this patch before SRFI-105 has
been finalized, but in the meantime here's a (hopefully) complete patch
set for your enjoyment.

Comments and suggestions solicited,

  Mark


From 57a4ae1eb7f58103574525c7e727ff08d44f18ec Mon Sep 17 00:00:00 2001
From: Mark H Weaver m...@netris.org
Date: Sun, 14 Oct 2012 04:09:01 -0400
Subject: [PATCH] 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 (scm_read_opts): Add curly-infix reader option.
  (scm_t_read_opts): Add curly_infix_p field.
  (init_read_options): Initialize new curly_infix_p field.
  (CHAR_IS_DELIMITER): Add '{' and '}' as delimiters if curly_infix_p
  is set.

  (set_per_port_curly_infix_p): New internal static function.

  (scm_read_shebang): Handle '#!curly-infix' reader directive.

  (scm_read, scm_read_keyword, scm_read_vector, scm_read_bytevector):
  Pass new 'neoteric_p' argument to subroutines where needed.

  (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.  Pass new 'neoteric_p' argument to
  subroutines where needed.

  (scm_read_expression): Add 'neoteric_p' argument.  New function body
  to handle neoteric expressions where appropriate.

  (scm_read_sexp): Add 'neoteric_p' argument.  Handle curly infix
  expressions, converting them to normal s-expressions.

  (flush_ws, scm_read_commented_expression, scm_read_sharp,
  scm_read_quote, scm_read_syntax): Add 'neoteric_p' argument.
  Pass new 'neoteric_p' argument to subroutines where needed.

* 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' reader directive.

* 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.
---
 doc/ref/api-evaluation.texi|   10 +-
 doc/ref/api-options.texi   |1 +
 doc/ref/srfi-modules.texi  |   14 +++
 libguile/private-options.h |3 +-
 libguile/read.c|  212 
 test-suite/Makefile.am |1 +
 test-suite/tests/srfi-105.test |   67 +
 7 files changed, 260 insertions(+), 48 deletions(-)
 create mode 100644 test-suite/tests/srfi-105.test

diff --git a/doc/ref/api-evaluation.texi b/doc/ref/api-evaluation.texi
index 9eccb39..245d4e0 100644
--- a/doc/ref/api-evaluation.texi
+++ b/doc/ref/api-evaluation.texi
@@ -338,13 +338,15 @@ r6rs-hex-escapes  noUse R6RS variable-length character and string hex escape
 square-brackets   yes   Treat `[' and `]' as parentheses, for R6RS compatibility.
 hungry-eol-escapes no   In strings, consume leading whitespace after an
 escaped end-of-line.
+curly-infix   noSupport SRFI-105 curly infix expressions.
 @end smalllisp
 
 Note that Guile also includes a preliminary mechanism for overriding
-read options on a per-port basis.  Currently, the only read option that
-is overridden in this way is the @code{case-insensitive} option, which
-is set or unset when the reader encounters the special directives
-@code{#!fold-case} or @code{#!no-fold-case}.  There is currently no
+read options on a per-port basis.  The only read options that can
+currently be overridden in this way are the @code{case-insensitive} and
+@code{curly-infix} options, which are set (or unset) when the reader
+encounters the special directives @code{#!fold-case},
+@code{#!no-fold-case}, or @code{#!curly-infix}.  There is currently no
 other way to access or set these per-port read options.
 
 The boolean options may be toggled with @code{read-enable} and
diff --git a/doc/ref/api-options.texi b/doc/ref/api-options.texi
index f635978..1734318 100644
--- a/doc/ref/api-options.texi
+++ b/doc/ref/api-options.texi
@@ -390,6 +390,7 @@ r6rs-hex-escapes  noUse R6RS variable-length character and string hex escape
 square-brackets   yes   Treat `[' and `]' as parentheses, for R6RS compatibility.
 hungry-eol-escapes no   In strings, consume leading

Re: [PATCH] Implement SRFI-105 curly infix expressions

[Mark H Weaver]

Hello all,

Here's an improved version of the SRFI-105 patch for Guile 2.0.  It
incorporates the recent name change 'nfx' -- '$nfx$', has an improved
test suite, and now correctly handles the case where 'curly-infix' is
enabled but the 'square-brackets' read option is disabled.

This patch assumes that the following patch set (per-port read options
and reader directives) has already been applied:

  http://lists.gnu.org/archive/html/guile-devel/2012-10/msg00056.html

Note that in the interests of backward compatibility, SRFI-105 syntax is
enabled by default, since '{' and '}' are currently considered extended
alphabetic characters.  It must first be enabled in one of two ways:

* On a per-port basis, when the reader encounters the #!curly-infix
  reader directive, e.g. near the top of source files.

* Globally, by evaluating: (read-enable 'curly-infix)

Reviews solicited.

   Thanks,
 Mark


From 4102fbbd852d2f36e13f0c7f10dbac2017552bff Mon Sep 17 00:00:00 2001
From: Mark H Weaver m...@netris.org
Date: Sun, 14 Oct 2012 04:09:01 -0400
Subject: [PATCH] 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 (scm_read_opts): Add curly-infix reader option.
  (scm_t_read_opts): Add curly_infix_p field.
  (init_read_options): Initialize new curly_infix_p field.
  (CHAR_IS_DELIMITER): Add '{', '}', '[', and ']' as delimiters if
  curly_infix_p is set.

  (set_per_port_curly_infix_p): New internal static function.

  (scm_read_shebang): Handle '#!curly-infix' reader directive.

  (scm_read, scm_read_keyword, scm_read_vector, scm_read_bytevector):
  Pass new 'neoteric_p' argument to subroutines where needed.

  (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.  Pass new 'neoteric_p' argument to
  subroutines where needed.

  (scm_read_expression): Add 'neoteric_p' argument.  New function body
  to handle neoteric expressions where appropriate.

  (scm_read_sexp): Add 'neoteric_p' argument.  Handle curly infix
  expressions, converting them to normal s-expressions.

  (flush_ws, scm_read_commented_expression, scm_read_sharp,
  scm_read_quote, scm_read_syntax): Add 'neoteric_p' argument.
  Pass new 'neoteric_p' argument to subroutines where needed.

* 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' reader directive.

* 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.
---
 doc/ref/api-evaluation.texi|   10 +-
 doc/ref/api-options.texi   |1 +
 doc/ref/srfi-modules.texi  |   14 +++
 libguile/private-options.h |3 +-
 libguile/read.c|  231 +++-
 test-suite/Makefile.am |1 +
 test-suite/tests/srfi-105.test |   76 +
 7 files changed, 282 insertions(+), 54 deletions(-)
 create mode 100644 test-suite/tests/srfi-105.test

diff --git a/doc/ref/api-evaluation.texi b/doc/ref/api-evaluation.texi
index 9eccb39..245d4e0 100644
--- a/doc/ref/api-evaluation.texi
+++ b/doc/ref/api-evaluation.texi
@@ -338,13 +338,15 @@ r6rs-hex-escapes  noUse R6RS variable-length character and string hex escape
 square-brackets   yes   Treat `[' and `]' as parentheses, for R6RS compatibility.
 hungry-eol-escapes no   In strings, consume leading whitespace after an
 escaped end-of-line.
+curly-infix   noSupport SRFI-105 curly infix expressions.
 @end smalllisp
 
 Note that Guile also includes a preliminary mechanism for overriding
-read options on a per-port basis.  Currently, the only read option that
-is overridden in this way is the @code{case-insensitive} option, which
-is set or unset when the reader encounters the special directives
-@code{#!fold-case} or @code{#!no-fold-case}.  There is currently no
+read options on a per-port basis.  The only read options that can
+currently be overridden in this way are the @code{case-insensitive} and
+@code{curly-infix} options, which are set (or unset) when the reader
+encounters the special directives @code{#!fold-case},
+@code{#!no-fold-case}, or @code{#!curly-infix}.  There is currently no
 other way to access or set these per-port read options.
 
 The boolean options may be toggled with @code{read-enable} and
diff --git a/doc/ref/api-options.texi b/doc/ref/api-options.texi
index f635978..1734318 100644
--- a/doc/ref/api-options.texi
+++ b/doc/ref/api-options.texi
@@ -390,6 +390,7 @@ r6rs-hex-escapes  noUse R6RS variable-length character and string hex escape
 square-brackets   yes   Treat `[' and `]' as parentheses, for R6RS compatibility.
 hungry-eol-escapes