[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: benefits of SRE syntax

This page is part of the web mail archives of SRFI 115 from before July 7th, 2015. The new archives for SRFI 115 contain all messages, not just those from before July 7th, 2015.

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
per@xxxxxxxxxxx   http://per.bothner.com/