Am Di., 1. Sept. 2020 um 15:25 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Tue, Sep 1, 2020 at 6:14 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>>
>> I don't understand your reasoning. The first argument to ? is not a
>> pattern and does not contain patterns or pattern variables (in the
>> sense of the grammar) but is just an expression. The question is: In
>> which environment is this expression evaluated.
>
>
> We could specify it either way.  I think in the same environment as
> the pattern variables is more natural and more consistent with the
> extension to non-linear patterns.  It's also strictly more expressive -
> you can write predicates which refer to previously matched variables.

We can specify it the way your implementation works, but then we
should stop calling it a superset of the Wright matcher.

But there are a number of reasons not to change the spec but to
correct the implementation:

(1) We lose compatibility with the original Wright matcher and other
descendants like Racket's.
(2) The Wright matcher has clear semantics. The semantics currently
implemented by your match is hardly that clear. For example, in a list
pattern that contains a predicate, the pattern variables on the left
will be available, but not those on the right. This way, for example,
you enforce a matching order, which is not present in the original
matcher and has nothing to do with the original list matching problem.
(3) The proposed new semantics is complicated even more by the
presence of ellipsis patterns. If a predicate is inside a pattern,
which is followed by ellipses, the variables on the left of the
predicate but inside the repeated pattern cannot be available to the
predicate. In particular <pat> would suddenly be interpreted
differently to <pat> =.. 1.
(4) The question really has nothing to do with non-linear patterns.
When you write down a formal specification in the sense of the R7RS,
you won't talk about lexical environments, bindings, and locations
when specifying repeated pattern variables.
(5) Writing a formal specification becomes harder.
(6) It is, in principle, not hard to write a correct matcher.

> So I would prefer to clarify the spec to match the impl here, rather
> than the other way around.

While I understand that you may be too busy to correct the
implementation to follow Wright's specification (and SRFI 204 in its
current state), someone else will hopefully volunteer. Having a spec
that is dictated by a momentary lack of a compliant implementation is
never a good idea, I think.

Marc