On 10/16/2013 11:44 AM, Michael Montague wrote:
> Maybe I am being a heretic, but what are the benefits of the SRE syntax?

I think structured regular expressions make sense when integrated
with a general pattern-matching framework (by which I mean something
like http://docs.racket-lang.org/reference/match.html). Also,
sub-matches should produce variable bindings.

Without that, I also see little value is yet another ad hoc
string-only pattern-matching syntax, which is likely to
be have different syntax from any general pattern-matching framework.
I have no problem with it as a SRFI, but I think it would be a
mistake for RnRS.

FWIW I'm working on a general pattern-matching framework for Kawa,
where variables in definitions are generalized to patterns.  I'm
focusing on the implementation framework for now, rather than
syntax or specific pattern operators.  However, the following work in
my prototype:

(let (([a::integer b] (vector 3 4))) (list b a))
  ==> (4 3)

(let (([a::pair b] (vector 3 4))) (list b a))
  ==> EXCEPTION: Value '3' for variable 'a' has wrong type (integer)
(gnu.math.IntNum cannot be cast to gnu.lists.Pair)

Here [a b] matches a 2-element list, where VAR::TYPE is a declaration
with a type-specifier.  In non-pattern (expression) context [a b c]
is equivalent to `#(,a ,b ,c) which is like (vector a b c) except
creating an immutable vector.  So using [pattern...] to test out
patterns made sense, since I could put off deciding on the meaning
of lists in patterns.  (The issue is whether the first element
is a sub-pattern, as in syntax-rules, or a "pattern operator", as in
Racket patterns.)
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/