Group Email Manager

login signup
Feature request: Customize equality predicate for pattern variables Marc Nieper-Wißkirchen (05 Sep 2020 15:20 UTC)
Re: Feature request: Customize equality predicate for pattern variables Marc Nieper-Wißkirchen (13 Sep 2020 13:08 UTC)
Re: Feature request: Customize equality predicate for pattern variables Marc Nieper-Wißkirchen (13 Sep 2020 13:55 UTC)
(missing)
(missing)
Re: Feature request: Customize equality predicate for pattern variables Marc Nieper-Wißkirchen 13 Sep 2020 13:54 UTC 
The allowance of non-linear patterns is orthogonal to early binding,
so implementations are possible (and arguably preferable) that allow
non-linear patterns but bind the pattern variables only once, namely
around the body as in the original matcher and the original text of
this SRFI.

Had we a special <decl> clause as I sketched, we could declare the
"type" of a pattern variable ("type" in the sense of which equivalence
predicate). Moreover, we could add a declaration like

(special (<special identifier> <identifier>) ...)

whose meaning could be as follows: <special identifier> has to be one
of the reserved identifiers (and, or, $, quasiquote, ...) (in the
sense of free-identifier=?). In the following pattern, all special
identifiers lose their meanings but the <identifiers> are bound to the
original meaning of the corresponding <special identifier>. (This
shall work exactly like the custom ellipsis of SRFI 46.)

This allows the use of match in macros where one cannot control the
identifiers used as pattern variables or other constants.

Am So., 13. Sept. 2020 um 15:41 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:
>
>
>
> On Sun, Sep 13, 2020 at 9:08 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Felix, thanks for this suggestion. It's a good one if pattern
>> variables are bound early and in the lexical tree order of the
>> pattern.
>>
>> When they are not (and I still believe that this is the much simpler,
>> clearer, and a lot better optimizable semantics), it doesn't work,
>> though. What would you think of adding a special pattern clause that
>> declares an equivalence predicate for pattern variables? E.g. as
>> follows:
>>
> I thought the possibilities of an implementation would either be:
>
> non-linear patterns are available for a form and extended equality could be handled as above.
> non-linear patterns are not available, and extended equality would be handled in the body with failure.
>
> what is the other possibility I'm missing?
>>
>> (match (<pat> . <body>) ...)
>>
>> is replaced by
>>
>> (match (<top-pat> . <body>) ...)
>>
>> and <top-pat> is either <pat> or  (<decl> <pat>)
>>
>> where <decl> is some meta-information (extensible), which can include
>> declare equivalence predicates for certain pattern variables.
>>
>> This meta-information can also be used to restrict (or extend) the
>> number of special identifiers to make the match pattern language
>> future-proof.