Thanks for exhibiting this. This is actually a good example of why I
wouldn't recommend this feature yet. The comparison works using
equal?. That is fine if a single register is represented by a symbol
(but then the comparison should have really used for eq? for speed or,
possibly, symbol=?) or by a list (containing Scheme datums). However,
as during some code refactoring it is decided that registers are
better (and more abstractly) represented by records, the code below
will break because the abstraction is broken.

The following rewrite of the clause

[('xor (? register32+? xreg1) xreg2)
 (=> failure) (unless (register=? xreg1 xreg2) (failure))
 ...]

does not suffer from the problem. (Had SRFI 204 a guard clause as the
"FHD" matcher from SRFI 200, it would look a bit nicer:)

[('xor (? register32+? xreg1) xreg2)
 (guard (register=? xreg1 xreg2))
 ...]

In any case, making the feature optional for the time being wouldn't
cause many difficulties. If Loko switched its current matcher to a
general SRFI 204 one that didn't provide this feature, it would show
an error during expansion time so that the code could easily be
adapted.

Marc

Am Di., 8. Sept. 2020 um 05:06 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:
>
> So far, I've come across this pattern:
>
>          ;; 20314B: 33C9                           (xor ecx ecx)
>          ;; 20314D: 488B440807                     (mov rax (mem64+ rax #x7 (* rcx #x1)))
>          ([('xor (? register32+? xreg) xreg)
>            (op dst ('mem64+ memargs ...))
>            . _]
>           ;; This and the next are poor man's CSE or something
>           (and (references-register? memargs xreg)
>                (list #b11
>                      a
>                      `(,op ,dst (mem64+ ,@(replace-register memargs xreg 0))))))
>
> in the middle of the analyzer code for loko at : https://gitlab.com/weinholt/loko/-/blob/master/arch/amd64/analyzer.sls
>
> so that's at least one person using non-linear patterns in production.
>
>
> On Mon, Sep 7, 2020 at 9:25 AM Alex Shinn <xxxxxx@gmail.com> wrote:
>>
>> On Mon, Sep 7, 2020 at 6:36 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>>
>>> >
>>> > Optional features still need to be specified, that doesn't really help you.
>>>
>>> What I mean is that if it is an optional feature, it still leaves some
>>> room for experimentation. It doesn't feel like there has been enough
>>> experimentation/discussion going on so that duplicate pattern
>>> variables suggest themselves for mandatory standardization. Are there
>>> any real-life use cases where they are really needed?
>>
>>
>> If I recall correctly, I added it only because someone said it couldn't be done with syntax-rules :)
>>
>>>
>>> > With that restriction, no double ellipsis', and clarifying that side-effects
>>> > in ? preds and = accessors are errors, the matching is deterministic.
>>> > I don't think there is any need to specify order (except for `or' clauses,
>>> > where order also matters for Wright's original match).
>>>
>>> When the lexical environment where `pred` is evaluated depends on
>>> which matchings have already taken place, an order has to specified.
>>
>>
>> The scope rules have to be specified, though this still doesn't imply
>> a matching order.  A simple way to side-step this whole issue is to
>> make it an error for a predicate expr to refer to a pattern variable.
>> In practice, no one will want or need this anyway - 99% of predicates
>> will be `number?' or `string?', etc.
>>
>>>
>>> But I still think that this change from Wright's matcher is a mistake.
>>> Not only but also for performance reasons: an implementation should be
>>> possible that binds all pattern variables in one single `let` around
>>> the body.
>>
>>
>> That's a weak argument.  It ignores the Macro Writer's Bill of Rights.
>> Even if the sample impl didn't optimize away naturally with a good
>> compiler, the case you're worried about here will never happen in
>> practice, and it's easy to provide a fast path for the common case.
>>
>> We shouldn't be in the business of specifying things based on the
>> assumption that "let is slow."
>>
>> --
>> Alex
>>