Email list hosting service & mailing list manager

Re: Lexical scope of pattern variables is not strictly respected in the sample implementation Marc Nieper-Wißkirchen (01 Sep 2020 09:14 UTC)

Re: Lexical scope of pattern variables is not strictly respected in the sample implementation Marc Nieper-Wißkirchen 01 Sep 2020 09:14 UTC

Am Di., 1. Sept. 2020 um 11:02 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Tue, Sep 1, 2020 at 5:35 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> In the specification section of SRFI 204, it says "identifiers will
>> match anything, and make the corresponding binding available in the
>> body", which I read as that the identifiers are lexically bound in an
>> extended environment, in which the body is evaluated.
>
>
> Except that identifiers may be referred to multiple times,
> with subsequent references tested for equality against the
> first match.

That's true, but that's part of the pattern language and does not mean
that some environment is extended (which is only meaningful for
subsequent evaluation of expression forms).

>> The sample implementation, however, fails to respect the correct
>> lexical scoping in some cases:
>>
>> (match '1 ((and odd (? odd)) odd))
>
>
> If the example were
>
>   (match '1 ((and odd odd) odd))
>
> we would expect it to evaluate to 1.  Unless we want to single out
> the arguments to ?, then your example must be an error.

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. The `(and odd odd)`
example is how a certain pattern is interpreted by the matcher. That's
uncontroversial and covered in the spec.

Of course, one can write the spec so that (match '1 ((and odd (? odd))
odd)) does not evaluate to 1 but is an error, but currently, the spec
isn't written in this way. (I don't want to suggest this; it would
make the semantics complicated and would introduce an unnecessary
incompatibility to other comparable matchers like Racket's one. It's
much better to update SRFI 204's sample implementation to what the
document currently says.)