Installing cond* in core

Installing cond* in core

[Stefan Kangas]

Hi emacs-devel,

After careful consideration and off-line discussions between Eli and
myself, we have come up with the following proposed plan:

 1. We will install cond* in core and let people who prefer it use it,
    while people who prefer pcase are free to keep using pcase.

 2. cond* vs pcase is to be considered a matter of stylistic preference.

 3. There is no intention to forcibly replace pcase with cond* in our
    code.

Everyone will be free to maintain the code that falls within their area
of responsibility using the style that they like best.  We hope that
this will make sense to proponents of both sides of the argument.

I have myself expressed significant reservations about installing cond*
in core.  The above could be seen as a politicians response to a
technical problem, and to some extent it is.

Our responsibility as maintainers is first and foremost to ensure that
we can all work together, and unite under a common banner.  Our success
as a project depends on it.  Thus, the last thing we want to do is to
alienate any group of contributors, big or small.

We believe that this is a more important concern than the arguments for
or against cond* or pcase.  The simple fact is that we have different
backgrounds and experiences, which have tended to land us on either side
of this discussion.  This diversity is a strength, and not a weakness.

However, the strong emotions and significant differences of personal
preferences between several very active contributors over months of
discussions have not left us with many reasonable choices.

Note that this decision does not throw our basic coding guidelines out
the window: we will still try to respect the local style of files we
change, the maintainers of various files typically have final say, etc.

It also goes without saying that it's probably best if the proposed
improvements to cond* are considered before the macro is installed.
It is our understanding that Richard intends to work on that.

Finally, this co-maintainer would like to draw everyone's attention to
this paragraph in a recent article[1] on sharp technical divisions over
typing in the Python community:

    The discussion highlighted another thing that is something of a
    hallmark of the Python world: cordiality even in the face of strong
    disagreement ...  Python conversations are almost always
    collegial—and have been for decades.  For example, several took the
    opportunity of the thread to thank the typing developers and to
    recognize that the feature does have uses (and users), even if they
    were not particularly inclined toward using typing themselves.  It
    all helps reinforce Brett Cannon's adage that he came for the
    language, but stayed for the community.  It also bodes well for
    finding reasonable solutions and compromises for typing—and more.

If it is true that Python "can be seen as a dialect of Lisp with
'traditional' syntax",[2] then perhaps it is our turn to take a cue
from them.


Footnotes:
[1]  https://lwn.net/Articles/958326/

[2]  https://norvig.com/python-lisp.html

Re: Installing cond* in core

[Alan Mackenzie]

Hello, Stefan.

On Sat, Jan 27, 2024 at 13:36:50 -0800, Stefan Kangas wrote:
> Hi emacs-devel,

> After careful consideration and off-line discussions between Eli and
> myself, we have come up with the following proposed plan:

>  1. We will install cond* in core and let people who prefer it use it,
>     while people who prefer pcase are free to keep using pcase.

>  2. cond* vs pcase is to be considered a matter of stylistic preference.

>  3. There is no intention to forcibly replace pcase with cond* in our
>     code.

Thanks for taking the trouble to work this through.

Can you further confirm that there will be no technical advantages given
to pcase over cond*?  In particular, that condstar.el will be in
lisp/emacs-lisp, and that it will be available from early mid-bootstrap
onwards, just as pcase is?

> Everyone will be free to maintain the code that falls within their area
> of responsibility using the style that they like best.  We hope that
> this will make sense to proponents of both sides of the argument.

> I have myself expressed significant reservations about installing cond*
> in core.  The above could be seen as a politicians response to a
> technical problem, and to some extent it is.

> Our responsibility as maintainers is first and foremost to ensure that
> we can all work together, and unite under a common banner.  Our success
> as a project depends on it.  Thus, the last thing we want to do is to
> alienate any group of contributors, big or small.

On this point, it's worth noting that pcase was silently slipped into
Emacs in the dead of night without any public discussion, and was then
widely proliferated through working code, again without discussion.
That has relevance to "alienation", and goes some way towards explaining
my attitude towards cond* and pcase.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Installing cond* in core

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> Can you further confirm that there will be no technical advantages given
> to pcase over cond*?

I see cond* as an alternative to pcase for those that prefer it.
This is one consequence of deciding not to get rid of pcase.

> In particular, that condstar.el will be in lisp/emacs-lisp,

We didn't discuss that.  I'd put it in lisp/, myself.

> and that it will be available from early mid-bootstrap onwards, just
> as pcase is?

We didn't discuss that.  It sounds like a separate change from adding
cond* to core, and I'm not sure it makes sense to commit to it off-hand,
without first understanding the details.

In general, there is no point to loading something early unless it is
used early.  Do you have something more specific in mind?

> On this point, it's worth noting that pcase was silently slipped into
> Emacs in the dead of night without any public discussion, and was then
> widely proliferated through working code, again without discussion.
> That has relevance to "alienation", and goes some way towards explaining
> my attitude towards cond* and pcase.

I can't speak to that, as I wasn't around.

I would propose that we start looking forward, and go back to working on
the things that we enjoy and find interesting.  That's likely to be more
productive than discussing the details of how things happened or didn't
happen 14 years ago.

Re: Installing cond* in core

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> I see cond* as an alternative to pcase for those that prefer it.
> This is one consequence of deciding not to get rid of pcase.

[...]

> We didn't discuss that.  It sounds like a separate change from adding
> cond* to core, and I'm not sure it makes sense to commit to it off-hand,
> without first understanding the details.
>
> In general, there is no point to loading something early unless it is
> used early.  Do you have something more specific in mind?

With consideration to its role as an alternative to pcase, it's
reasonable to request that it not be placed at a disadvantage by not
being available at the same stage of the bootstrap process as pcase.

Re: Installing cond* in core

[Stefan Monnier via Emacs development discussions.]

> I have myself expressed significant reservations about installing cond*
> in core.  The above could be seen as a politicians response to a
> technical problem, and to some extent it is.

I like the addition of binding constructs to `cond`, so I think `cond*`
could be a worthwhile addition, actually.

But I think the two pattern languages (that of `cond*`s `match*` and
that of Pcase) need to be unified, because they're already too similar
to justify having them both.  This would be a very simple change that
simplifies the implementation (and the doc) significantly.


        Stefan

Re: Installing cond* in core

[Eli Zaretskii]

> Date: Sat, 27 Jan 2024 23:33:52 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Can you further confirm that there will be no technical advantages given
> to pcase over cond*?

This remains to be seen.  Only actual usage of cond* and experience we
gain from that will allow us to realize the relative merits and
demerits of each one of the macros.

> In particular, that condstar.el will be in lisp/emacs-lisp

That's probably a good place, yes.

> and that it will be available from early mid-bootstrap onwards, just
> as pcase is?

Only if really needed.  I object in general to preloading anything
that is not actually needed, and for that reason I will keep an eye on
uses of cond* in preloaded files, with the purpose of avoiding that as
much as possible, so that we don't have to preload another package
unless we must.

> On this point, it's worth noting that pcase was silently slipped into
> Emacs in the dead of night without any public discussion, and was then
> widely proliferated through working code, again without discussion.

Please drop this attitude: it is not useful.  In Emacs development,
stuff is routinely "slipped into Emacs in the dead of the night
without any public discussion", for better and for worse.  I'm sure
that if you examine the logs of your own changes, you will see many
examples of that; I know I see that in mine and in most other's.
E.g., I installed a user-facing change just yesterday without asking
anyone's opinion.  This is how Emacs is developed for decades, and we
should by now realize that this is our strength, although it does have
known downsides.  The stuff that goes into the repository is sent to a
special mailing list, so people who want to be aware of things
"slipping in the dead of night" have ample opportunity to pay
attention and holler.

Re: Installing cond* in core

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 27 Jan 2024 16:26:17 -0800
> Cc: emacs-devel@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> Alan Mackenzie <acm@muc.de> writes:
> 
> > In particular, that condstar.el will be in lisp/emacs-lisp,
> 
> We didn't discuss that.  I'd put it in lisp/, myself.

FWIW, I think lisp/emacs-lisp/ is better, since we are talking about a
macro that is (going to be) part of Emacs Lisp.

Re: Installing cond* in core

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Alan Mackenzie <acm@muc.de>,  emacs-devel@gnu.org,  Stefan Monnier
>  <monnier@iro.umontreal.ca>
> Date: Sun, 28 Jan 2024 10:43:59 +0800
> 
> With consideration to its role as an alternative to pcase, it's
> reasonable to request that it not be placed at a disadvantage by not
> being available at the same stage of the bootstrap process as pcase.

This is not a "fair competition" kind of issue.  Whether cond* will
fly on the same flight level as pcase, or higher or lower, will be
decided based on actual experience and other relevant technical
aspects, and nothing else.

Re: Installing cond* in core

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> This is not a "fair competition" kind of issue.  Whether cond* will
> fly on the same flight level as pcase, or higher or lower, will be
> decided based on actual experience and other relevant technical
> aspects, and nothing else.

Fair enough, but please don't object to:

  (eval-when-compile
    (require 'condstar))

in x-dnd.el and the like.

Re: Installing cond* in core

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  acm@muc.de,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca
> Date: Sun, 28 Jan 2024 15:21:20 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is not a "fair competition" kind of issue.  Whether cond* will
> > fly on the same flight level as pcase, or higher or lower, will be
> > decided based on actual experience and other relevant technical
> > aspects, and nothing else.
> 
> Fair enough, but please don't object to:
> 
>   (eval-when-compile
>     (require 'condstar))
> 
> in x-dnd.el and the like.

Why should I object to that, assuming that the use of cond* in
whatever file does this is justified?

Re: Installing cond* in core

[Alan Mackenzie]

Hello, Eli.

On Sun, Jan 28, 2024 at 08:09:28 +0200, Eli Zaretskii wrote:
> > Date: Sat, 27 Jan 2024 23:33:52 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > On this point, it's worth noting that pcase was silently slipped into
> > Emacs in the dead of night without any public discussion, and was then
> > widely proliferated through working code, again without discussion.

> Please drop this attitude: it is not useful.  In Emacs development,
> stuff is routinely "slipped into Emacs in the dead of the night
> without any public discussion", for better and for worse.

Pretending it didn't happen and failing to discuss it is not healthy for
the project.  Routine bug fixes, and uncontroversial stuff is committed
without discussion, yes.  Otherwise we'd be doing nothing else but silly
discussions on emacs-devel.

But changes which fundamentally affect the way everybody works should be
openly discussed, first.  pcase was such a change, and it was not
discussed.  Had if been discussed first, then:

(i) Its faults could have been identified and corrected, or at least
  ameliorated.
(ii) It would have had adequate documentation from the start.
(iii) Richard wouldn't be trying to fix things 14 years later by
  crafting a better alternative.

> I'm sure that if you examine the logs of your own changes, you will
> see many examples of that; I know I see that in mine and in most
> other's.

I don't think I have ever intalled anything controversial without
discussing it on the list.  I don't think you have, either.  For
example, when you enhanced redisplay a few years ago to display line
numbers, that was openly discussed.  A few bugs were found, and you made
one or two changes to the design in response to feedback.  That's the
way things should work.  It didn't happen for pcase.

> E.g., I installed a user-facing change just yesterday without asking
> anyone's opinion.  This is how Emacs is developed for decades, and we
> should by now realize that this is our strength, although it does have
> known downsides.  The stuff that goes into the repository is sent to a
> special mailing list, so people who want to be aware of things
> "slipping in the dead of night" have ample opportunity to pay
> attention and holler.

Controversial things should be discussed _before_ being committed to
master, before their designs are finalised, not afterwards.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Installing cond* in core

[Dmitry Gutov]

On 28/01/2024 14:38, Alan Mackenzie wrote:
> Pretending it didn't happen and failing to discuss it is not healthy for
> the project.  Routine bug fixes, and uncontroversial stuff is committed
> without discussion, yes.  Otherwise we'd be doing nothing else but silly
> discussions on emacs-devel.

The addition of pcase was a boon for the project.

Its uses in particularly important areas, like bytecomp, might have been 
a subject for discussion, but we don't really do that when all active 
contributors to an area of code agree with the technical decision.

And they did agree, otherwise the discussion would have had materialized 
at the spot.

Re: Installing cond* in core

[Emanuel Berg]

Alan Mackenzie wrote:

> Controversial things should be discussed _before_ being
> committed to master, before their designs are finalised,
> not afterwards.

I think most people will agree completely.

It is beneficial to software, but also to people.

Often what is important to people is they get to say their
views and be heard. Even if what actually happens after that
is something opposite to their point of view, it will be much
easier for them to take and let go of.

People shouldn't feel "first people ignores me, then I have to
deal with all the problems that came from it".

-- 
underground experts united
https://dataswamp.org/~incal

Re: Installing cond* in core

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Jan 28, 2024 at 15:02:29 +0200, Dmitry Gutov wrote:
> On 28/01/2024 14:38, Alan Mackenzie wrote:
> > Pretending it didn't happen and failing to discuss it is not healthy for
> > the project.  Routine bug fixes, and uncontroversial stuff is committed
> > without discussion, yes.  Otherwise we'd be doing nothing else but silly
> > discussions on emacs-devel.

> The addition of pcase was a boon for the project.

You're missing the point.  pcase has flaws, and even now, 14 years
later, isn't satisfactorally documented.  All you seem to be saying is
that pcase is better than no pcase.  I'd agree with that.

But if pcase were so good, why is Richard writing a better replacement?

> Its uses in particularly important areas, like bytecomp, might have been 
> a subject for discussion, but we don't really do that when all active 
> contributors to an area of code agree with the technical decision.

You're being a bit vague there, but when have all active contributors to
any area of code been in agreement?

> And they did agree, otherwise the discussion would have had materialized 
> at the spot.

That's not the way things happened.  pcase was simply installed in
Emacs, with all its faults, and then proliferated round Emacs.  Where
was the room for discussion?  Discussion is difficult after something
has already been done.

If you're trying to say that pcase is better than nothing, so people use
it, then I'd agree.  But if you're trying to insist it's as good as it
could be, I'd ask you why Richard is spending a lot of time crafting a
better replacement.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Installing cond* in core

[Dmitry Gutov]

On 28/01/2024 15:38, Alan Mackenzie wrote:
> Hello, Dmitry.
> 
> On Sun, Jan 28, 2024 at 15:02:29 +0200, Dmitry Gutov wrote:
>> On 28/01/2024 14:38, Alan Mackenzie wrote:
>>> Pretending it didn't happen and failing to discuss it is not healthy for
>>> the project.  Routine bug fixes, and uncontroversial stuff is committed
>>> without discussion, yes.  Otherwise we'd be doing nothing else but silly
>>> discussions on emacs-devel.
> 
>> The addition of pcase was a boon for the project.
> 
> You're missing the point.  pcase has flaws, and even now, 14 years
> later, isn't satisfactorally documented.  All you seem to be saying is
> that pcase is better than no pcase.  I'd agree with that.
> 
> But if pcase were so good, why is Richard writing a better replacement?

It all started with some people not understanding what pcase does and 
how it works. We're yet to see whether cond* is any better in those areas.

>> Its uses in particularly important areas, like bytecomp, might have been
>> a subject for discussion, but we don't really do that when all active
>> contributors to an area of code agree with the technical decision.
> 
> You're being a bit vague there, but when have all active contributors to
> any area of code been in agreement?

A lot of times. Or in enough of an agreement for there being no problems 
to discuss.

>> And they did agree, otherwise the discussion would have had materialized
>> at the spot.
> 
> That's not the way things happened.  pcase was simply installed in
> Emacs, with all its faults, and then proliferated round Emacs.  Where
> was the room for discussion?  Discussion is difficult after something
> has already been done.

We're doing it all the time by commenting on commits in an email to 
emacs-devel.

> If you're trying to say that pcase is better than nothing, so people use
> it, then I'd agree.  But if you're trying to insist it's as good as it
> could be,

One does not need to insist on that to disagree with your original 
statements.

> I'd ask you why Richard is spending a lot of time crafting a
> better replacement.

Rewriting other people's code that one doesn't understand has a long and 
varied history in software development. We even have a term for it.

Re: Installing cond* in core

[Eli Zaretskii]

> Date: Sun, 28 Jan 2024 12:38:23 +0000
> Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Please drop this attitude: it is not useful.  In Emacs development,
> > stuff is routinely "slipped into Emacs in the dead of the night
> > without any public discussion", for better and for worse.
> 
> Pretending it didn't happen and failing to discuss it is not healthy for
> the project.

That's not what I said.

> Routine bug fixes, and uncontroversial stuff is committed without
> discussion, yes.

Those aren't the cases to which I alluded.

> > I'm sure that if you examine the logs of your own changes, you will
> > see many examples of that; I know I see that in mine and in most
> > other's.
> 
> I don't think I have ever intalled anything controversial without
> discussing it on the list.

The problem is that "controversial" is many times only evident in
retrospect.

> Controversial things should be discussed _before_ being committed to
> master, before their designs are finalised, not afterwards.

When we realize they are controversial, yes.  Many times, they are
not, and that's life.

Re: Installing cond* in core

[Emanuel Berg]

Stefan Kangas wrote:

> After careful consideration and off-line discussions between
> Eli and myself, we have come up with the following proposed
> plan [...]

A very good proposal and well put.

Hopefully people will accept it as a nod to everyone and an
invitation to move forward.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Installing cond* in core

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Jan 28, 2024 at 15:48:04 +0200, Dmitry Gutov wrote:
> On 28/01/2024 15:38, Alan Mackenzie wrote:
> > On Sun, Jan 28, 2024 at 15:02:29 +0200, Dmitry Gutov wrote:
> >> On 28/01/2024 14:38, Alan Mackenzie wrote:
> >>> Pretending it didn't happen and failing to discuss it is not healthy for
> >>> the project.  Routine bug fixes, and uncontroversial stuff is committed
> >>> without discussion, yes.  Otherwise we'd be doing nothing else but silly
> >>> discussions on emacs-devel.

> >> The addition of pcase was a boon for the project.

> > You're missing the point.  pcase has flaws, and even now, 14 years
> > later, isn't satisfactorally documented.  All you seem to be saying is
> > that pcase is better than no pcase.  I'd agree with that.

> > But if pcase were so good, why is Richard writing a better replacement?

> It all started with some people not understanding what pcase does and 
> how it works.

I don't think that's true.  People understand how it works.  Enough
people have difficulty reading and debugging pcase and its numerous
variants to matter.

> We're yet to see whether cond* is any better in those areas.

This is true, but it's highly likely cond* will be better.  It's being
designed by an expert designer, and has been through a phase of open
comment and revision.  Also, it takes advantage of the experience of
pcase.

[ .... ]

> > That's not the way things happened.  pcase was simply installed in
> > Emacs, with all its faults, and then proliferated round Emacs.  Where
> > was the room for discussion?  Discussion is difficult after something
> > has already been done.

> We're doing it all the time by commenting on commits in an email to 
> emacs-devel.

To have been effective, such comment would have resulted in the removal
or fundamental alteration of pcase long after it had been ground into the
core of Emacs.  That just wasn't going to happen.

You weren't there at the time.  I was.  I was completely unaware of pcase
happening, and it was a shock being confronted by it for the first time.

> > If you're trying to say that pcase is better than nothing, so people use
> > it, then I'd agree.  But if you're trying to insist it's as good as it
> > could be,

> One does not need to insist on that to disagree with your original 
> statements.

You cannot disagree with my original statement made last night.  As I
said, you weren't there at the time.

> > I'd ask you why Richard is spending a lot of time crafting a
> > better replacement.

> Rewriting other people's code that one doesn't understand has a long and 
> varied history in software development. We even have a term for it.

You're suggesting in that paragraph that the fault lies in Richard's lack
of ability.  That's uncalled for.  He has trouble reading and
understanding code written with pcase, as do I, and as do others here.
The fault is in pcase; it is flawed.  At the same time, it is not doubted
that there are people here fully conversant with pcase.  Having such a
split in the project is a bad thing.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Installing cond* in core

[Alan Mackenzie]

Hello, Eli.

On Sun, Jan 28, 2024 at 16:18:33 +0200, Eli Zaretskii wrote:
> > Date: Sun, 28 Jan 2024 12:38:23 +0000
> > Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Please drop this attitude: it is not useful.  In Emacs development,
> > > stuff is routinely "slipped into Emacs in the dead of the night
> > > without any public discussion", for better and for worse.

> > Pretending it didn't happen and failing to discuss it is not healthy for
> > the project.

> That's not what I said.

Sorry, I misunderstood you.

> > Routine bug fixes, and uncontroversial stuff is committed without
> > discussion, yes.

> Those aren't the cases to which I alluded.

All right, most commits without commenting on emacs-devel are
uncontroversial.  I am aware of a few others, about which I've not been
happy either.  Do you find the level of such commits acceptable, or do
you too wish they were discussed more?

> > > I'm sure that if you examine the logs of your own changes, you will
> > > see many examples of that; I know I see that in mine and in most
> > > other's.

> > I don't think I have ever intalled anything controversial without
> > discussing it on the list.

> The problem is that "controversial" is many times only evident in
> retrospect.

In the current case, the controversy was obvious.  How can you change the
meaning of the basic tokens ` and , without it being controversial?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Installing cond* in core

[Eli Zaretskii]

> Date: Sun, 28 Jan 2024 15:26:22 +0000
> Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > I don't think I have ever intalled anything controversial without
> > > discussing it on the list.
> 
> > The problem is that "controversial" is many times only evident in
> > retrospect.
> 
> In the current case, the controversy was obvious.

No, it wasn't.  It is only obvious today, and even today quite a few
active Emacs developers disagree that there is a problem.

So please, let's stop this argument that has no useful purpose.
Let's move on.

Re: Installing cond* in core

[Alan Mackenzie]

Hello, Stefan.

On Sat, Jan 27, 2024 at 16:26:17 -0800, Stefan Kangas wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Can you further confirm that there will be no technical advantages given
> > to pcase over cond*?

> I see cond* as an alternative to pcase for those that prefer it.
> This is one consequence of deciding not to get rid of pcase.

> > In particular, that condstar.el will be in lisp/emacs-lisp,

> We didn't discuss that.  I'd put it in lisp/, myself.

That would make it unusable early in the bootstrap, putting it at a
disadvantage to pcase.

> > and that it will be available from early mid-bootstrap onwards, just
> > as pcase is?

> We didn't discuss that.  It sounds like a separate change from adding
> cond* to core, and I'm not sure it makes sense to commit to it off-hand,
> without first understanding the details.

> In general, there is no point to loading something early unless it is
> used early.  Do you have something more specific in mind?

Yes.  I outlined a few days ago my idea of tidying up the bootstrap
process by using cond* in macroexp.el, thus allowing the files loaded by
loadup.el to be in a more natural order.  This idea was vetoed by Eli,
at least for the moment.  But it seems like a good idea not to rule out
similar changes in the future.

> > On this point, it's worth noting that pcase was silently slipped into
> > Emacs in the dead of night without any public discussion, and was then
> > widely proliferated through working code, again without discussion.
> > That has relevance to "alienation", and goes some way towards explaining
> > my attitude towards cond* and pcase.

> I can't speak to that, as I wasn't around.

> I would propose that we start looking forward, and go back to working on
> the things that we enjoy and find interesting.  That's likely to be more
> productive than discussing the details of how things happened or didn't
> happen 14 years ago.

The events of 14 years ago have a profound influence on the present and
future.  I'm somewhat disappointed that the solution you've come up with
for cond* is not going to help me at all, though I understand how and
why you made it.  It's basically leave things as they are and ignore
cond*.  In ten years time, I'm still going to be faced with inscrutable
pcases when debugging code, and that will still slow me down just as
much as it does today.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Installing cond* in core

[Dmitry Gutov]

Hi Alan,

On 28/01/2024 16:32, Alan Mackenzie wrote:

>>> But if pcase were so good, why is Richard writing a better replacement?
> 
>> It all started with some people not understanding what pcase does and
>> how it works.
> 
> I don't think that's true.  People understand how it works.  Enough
> people have difficulty reading and debugging pcase and its numerous
> variants to matter.

Richard explicitly asked a number of questions about what it does and 
how it works. A number others also expressed confusion about it, what 
the syntax means and how to interpret it.

>> We're yet to see whether cond* is any better in those areas.
> 
> This is true, but it's highly likely cond* will be better.  It's being
> designed by an expert designer, and has been through a phase of open
> comment and revision.  Also, it takes advantage of the experience of
> pcase.

A new macro that went through a few rounds of revision with no real 
consumers yet vs a macro that's been in use for 14 years.

Have you actually tried it yourself? E.g. to rewrite some code 
conversion logic that you urge to replace?

> [ .... ]
> 
>>> That's not the way things happened.  pcase was simply installed in
>>> Emacs, with all its faults, and then proliferated round Emacs.  Where
>>> was the room for discussion?  Discussion is difficult after something
>>> has already been done.
> 
>> We're doing it all the time by commenting on commits in an email to
>> emacs-devel.
> 
> To have been effective, such comment would have resulted in the removal
> or fundamental alteration of pcase long after it had been ground into the
> core of Emacs.  That just wasn't going to happen.
> 
> You weren't there at the time.  I was.  I was completely unaware of pcase
> happening, and it was a shock being confronted by it for the first time.

If you weren't aware, then you weren't working on that area of code, right?

>>> If you're trying to say that pcase is better than nothing, so people use
>>> it, then I'd agree.  But if you're trying to insist it's as good as it
>>> could be,
> 
>> One does not need to insist on that to disagree with your original
>> statements.
> 
> You cannot disagree with my original statement made last night.  As I
> said, you weren't there at the time.

I don't have to insist it's as good as it could be to object to throwing 
it out.

>>> I'd ask you why Richard is spending a lot of time crafting a
>>> better replacement.
> 
>> Rewriting other people's code that one doesn't understand has a long and
>> varied history in software development. We even have a term for it.
> 
> You're suggesting in that paragraph that the fault lies in Richard's lack
> of ability.  That's uncalled for.  He has trouble reading and
> understanding code written with pcase, as do I, and as do others here.
> The fault is in pcase; it is flawed.  At the same time, it is not doubted
> that there are people here fully conversant with pcase.  Having such a
> split in the project is a bad thing.

Having trouble with doing something is the literal definition of lack of 
ability.

Not the lack of talent, mind you, or potential, but insufficient 
understanding and skill with that tool (destructuring pattern 
matching--which is not unique to Elisp and has carryover from a number 
of other programming languages) is what motivated this whole argument.

And I'm really skeptical that when cond* goes through all the additional 
revisions and gets as powerful as pcase, that it won't raise all the 
similar questions. But I guess we shall see.

Re: Installing cond* in core

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Jan 28, 2024 at 18:54:18 +0200, Dmitry Gutov wrote:
> Hi Alan,

> On 28/01/2024 16:32, Alan Mackenzie wrote:

[ .... ]

> >> We're yet to see whether cond* is any better in those areas.

> > This is true, but it's highly likely cond* will be better.  It's
> > being designed by an expert designer, and has been through a phase of
> > open comment and revision.  Also, it takes advantage of the
> > experience of pcase.

> A new macro that went through a few rounds of revision with no real 
> consumers yet vs a macro that's been in use for 14 years.

Yes.  The 14 year old macro has acknowledged faults, the new one doesn't
as far as anybody yet knows (although it has an area of controversy).

> Have you actually tried it yourself? E.g. to rewrite some code 
> conversion logic that you urge to replace?

No.  It is not yet working.

> > [ .... ]

> >>> That's not the way things happened.  pcase was simply installed in
> >>> Emacs, with all its faults, and then proliferated round Emacs.  Where
> >>> was the room for discussion?  Discussion is difficult after something
> >>> has already been done.

> >> We're doing it all the time by commenting on commits in an email to
> >> emacs-devel.

> > To have been effective, such comment would have resulted in the removal
> > or fundamental alteration of pcase long after it had been ground into the
> > core of Emacs.  That just wasn't going to happen.

> > You weren't there at the time.  I was.  I was completely unaware of pcase
> > happening, and it was a shock being confronted by it for the first time.

> If you weren't aware, then you weren't working on that area of code, right?

I was not.  pcase was first committed on 2010-08-04 in commit
d02c9bcd096c44b4e3d5e2834c75967b56cdecdd.  There was no prior discussion
about it on emacs-devel.

> >>> If you're trying to say that pcase is better than nothing, so people use
> >>> it, then I'd agree.  But if you're trying to insist it's as good as it
> >>> could be,

> >> One does not need to insist on that to disagree with your original
> >> statements.

> > You cannot disagree with my original statement made last night.  As I
> > said, you weren't there at the time.

> I don't have to insist it's as good as it could be to object to throwing 
> it out.

Your wish has been fulfilled.  Eli's and Stefan K's decision from last
night is 100% in favour of those who want the use of pcase to carry on
unchanged.  cond* has been consigned to a few niche uses before it is
even up and running.

> >>> I'd ask you why Richard is spending a lot of time crafting a
> >>> better replacement.

> >> Rewriting other people's code that one doesn't understand has a long and
> >> varied history in software development. We even have a term for it.

> > You're suggesting in that paragraph that the fault lies in Richard's lack
> > of ability.  That's uncalled for.  He has trouble reading and
> > understanding code written with pcase, as do I, and as do others here.
> > The fault is in pcase; it is flawed.  At the same time, it is not doubted
> > that there are people here fully conversant with pcase.  Having such a
> > split in the project is a bad thing.

> Having trouble with doing something is the literal definition of lack of 
> ability.

"Lack of ability" means a general inability to get things done, unless
qualified somehow.  (English is my first language.)  The fault lies in
pcase's unreadable syntax.  It is not personal.

> Not the lack of talent, mind you, or potential, but insufficient 
> understanding and skill with that tool (destructuring pattern 
> matching--which is not unique to Elisp and has carryover from a number 
> of other programming languages) is what motivated this whole argument.

Unlike most of Emacs Lisp, pcase is peculiar in that only some hackers
can get to grips with it.  You seems to be one of them, I am certainly
not, and neither is Richard.  The decision recently taken will mean you
need not trouble yourself with cond*, and people like me will continue to
be hindered and slowed down by pcase code for the foreseeable future.

> And I'm really skeptical that when cond* goes through all the additional 
> revisions and gets as powerful as pcase, that it won't raise all the 
> similar questions.

Possibly, but not inevitably.  Its syntax is kinder on the eye than
pcase's.  Maybe people would object to it because it requires the use of
multicharacter keywords and is bulkier, and so on.  I can't tell at this
stage.

> But I guess we shall see.

I doubt we will.  My proposal to test cond* by putting it into
macroexp.el was vetoed by Eli.  The decision taken was not to replace any
pcase with cond*.  Where does that leave cond*?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Installing cond* in core

[Eli Zaretskii]

> Date: Sun, 28 Jan 2024 19:14:06 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > But I guess we shall see.
> 
> I doubt we will.  My proposal to test cond* by putting it into
> macroexp.el was vetoed by Eli.  The decision taken was not to replace any
> pcase with cond*.

You've misunderstood the decision.

Re: Installing cond* in core

[Dmitry Gutov]

Hi Alan,

On 28/01/2024 21:14, Alan Mackenzie wrote:

>>>> We're yet to see whether cond* is any better in those areas.
> 
>>> This is true, but it's highly likely cond* will be better.  It's
>>> being designed by an expert designer, and has been through a phase of
>>> open comment and revision.  Also, it takes advantage of the
>>> experience of pcase.
> 
>> A new macro that went through a few rounds of revision with no real
>> consumers yet vs a macro that's been in use for 14 years.
> 
> Yes.  The 14 year old macro has acknowledged faults, the new one doesn't
> as far as anybody yet knows (although it has an area of controversy).

A bunch have already been mentioned. Including (but not limited to) the 
gratuitous incompatibility in syntax where it doesn't have to be 
different when Stefan mentioned lately.

>>> You weren't there at the time.  I was.  I was completely unaware of pcase
>>> happening, and it was a shock being confronted by it for the first time.
> 
>> If you weren't aware, then you weren't working on that area of code, right?
> 
> I was not.  pcase was first committed on 2010-08-04 in commit
> d02c9bcd096c44b4e3d5e2834c75967b56cdecdd.  There was no prior discussion
> about it on emacs-devel.

So, you wanted it to have been discussed with... simply someone? I'm 
guessing it must have been, in public or in private.

And if you were looking for the reasoning behind it, there are a few 
paragraphs about it in Stefan's paper: 
https://dl.acm.org/doi/pdf/10.1145/3386324 (Section 8.3, page 37).

>>>>> If you're trying to say that pcase is better than nothing, so people use
>>>>> it, then I'd agree.  But if you're trying to insist it's as good as it
>>>>> could be,
> 
>>>> One does not need to insist on that to disagree with your original
>>>> statements.
> 
>>> You cannot disagree with my original statement made last night.  As I
>>> said, you weren't there at the time.
> 
>> I don't have to insist it's as good as it could be to object to throwing
>> it out.
> 
> Your wish has been fulfilled.  Eli's and Stefan K's decision from last
> night is 100% in favour of those who want the use of pcase to carry on
> unchanged.  cond* has been consigned to a few niche uses before it is
> even up and running.

The proof is in the pudding. Personally, I *would* have put it in ELPA 
after some sufficiently broad announcement that there is this new 
powerful syntax endorsed by the maintainers of Emacs (or some of them), 
that the package authors could use. And see how well that turns out. The 
alternative-syntaxes packages (like f/s/dash) have been fairly popular 
among the package author community. But for some reason people who don't 
like pcase here, don't seem to like ELPA either.

For my part, I'm concerned that cond* turns out to be a weaker, 
arbitrarily incompatible version of pcase, and only practice can prove 
otherwise. Committing to changing a whole swaths of code to it risks 
fixing in stone any current deficiencies. Not to mention that taking 
over the code that Stefan still maintains to an extent would not be very 
friendly.

>> Not the lack of talent, mind you, or potential, but insufficient
>> understanding and skill with that tool (destructuring pattern
>> matching--which is not unique to Elisp and has carryover from a number
>> of other programming languages) is what motivated this whole argument.
> 
> Unlike most of Emacs Lisp, pcase is peculiar in that only some hackers
> can get to grips with it.  You seems to be one of them, I am certainly
> not, and neither is Richard.  The decision recently taken will mean you
> need not trouble yourself with cond*, and people like me will continue to
> be hindered and slowed down by pcase code for the foreseeable future.

Just to be clear, I like pcase not because I am particularly clever, but 
because my brain can only fit a limited number of things at a time 
(ideas, processes, or words on the screen), and a succinct syntax that 
uses principles I can recognize allows me to understand such programs 
quicker, cutting out the boilerplate.

>> And I'm really skeptical that when cond* goes through all the additional
>> revisions and gets as powerful as pcase, that it won't raise all the
>> similar questions.
> 
> Possibly, but not inevitably.  Its syntax is kinder on the eye than
> pcase's.  Maybe people would object to it because it requires the use of
> multicharacter keywords and is bulkier, and so on.  I can't tell at this
> stage.

If being slightly more verbose is going to be its only problem, I'd say 
we're in a good place.

Re: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > Richard explicitly asked a number of questions about what it does and 
  > how it works. A number others also expressed confusion about it, what 
  > the syntax means and how to interpret it.

I found it hard to interpret some specific pcase constructs despite
having read its documentation.  It did not come naturally.  However,
with more experience I have learned to understand them.  It still
requires an annoying amount concentration, but I can do it.

I still think pcase is inconvenient in some of its uses -- once
one gets beyond the basic kinds of patterns.

I do not advocate removing or changing pcase itself.  Too much code
depends on it.  I do hope to discourage its use inside Emacs in
favor of cond*.

-- 
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: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > > > > I don't think I have ever intalled anything controversial without
  > > > > discussing it on the list.

It seems that nobody regarded pcase as posing an important design
issue when it was installed.  It is a kind of design issue we usually
don't think about.  We used to use an overflowing sink as the icon for
Emacs.  If some people think a feature is useful, we might try to improve
some details, and then we put it in.

We're not used to asking, "How do we avoid having duplicate features?
How do we achieve these goals while also keeping Emacs as simple as
possible?"  Instead we get a congeries of every feature that seemed
useful for something.

This issue arises for some sorts of features and not for others.  It
tends to be biggest for features that are rather unspecialized.  for
specialized things, it may not be an issue at all.

For instance, a package to communicate using the (fictional) Frotz
protocol does not raise an issue like this.  Some users will use the
Frotz protocol and others won't, but the existence of support for it
won't inconvenience developers much.  Unless you work on one of the
few things that actually interact with Frotz, you won't ever need to
know about that code.

By contrast, pcase does increase what Emacs developers need to learn,
because it is unspecialized.

We should all be on the lookout for proposals to install a construct
which is unspecialized enough to get used in many areas of the Emacs
code base.  In such a situation, we should make sure we fill that
niche in the cleanest possible way.

-- 
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: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > After careful consideration and off-line discussions between Eli and
  > myself, we have come up with the following proposed plan:

  >  1. We will install cond* in core and let people who prefer it use it,
  >     while people who prefer pcase are free to keep using pcase.

  >  2. cond* vs pcase is to be considered a matter of stylistic preference.

  >  3. There is no intention to forcibly replace pcase with cond* in our
  >     code.

I think that is a good plan.

I would not propose to eliminate pcase, or obsolete it, because that
would break things and there is no good reason to do that.

  > In general, there is no point to loading something early unless it is
  > used early.  Do you have something more specific in mind?

If people use it where they wish, it will get used in some files that
are loaded early.  Putting it in emacs-lisp should not require any
special effort.  I think the code generated by `cond*' calls only
C-level primitives, except in one special case.

That special case is when the `rx' construct is used and match
subsequences are extracted as strings.  Then it generates calls to
`match-string' which is in subr.el.  It won't be hard to avoid regexp
matching in code loaded that early.  Indeed, I would be surprised to
see any use for it at that point.

There should be no need to preload cond* because it defines no
run-time support.  All its work is done at macroexpand time.

Perhaps there will be an issue about using it in *non-compiled* files
that are loaded early.  Is any such file complex enough to want to use
constructs such as cond* or pcase?



-- 
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: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > But I think the two pattern languages (that of `cond*`s `match*` and
  > that of Pcase) need to be unified, because they're already too similar
  > to justify having them both.  This would be a very simple change that
  > simplifies the implementation (and the doc) significantly.

When I started designing cond*, I wanted to make its pattern language
more different than it actually is.  Especially I found _ to mean
"match anything and ignore it" to be clunky.  I wanted a simpler way
to say that.

For cdr slots, I found a much more convenient way.  But not for car
slots.  I could not find anything else distinguishable that was
simpler or better than _.  So I went with _.

I did manage to simplify the `pred' and `guard' constructs, replacing
them with constrained variables.

I changed some details of `rx', but that was to make it easier to
implement.  Indeed, it simply calls the Lisp facility `rx'.

Aside from `app', which cond* does not need, is anything else missing
(as opposed to, not yet implemented) from cond* patterns that pcase
has?  For now, I will assume not.

So, how could we make the two pattern languages compatible?

For `rx', I don't object to changing cond*'s `rx' to be compatible
with pcases's.  But I don't want that to implement that myself,
because I expect it to be a pain.  I don't know the pcase code so I
can't undertake to make cond* use that.  Can someone else write this
change in cond*?

For constrained variables, the path I'd be happy with is to make both
cond* and pcase implement both pattern interfaces.  That means cond*
constrained variables (both kinds) and `pred' and `guard'.

I could write that change in cond* if someone else writes the
corresponding change in pcase.


-- 
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: Installing cond* in core

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 29 Jan 2024 22:58:34 -0500
> 
> There should be no need to preload cond* because it defines no
> run-time support.  All its work is done at macroexpand time.

Which is why we should try to make sure all preloaded files require
cond* only with eval-when-compile.

> Perhaps there will be an issue about using it in *non-compiled* files
> that are loaded early.  Is any such file complex enough to want to use
> constructs such as cond* or pcase?

I don't think we have such files, at least not now.

Re: Installing cond* in core

[Stefan Monnier]

> is anything else missing (as opposed to, not yet implemented) from
> cond* patterns that pcase has?  For now, I will assume not.
>
> So, how could we make the two pattern languages compatible?

I think the question is rather: why should we have two equivalent and
almost identical matching syntaxes and implementations?


        Stefan

Re: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > I think the question is rather: why should we have two equivalent and
  > almost identical matching syntaxes and implementations?

That is the easiest way to make cond* function.  (The only work needed
will be future maintenance.)  It is a way something I can feasibly
take.  I do not see any other alternative that I could feasibly do.

I do not understand the pcase code for implementing pattern matching,
and figuring it out would be the first hurdle of trying to fit it into
cond*, if that were done by me.

A priori, I suspect it won't fit.  cond*-subpat, which does this job
in cond*, passes data up and down the recursion.  I can't tell whether
pcase does something comparable.  Also, cond*-subpat does not generate
the overall structure of a clause -- its caller, cond*-match, does
that.  Based on looking at the Lisp code pcase produces, I expect that
it generates the overall structure of the clause as part of success
for a pattern.

Perhaps the work would be much less if done by you.  But I don't have
the option of doing this as you; I could only do it as me.

-- 
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: Installing cond* in core

[Stefan Monnier]

>   > I think the question is rather: why should we have two equivalent and
>   > almost identical matching syntaxes and implementations?
> That is the easiest way to make cond* function.

Only if you consider "easiest" at each small incremental step.
The overall cost of what you've done is already much higher :-)

> I do not understand the pcase code for implementing pattern matching,

You don't need to understand it.

> A priori, I suspect it won't fit.  cond*-subpat, which does this job
> in cond*, passes data up and down the recursion.  I can't tell whether
> pcase does something comparable.  Also, cond*-subpat does not generate
> the overall structure of a clause -- its caller, cond*-match, does
> that.

Throw away cond*-subpat.  Just rewrite

    (cond*
     ((match* PAT FORM) THEN)
     . ELSE)

into something like

    (pcase FORM
      (PAT THEN)
      (_ (cond* . ELSE)))

And presumably for

    (cond*
     ((match* PAT FORM))
     . REST)

you'd rewrite it to

    (pcase-let ((PATH FORM))
      (cond* . REST))

No need to look inside or understand `pcase.el` at all!



        Stefan

Re: Installing cond* in core

[Alan Mackenzie]

Hello, Stefan.

On Fri, Feb 02, 2024 at 08:17:25 -0500, Stefan Monnier wrote:
> >   > I think the question is rather: why should we have two equivalent and
> >   > almost identical matching syntaxes and implementations?
> > That is the easiest way to make cond* function.

> Only if you consider "easiest" at each small incremental step.
> The overall cost of what you've done is already much higher :-)

> > I do not understand the pcase code for implementing pattern matching,

> You don't need to understand it.

I've needed to understand it, and I also found it difficult to
understand.

I've also found difficult the macro expansions which pcase produces.
cond* might be easier here, though it's too soon to tell.

> > A priori, I suspect it won't fit.  cond*-subpat, which does this job
> > in cond*, passes data up and down the recursion.  I can't tell whether
> > pcase does something comparable.  Also, cond*-subpat does not generate
> > the overall structure of a clause -- its caller, cond*-match, does
> > that.

> Throw away cond*-subpat.  Just rewrite

>     (cond*
>      ((match* PAT FORM) THEN)
>      . ELSE)

> into something like

>     (pcase FORM
>       (PAT THEN)
>       (_ (cond* . ELSE)))

> And presumably for

>     (cond*
>      ((match* PAT FORM))
>      . REST)

> you'd rewrite it to

>     (pcase-let ((PATH FORM))
>       (cond* . REST))

> No need to look inside or understand `pcase.el` at all!

But that would rule out the possibility of simplifying pcase by
rewriting it in terms of cond*.  ;-)

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Installing cond* in core

[Stefan Monnier]

> But that would rule out the possibility of simplifying pcase by
> rewriting it in terms of cond*.  ;-)

AFAICT the implementation of `match*` is not designed to handle the task
of matching against several patterns to select which branch to use.

So in order to reimplement `pcase` on top of `match*`s machinery we'd
have to choose between a significant rework/redesign of `match*`, or
a macro-expansion result which performs more repeated tests and
operations at runtime.


        Stefan

Re: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > AFAICT the implementation of `match*` is not designed to handle the task
  > of matching against several patterns to select which branch to use.

I do not follow you.  Could you please describe the issue more concretely?
Pehraps wiht an example  Then I could judge whether this is grave.


-- 
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: Installing cond* in core

[Stefan Monnier]

> > AFAICT the implementation of `match*` is not designed to handle the task
> > of matching against several patterns to select which branch to use.
> I do not follow you.  Could you please describe the issue more concretely?
> Pehraps wiht an example  Then I could judge whether this is grave.

When matching EXP against patterns PAT1..PATn, Pcase is careful to share
the common part of those patterns in the resulting code, so that the
resulting code will not test (consp EXP) more than once, for example.

Try (cond* ((match* `(a1 . ,b1) EXP) ...) ((match* `(a2 . ,b2) EXP) ...))
and see how, before testing `a2`, it re-tests whether EXP is `consp` and
it re-extracts its `car`, even though it already just did those very
same operations.

Of course, the same happens with my PoC `pcase*` addition to `cond*`.
But not if you do (pcase EXP (`(a1 . ,b1) ...) (`(a2 . ,b2) ...)).


        Stefan

Re: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

Rewriting clause by clause is an interesting idea.
However, there are problems to solve.

  > Throw away cond*-subpat.  Just rewrite

cond* has extended the patterns.
This would discard those extensions, so I have to say no.

Rewriting using pcase could be acceptable if those extensions are
implemeted in pcase.  You would be able to do that, if you want to.

  >     (cond*
  >      ((match* PAT FORM) THEN)
  >      . ELSE)

That method works for exiting match* clauses, and this

      > (cond*
      >  ((match* PAT FORM))
      >  . REST)

for empty no-exit match* clauses, But there are also nonempty ni-exit
clauses:

  >     (cond*
  >      (:no-exit (match* PAT FORM) THEN)
  >      . ALWAYS)

Can rewriting handle that?

-- 
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: Installing cond* in core

[Stefan Monnier]

> But there are also nonempty ni-exit clauses:
>
>   >     (cond*
>   >      (:no-exit (match* PAT FORM) THEN)
>   >      . ALWAYS)
>
> Can rewriting handle that?

Most likely, yes, tho I have no idea what the above means and haven't
seen the corresponding doc&code, so I can't guarantee it.

Assuming it means "if PAT matches, execute THEN (with the corresponding
bindings) for its side effects, and in all cases continue with ALWAYS
without PAT's bindings", then it's just

    (progn (pcase FORM ((PAT THEN)))
           (cond* . ALWAYS))

so that would be trivial to add, of course.


- Stefan

Re: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > When matching EXP against patterns PAT1..PATn, Pcase is careful to share
  > the common part of those patterns in the resulting code, so that the
  > resulting code will not test (consp EXP) more than once, for example.

Now I understand.  It is a good optimization.

-- 
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: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > > But there are also nonempty ni-exit clauses:
  > >
  > >   >     (cond*
  > >   >      (:no-exit (match* PAT FORM) THEN)
  > >   >      . ALWAYS)
  > >
  > > Can rewriting handle that?

  > Assuming it means "if PAT matches, execute THEN (with the corresponding
  > bindings) for its side effects, and in all cases continue with ALWAYS
  > without PAT's bindings", then it's just

The bindings cover both THEN and ALWAYS.

-- 
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: Installing cond* in core

[Stefan Monnier]

>   > > But there are also nonempty ni-exit clauses:
>   > >
>   > >   >     (cond*
>   > >   >      (:no-exit (match* PAT FORM) THEN)
>   > >   >      . ALWAYS)
>   > >
>   > > Can rewriting handle that?
>
>   > Assuming it means "if PAT matches, execute THEN (with the corresponding
>   > bindings) for its side effects, and in all cases continue with ALWAYS
>   > without PAT's bindings", then it's just
>
> The bindings cover both THEN and ALWAYS.

Then I don't understand what's the intended semantics: how can you use
PAT's bindings over ALWAYS when PAT failed to match?


        Stefan

Re: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > Then I don't understand what's the intended semantics: how can you use
  > PAT's bindings over ALWAYS when PAT failed to match?

It makes bindings for all the variables it could bind, independent of
which ones matched in a given case.

pcase does that to, I found out by experiment.

-- 
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: Installing cond* in core

[Stefan Monnier]

>   > Then I don't understand what's the intended semantics: how can you use
>   > PAT's bindings over ALWAYS when PAT failed to match?
> It makes bindings for all the variables it could bind, independent of
> which ones matched in a given case.

I don't understand, sorry.  Can you give some examples?

> pcase does that to, I found out by experiment.

Same here.  Are you referring to cases such as

    (pcase EXP
      ((or `(,a ,b)
           5)
       (BODY)))

where `a` and `b` will be bound to nil when EXP evaluates to 5?


        Stefan

Re: Installing cond* in core

[Lynn Winebarger]

On Sat, Jan 27, 2024 at 4:37 PM Stefan Kangas <stefankangas@gmail.com> wrote:
[nice sentiments, but then...]
> If it is true that Python "can be seen as a dialect of Lisp with
> 'traditional' syntax",[2] then perhaps it is our turn to take a cue
> from them.
[...]
> [2]  https://norvig.com/python-lisp.html

How about even if that claim is false?  Because the modern inheritor
of lisp implementation technology is clearly Javascript, at least in
V8.  Among other things, the heap can be dumped for later loading
(again, V8-specific as far as I know).  And my experience is that
Norvig's classification of Python's storage management as "automatic"
to be questionable.
This observation is completely off-topic, of course.

Lynn

Re: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

Having expressions represented as lists, so that programs can easily
operate on them, is the heart of Lisp.  Languages which don't do that
may have a partial resemblance to Lisp, but they also have a major
difference from Lisp.

-- 
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: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > Same here.  Are you referring to cases such as

  >     (pcase EXP
  >       ((or `(,a ,b)
  >            5)
  >        (BODY)))

  > where `a` and `b` will be bound to nil when EXP evaluates to 5?

Yes.

-- 
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: Installing cond* in core

[Stefan Monnier]

>   > Same here.  Are you referring to cases such as
>
>   >     (pcase EXP
>   >       ((or `(,a ,b)
>   >            5)
>   >        (BODY)))
>
>   > where `a` and `b` will be bound to nil when EXP evaluates to 5?
>
> Yes.

O, but here the (overall) pattern *does* match, and the semantics can be
described as: any variable that is not bound by the specific match but
that could be bound by other ways to match the pattern gets
a nil binding.

In the case of

    (cond*
     (:no-exit (match* PAT FORM) THEN)
     . ALWAYS)

does that mean that the semantics you provide is in ALWAYS, the vars
bound by PAT are bound to the matched values when PAT did match and they
are all bound to nil otherwise?
Or can some of the vars in PAT get bound to a non-nil value when PAT
fails to match?  If so, which ones?


        Stefan

Re: Installing cond* in core

[Peter Hull]

I'd like to follow along with this - please could someone remind me
where I can find the latest implementation of cond*? I know I've seen
it as a patch submitted to this list but I can't seem to find it now,
and "cond*" does not seem to be a search-engine-friendly term (even
emacs-devel's namazu struggles)
Thanks,
Peter

Re: Installing cond* in core

[Lynn Winebarger]

On Sun, Mar 17, 2024 at 10:41 PM Richard Stallman <rms@gnu.org> wrote:
> Having expressions represented as lists, so that programs can easily
> operate on them, is the heart of Lisp.  Languages which don't do that
> may have a partial resemblance to Lisp, but they also have a major
> difference from Lisp.

My response was a bit tongue-in-cheek, but I did restrict it to "lisp
implementation technology".  If someone on this list wants to learn
about efficient implementation techniques for a dynamically typed and
interactive language that might be ported to emacs lisp, they would be
better served by studying the v8 implementation than python's
internals.  Especially when it comes to, say, multi-threaded parallel
processing, garbage collection, specializing compiled code for
dynamically typed objects, and similar topics of interest.  IMNSHO.

Lynn

Re: Installing cond* in core

[Richard Stallman]

[[[ 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. ]]]

  > does that mean that the semantics you provide is in ALWAYS, the vars
  > bound by PAT are bound to the matched values when PAT did match and they
  > are all bound to nil otherwise?

That is what makes sense, and that is what I think the code does.

-- 
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: Installing cond* in core

[Stefan Monnier]

> [[[ 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. ]]]
>
>   > does that mean that the semantics you provide is in ALWAYS, the vars
>   > bound by PAT are bound to the matched values when PAT did match and they
>   > are all bound to nil otherwise?
>
> That is what makes sense, and that is what I think the code does.

OK, so it "behaves the same" as what Pcase does for `(or PAT _)`.
The semantics sounds fine, then and would be easy enough to reproduce with Pcase.
I wonder how often this :no-exit form is useful, tho.


        Stefan