On 18 May 2025, at 02:01, John Cowan <[email protected]> wrote: > Here's what I see: > > 1. In the summary, why dose quasi pat not allow backquote?
I think it’s implied already, but agree this should be explicit (especially if I adopt the ‘right’ nested quasiquote semantics, which I think I will). Will fix for the next draft. > 5. Issues: I’m not 100% sure which number refers to which issue here (perhaps I should use <ol> and not <ul> for this in future), so in the manner of an interactive fiction engine, I’ll explain what I’m assuming in interpreting your comments. > Issue 1: I think match-next is sufficient. I also think non-tail positions > should not require a warning, for the sake of implementations in which > continuation marks are expensive. Hmm, a ‘should’ on warning for non-tail uses would indeed be possible and an elegant solution to that issue. I also like the names next-match or match-next. I am also thinking about ML-style pattern guards as a solution to this issue. That would not give you a means of early exit from the actual body of each clause, but would let you use arbitrary Scheme code over any variables in the pattern to exclude a clause which would otherwise match. However, I’m also increasingly thinking that this feature should be left out of the initial version of this SRFI entirely. ML got on perfectly well with no pattern guards for decades (they are in SuccessorML but not Standard ML) and early exit from a pattern match clause is still not part of either ML nor Haskell. A subsequent SRFI could add this as an extension. My only concern is that pattern guards or early clause exit are a practical alternative to non-linear patterns and without them, there is no way to simulate non-linear variable matches. > Issue 2: Please explainwhy this would be good. (Assuming you mean a non-ordered ‘and’ outside of ? patterns.) At present, any optimizing implementation would have a general concept of a pattern that means ‘all these subpatterns must match the same subject, and they may be tested in any order’. But the only way to access this functionality that doesn’t involve prioritizing one particular procedure call is a separate match-values. I can’t imagine a case where this would be needed in practice, but it just feels like an anomaly that this is not available directly as a primitive. > Issue 4: Yes. (Assuming you mean whether the pattern matcher should be allowed to eliminate procedure calls which can neither refute a pattern nor cause a variable to be bound.) There are two yes-or-no questions in that issue – do you mean yes to the first one or to the second one? > Issue 5: I read the whole Emacs thread, and it's mostly about not breaking > backward compatibility, which is not really an issue for us. The Shin > approach makes nested backquote patterns the same as ordinary backquotes, > which seems like a win. Yes, on reflection, I agree. I’ll change this in the next draft. > Issue 6: I don't know either. > > Issue 7:I don't follow this. > > Issue 8: > > Issue 9: I don't follow this either. > > Issue 10: I don't know. Here I’m no longer sure which number corresponds to which issue. I’m assuming that one of the ‘I don’t follow’s refers to the semantics of lset and seq/unordered. Consider the pattern (lset (cons 'a newest-a) (cons 'a older-a) _ ...). Newest-a should be bound to the cdr of the most recent association with the key ‘a’ in the input association list, and older-a to the cdr of the next oldest. So the result depends on the input order in the sequence and the order of subpatterns within the lset pattern. I feel I understand the correct thing intuitively but find it hard to formulate into a specification. > 6. Maybe else is better than underscore? When the pattern consists only of a wildcard, maybe, but as a subpattern this looks weird: (match x ((cons 'some-key else) 'found-the-key)) Moreover, underscore is the same as in syntax-case, syntax-rules, as well as Haskell and ML — and the same issue with ‘else’ is present in Wright/Shinn and in Racket’s pattern matching library (and the documentation of those has to warn about the issue as well). I feel precedent speaks strongly for keeping the underscore. That said, I might add the ability for match-values and match-lambda to have ‘else’ clauses which take any number of values/arguments. > 7. Sentences that begin with identifiers should be rewritten not to, so that > there are no capitalized identifiers. Arthur, can you comment on this stylistic matter, as SRFI editor? Capitalized identifiers at the start of sentences are used consistently in the Scheme reports so far. > 8. I think leaving <max> out us better than using #t. That’s ambiguous with the current syntax for requiring a certain exact number of repeats. Daphne
