[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pcase defuns
From: |
Andrew Hyatt |
Subject: |
Re: pcase defuns |
Date: |
Tue, 21 Dec 2021 00:20:41 -0500 |
On Mon, Dec 20, 2021 at 11:15 PM Richard Stallman <rms@gnu.org>
wrote:
[[[ To any NSA and FBI agents reading my email: please consider
]]] [[[ whether defending the US Constitution against all
enemies, ]]] [[[ foreign or domestic, requires you to follow
Snowden's example. ]]]
The idea of defining a function in pieces, scattered around one
or more files, is attractive as regards writing them. But it
creates an inconvenience for subsequent maintenance by other
people.
The first thing you're likely to do when you see a call to a
function you don't know about is to find its definition. For a
piecewise-defined function, "the" definition doesn't exist. It
has a number of partial definitions, scattered around one file
or perhaps multiple files.
If you think it is helpful for clarity to put the code for
handling various cases in various places in the file, no new
construct is needed for that. You can define a function for
handling each case, and put its definition in the place you want
it. Then define one overall function (you can think of it as
"generic") which detects the cases and calls those.
This works with our tools.
Let's contrast this with generic functions.
A generic function has a single central definition which
describes how to call it. It is easy to find that.
Finding the definitions of all the methods may be difficult.
You may need to grep for them.
Calling the generic function selects a method by data types, and
you can generally tell, for given arguments, what data types
they have. You can probably tell that one method is the right
one without seeing all the others and comparing them.
Thus, generic functions cause one kind of inconvenience for
studying a program, but avoids the other kinds.
Let's not add any constructs that increase the level of
complexity of genericness beyond this.
These are all good points, thanks.
I agree that just implementing everything in a function is
reasonable. For that, just using pcase seems good enough,
although it might be interesting to have a very different way of
writing a function such as
(pcase-defun mytest
"Demonstrates a way of writing defuns via pcase matching."
((a b _) "a b match")
(`(c ,v _) (format "c %s match" v)))
Not sure if I like this syntax, it does seem to lend itself to the
idea of a pcase-centric way of programming, but it's also a bit
odd, and doesn't seem to buy much. However, it does at least
answer the objections raised to my initial proposal. Of course, so
does not doing anything.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Re: pcase defuns, Stefan Monnier, 2021/12/19
Re: pcase defuns, Stefan Monnier, 2021/12/21
Re: pcase defuns, Richard Stallman, 2021/12/19
Re: pcase defuns, Po Lu, 2021/12/22