On Tue, Nov 28, 2023, 8:54 AM Nikita Domnitskii <nikita@domnitskii.me>
wrote:

> Richard Stallman <rms@gnu.org> writes:
>
> >   (cond* (:bind b1 (b (save-window-excursion (find-file-at-point
> filename))))
> >          ((bufferp b) (setq b1 b))
> >          ((bufferp (car-safe b)) (setq b1 (car-safe b))))
> >   (if b1 (switch-to-buffer-other-window b)))
> >
> >   (cond* (:bind b1 (b (save-window-excursion (find-file-at-point
> filename))))
> >          ((bufferp b) (switch-to-buffer-other-window b))
> >          ((bufferp (car-safe b)) (switch-to-buffer-other-window
> (car-safe b)))))
> >
> >   (let ((b (save-window-excursion (find-file-at-point filename))) b1)
> >     (if (or (match-set b1 b (bufferp b1))
> >             (match-set b1 (car-safe b) (bufferp b1)))
> >         (switch-to-buffer-other-window b1)))
>
> To be honest all variants look less expressive than original
> pcase.
>
> Maybe instead of trying to implement cond* we should look into impoving
> pcase patterns? As a starting point I suggest Racket pattern matching
> implementation (which in my opinion is fairly readable):
> https://docs.racket-lang.org/reference/match.html


A similar match package is available in guile:
https://www.gnu.org/software/guile/manual/html_node/Pattern-Matching.html

Indeed, I first saw "match" in a course on compiler theory around 2000.
When I saw pcase I thought the author had based it on "match", but
according to  https://dl.acm.org/doi/pdf/10.1145/3386324 (Evolution of
Emacs Lisp, p 37), that resemblance was, at least initially, accidental.

As some others here have expressed, I find the use of "constructor syntax"
for both construction (in a value position) and destructuring (in a binding
position) aesthetically appealing.  On the other hand, since pcase is in
some ways an inverse operator to quasiquotation, I feel like the pattern
clauses should be implicitly backquoted.  Or, one might say, backquote
introduces a value context for constructor syntax, but is not itself part
of that constructor syntax, while unquote (comma) and unquote-splice
(comma-at) operators are constructor syntax.  Then pcase can be seen as
introducing a binding context (i.e. similar to the"cond-let" form being
discussed elsewhere).  Read syntax could also be introduced to formalize
the duality of the operators, say "`?".

The documentation of the "bare" patterns (un-backquoted) is probably the
most confusing part of the doc, especially with the "Caveats for symbol in
pattern" section, but that's how pcase is introduced(!).  That's where the
confusing DSL is to me, since operators like "and" and "or" are redefined
but act on patterns rather than values, but there's no visual prompt that
this redefinition is in effect. A similar complaint might be levelled at
",(and ...)".  If backquote and pcase were understood to introduce
evaluation and binding contexts respectively for constructor syntax, then
maybe the change in meaning would be more apparent?

There are also macro expanders written explicitly for syntax pattern
matching in Scheme.  Those might be adapted if the core developers would
prefer separate facilities for pattern matching used for compiling than
"low-level" facilities made available everywhere.  In a system like
"syntax-case" the bindings made by the matcher are only available in the
"syntax" constructor form, rather than bound as ordinary lexically-scoped
variables.


Lynn