unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrew Hyatt <ahyatt@gmail.com>
To: Tassilo Horn <tsdh@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: pcase defuns
Date: Sun, 19 Dec 2021 10:33:12 -0500	[thread overview]
Message-ID: <m2fsqoehjb.fsf@andrews-mbp.lan> (raw)
In-Reply-To: <871r299e5j.fsf@gnu.org>

On Sun, Dec 19, 2021 at 09:34 AM Tassilo Horn <tsdh@gnu.org> 
wrote: 

> Andrew Hyatt <ahyatt@gmail.com> writes: 
> 
> Hi Andrew, 
> 
>> As a part of a personal project, I wrote a way to define 
>> functions in an equivalent way to pcases.  For example: 
>> 
>> (pcase-defun mytest (a b _) 
>>  "Match on 'a 'b with the third argument a wildcard" "a b 
>>  match") 
>> 
>> (pcase-defun mytest (c ,var _) 
>>  "Match on 'c binding VAR, with the third argument a wildcard" 
>>  (format "c %s match" var) ) 
>> 
>> (mytest 'a 'b 'c) -> "a b match" (mytest 'c 100 'c) -> "c 100 
>> match" 
> 
> So that's basically similar to cl-defgeneric / cl-defmethod just 
> with pcase pattern matching, right? 
> 
> In that case, I think I like the cl approach better, i.e., 
> having a separate definition for the signature + several 
> implementations for variants. 
> 
> But since the order of patterns is very significant, I'm not 
> sure if it's a good idea to specify them separately.  E.g., what 
> if there are pcase-defun's for mytest in several files?  Then 
> you might get different behavior depending on the order how 
> files are loaded.  And even in the "all patterns in mytest.el" 
> case: what if I re-evaluate some pcase-defuns after the file has 
> been loaded?

I have a solution for this: a crude one: I just sort all the rules 
according to their flattened length. So the most complicated ones 
should get tried first, which I think is something that can 
communicated to the user. There's other ways the system could 
behave, such as offering to the user to define a priority for the 
rule. But definitely it's easy to make sure new rules can be added 
without crazy things happening.

You've hit upon the issue with these types of systems. Powerful, 
easy to use, but dispatch rules are always vague.  The same thing 
can happen with cl-defmethod, IIRC, where you can have two rules 
that both seem like they should take precedence.  I think offering 
this functionality gives the user that choice - if they want very 
specific ordering, they can just use pcase in a function, either 
in a solution as you propose, or just use pcase itself, which is 
pretty straighforward.

>
> So probably I'd favor a pcase-defun which specifies all patterns and
> bodies in a single definition, e.g., like:
>
> (pase-defun mytest
>   "Docstring"
>  ((a b _)
>   "a b match")
>  ((c ,var _)
>   (format "c %s match" var)))
>
> Bye,
> Tassilo



  reply	other threads:[~2021-12-19 15:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-19  4:53 pcase defuns Andrew Hyatt
2021-12-19  8:34 ` Tassilo Horn
2021-12-19 15:33   ` Andrew Hyatt [this message]
2021-12-19 17:16     ` Tassilo Horn
2021-12-19 19:05       ` Stefan Monnier
2021-12-20  5:56         ` Tassilo Horn
2021-12-22 14:07   ` LdBeth
2021-12-19 17:23 ` Stefan Monnier
2021-12-19 21:08   ` Andrew Hyatt
2021-12-21  4:15     ` Richard Stallman
2021-12-21  5:20       ` Andrew Hyatt
2021-12-22  4:18         ` Richard Stallman
2021-12-23  1:52           ` Andrew Hyatt
2021-12-24  4:13             ` Richard Stallman
2021-12-21 15:32     ` Stefan Monnier
2021-12-20  4:43 ` Richard Stallman
2021-12-23  2:30 ` Po Lu
2022-03-26 17:41 ` Andrew Hyatt
2022-03-27  9:31   ` Stefan Monnier
2022-03-27 18:17     ` Andrew Hyatt
2022-03-28  4:15   ` Richard Stallman
2022-03-30  1:28     ` Andrew Hyatt
2022-03-31  4:27       ` Richard Stallman
2022-04-17 22:09         ` Andrew Hyatt
2022-04-19  3:48           ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2fsqoehjb.fsf@andrews-mbp.lan \
    --to=ahyatt@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=tsdh@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).