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/