Re: New rx implementation with extension constructs

[Mattias Engdegård]

Here is a revised patch after comments on and off the list (many thanks!).
There is now a section in the manual that describes the extension facility.

Although consistent and usable in its current form, there are a few points 
where I have yet to make up my mind. Perhaps you may shed some insight on the 
matters:

The rx-define, rx-let and rx-let-eval macros all essentially use the syntax

   (NAME RX-FORM)
or (NAME (ARGS...) RX-FORM)

for definining plain and parametrised rx forms, respectively.
It is very common for RX-FORM to be a sequence of rx elements. As a result, the 
majority of definitions will need an explicit (seq ...) around the definition, 
as in

(rx-define float-num (seq (+ digit) ?. (* digit)))

An alternative syntax would be the (Scheme-inspired)

  (NAME RX-FORMS...)
  ((NAME ARGS...) RX-FORMS...)

where the `seq' wouldn't be necessary, but the argument list syntax no longer 
follows Lisp tradition.
Would it be palatable? Forms with rest arguments, currently written

  (NAME (ARG1 ARG2 &rest REST-ARG) RX-FORM)

might become (Scheme again)

  ((NAME ARG1 ARG2 . REST-ARG) RX-FORMS...)

A second, orthogonal point is how rest arguments are expanded in the definition 
form. Right now, they expand as (seq ...) forms, which mostly works but not 
always:

(rx-let ((flavour (&rest choices) (or "vanilla" choices)))
  (rx (flavour "strawberry" "chocolate")))

expands to (rx (or "vanilla" (seq "strawberry" "chocolate"))) which wasn't the 
intention. It may be better to make rest arguments auto-splicing when 
substituted, which would work in all cases that I can think of.

0001-New-rx-implementation.patch
Description: Binary data