Creating a git branch for cond*

Creating a git branch for cond*

[Alan Mackenzie]

Hello, Richard, Eli, and Emacs.

Richard posted some embryonic code for cond* a little over a week ago.

To move things forward, I propose creating the git branch
feature/condstar, and incorporating the new code into it in
lisp/emacs-lisp/condstar.el.  This will enable its development to happen
more systematically and rapidly.

Does anybody have any objections?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Creating a git branch for cond*

[Eli Zaretskii]

> Date: Thu, 25 Jan 2024 15:48:18 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Richard, Eli, and Emacs.
> 
> Richard posted some embryonic code for cond* a little over a week ago.
> 
> To move things forward, I propose creating the git branch
> feature/condstar, and incorporating the new code into it in
> lisp/emacs-lisp/condstar.el.  This will enable its development to happen
> more systematically and rapidly.
> 
> Does anybody have any objections?

You intend to maintain that branch personally?  If you intend for
Richard to do that, it's up to him, I think.  Having more than one
branch in a repository complicates Git-related workflows, and could
cause problems if the user pushes to the wrong branch.  So it is not
an easy decision.

Re: Creating a git branch for cond*

[Alan Mackenzie]

Hello, Eli.

On Thu, Jan 25, 2024 at 17:53:51 +0200, Eli Zaretskii wrote:
> > Date: Thu, 25 Jan 2024 15:48:18 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Hello, Richard, Eli, and Emacs.

> > Richard posted some embryonic code for cond* a little over a week ago.

> > To move things forward, I propose creating the git branch
> > feature/condstar, and incorporating the new code into it in
> > lisp/emacs-lisp/condstar.el.  This will enable its development to happen
> > more systematically and rapidly.

> > Does anybody have any objections?

> You intend to maintain that branch personally?

I'm prepared to do that, yes.

> If you intend for Richard to do that, it's up to him, I think.

Richard will surely respond to my last post.  Let's see what he says.

> Having more than one branch in a repository complicates Git-related
> workflows, and could cause problems if the user pushes to the wrong
> branch.  So it is not an easy decision.

It's clear from my code reviewing so far that cond* is not yet ready for
prime time.  Creating a branch for it would be, I think, the normal
thing in Emacs development.

My main motivation is not to let the current impetus peter out.

But let's see what Richard says.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Creating a git branch for cond*

[Eli Zaretskii]

> Date: Thu, 25 Jan 2024 16:08:37 +0000
> Cc: rms@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> My main motivation is not to let the current impetus peter out.

You should have no reasons to worry about that.

Re: Creating a git branch for cond*

[Alfred M. Szmidt]

   Hello, Richard, Eli, and Emacs.

   Richard posted some embryonic code for cond* a little over a week ago.

   To move things forward, I propose creating the git branch
   feature/condstar, and incorporating the new code into it in
   lisp/emacs-lisp/condstar.el.  This will enable its development to happen
   more systematically and rapidly.

   Does anybody have any objections?

I hope it goes to master directly, it is a single file that doesn't
affect anything else.  And _if_ existing code is updated to use cond*
that will get much more milage.

Nothing should really stop development if this lives on master, or a
branch.

Re: Creating a git branch for cond*

[Alan Mackenzie]

Hello, Alfred.

On Thu, Jan 25, 2024 at 11:16:43 -0500, Alfred M. Szmidt wrote:

>    Hello, Richard, Eli, and Emacs.

>    Richard posted some embryonic code for cond* a little over a week ago.

>    To move things forward, I propose creating the git branch
>    feature/condstar, and incorporating the new code into it in
>    lisp/emacs-lisp/condstar.el.  This will enable its development to happen
>    more systematically and rapidly.

>    Does anybody have any objections?

> I hope it goes to master directly, it is a single file that doesn't
> affect anything else.  And _if_ existing code is updated to use cond*
> that will get much more milage.

It does affect other things, in particular, other .el files which are
adapted to use cond*.  If that happens on master, then both cond* and
the conversion need to be perfect before the file can be committed.  On
a branch, things can be a lot less constrained.

What I want to do early on in cond* development is convert
lisp/emacs-lisp/macroexp.el from pcase to cond*.  Currently, pcase.el is
dependent upon macroexp.el and macroexp.el is dependent upon pcase.el.
This leads to an unlovely artifice in the bootstrapping file, loadup.el,
and this has caused me grief in another branch I'm working on.

cond* has no dependency on macroexp.el, so could simply be loaded as the
fourth file, after debug-early.el, byte-run.el, backquote.el.  Having
macroexp.el loaded as the fifth file (rather than the 17th, as it
currently is) would simplify the initial loadup appreciably.

No doubt Eli will have something to say about this idea.  ;-)

> Nothing should really stop development if this lives on master, or a
> branch.

There are advantages to the branch, as well as advantages to having it
on master.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Creating a git branch for cond*

[Alfred M. Szmidt]

   What I want to do early on in cond* development is convert
   lisp/emacs-lisp/macroexp.el from pcase to cond*.  Currently, pcase.el is
   dependent upon macroexp.el and macroexp.el is dependent upon pcase.el.
   This leads to an unlovely artifice in the bootstrapping file, loadup.el,
   and this has caused me grief in another branch I'm working on.

Wouldn't it make more sense to put _those_ changes on a branch when
cond* is on master?  macroexp.el changes would have much more
significant impact on things than just adding cond*.  And when cond*
is modified in a significant matter, it would be easy to rebase the
branch accordingly.

The additional beneift would be that one would have good examples of
where cond* is much clearer than pcase.

Re: Creating a git branch for cond*

[Eli Zaretskii]

> Date: Thu, 25 Jan 2024 16:37:44 +0000
> Cc: rms@gnu.org, eliz@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I hope it goes to master directly, it is a single file that doesn't
> > affect anything else.  And _if_ existing code is updated to use cond*
> > that will get much more milage.
> 
> It does affect other things, in particular, other .el files which are
> adapted to use cond*.

Please don't make any changes except installing cond* and fixing it.
There's no decision yet to start converting any code to use it, nor do
I envision such a decision any time soon.

> If that happens on master, then both cond* and
> the conversion need to be perfect before the file can be committed.

Once again: we are not converting anything, at least not yet.  We are
only discussing how best to handle installation of cond*.

> What I want to do early on in cond* development is convert
> lisp/emacs-lisp/macroexp.el from pcase to cond*.

I don't agree with such a change, so please don't do anything like
that.

> Currently, pcase.el is dependent upon macroexp.el and macroexp.el is
> dependent upon pcase.el.  This leads to an unlovely artifice in the
> bootstrapping file, loadup.el, and this has caused me grief in
> another branch I'm working on.

We are not going to make any such changes just because we can, or just
because you have problems on some branch you'd like to avoid fixing.
cond* is a new construct, and once it is in Emacs, and documented as
it should be, we should collect experience with using it before we
even think about converting existing code.

Please don't forget that Emacs is a stable program: we don't make
changes just because we can.  Changes to code that was with us for
years are only justified if we have a very good reason.

> No doubt Eli will have something to say about this idea.  ;-)

He does, see above.  You don't have my okay for making any changes
except installing cond* and fixing it and its documentation.

Btw, we should also have tests for it.

> There are advantages to the branch, as well as advantages to having it
> on master.

Yes.  But, as you say, let's hear what Richard thinks about this.

Re: Creating a git branch for cond*

[Alan Mackenzie]

Hello, Eli.

On Thu, Jan 25, 2024 at 18:56:05 +0200, Eli Zaretskii wrote:
> > Date: Thu, 25 Jan 2024 16:37:44 +0000
> > Cc: rms@gnu.org, eliz@gnu.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > I hope it goes to master directly, it is a single file that doesn't
> > > affect anything else.  And _if_ existing code is updated to use cond*
> > > that will get much more milage.

> > It does affect other things, in particular, other .el files which are
> > adapted to use cond*.

> Please don't make any changes except installing cond* and fixing it.
> There's no decision yet to start converting any code to use it, nor do
> I envision such a decision any time soon.

> > If that happens on master, then both cond* and
> > the conversion need to be perfect before the file can be committed.

> Once again: we are not converting anything, at least not yet.  We are
> only discussing how best to handle installation of cond*.

> > What I want to do early on in cond* development is convert
> > lisp/emacs-lisp/macroexp.el from pcase to cond*.

> I don't agree with such a change, so please don't do anything like
> that.

You know me.  I wouldn't make any such changes without asking first,
anyway.  But for people asking _why_ we're introducing cond*, that it
opens up such possibilities is a good answer.

> > Currently, pcase.el is dependent upon macroexp.el and macroexp.el is
> > dependent upon pcase.el.  This leads to an unlovely artifice in the
> > bootstrapping file, loadup.el, and this has caused me grief in
> > another branch I'm working on.

> We are not going to make any such changes just because we can, or just
> because you have problems on some branch you'd like to avoid fixing.

The point I was making is that our bootstrap procedure in loadup.el
verges on unmaintainability.  What should be a simple linear list of
..el(c) files being loaded one after the other has turned into a
difficult tree where some files are loaded from loadup, some are loaded
with (require 'foo) inside eval-when-compile, and some may be straight
requires, I can't remember exactly.  Some loaded files get unloaded
again.  (pcase.el is an example.)  macroexp.el is loaded twice (or
four times, if you count the second loadup separately).

All this has hindered me on that other branch (for bug #67455, about
getting position information into doc strings that we discussed
extensively back in November).  It is likely to hinder others, too.

My point was that cond*, once it's established, will give us the
mechanism to sort at least some of this out.

> cond* is a new construct, and once it is in Emacs, and documented as
> it should be, we should collect experience with using it before we
> even think about converting existing code.

> Please don't forget that Emacs is a stable program: we don't make
> changes just because we can.  Changes to code that was with us for
> years are only justified if we have a very good reason.

Understood.

> > No doubt Eli will have something to say about this idea.  ;-)

> He does, see above.  You don't have my okay for making any changes
> except installing cond* and fixing it and its documentation.

> Btw, we should also have tests for it.

Indeed.  They will be needed to get the code working properly anyway.

> > There are advantages to the branch, as well as advantages to having it
> > on master.

> Yes.  But, as you say, let's hear what Richard thinks about this.

Yes.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Creating a git branch for cond*

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> What I want to do early on in cond* development is convert
> lisp/emacs-lisp/macroexp.el from pcase to cond*.

I think such a decision should strongly involve the people mainly
responsible for maintaining that file.  Here are the top 5 contributors
to that file, going by number of lines:

 501 Stefan Monnier
 136 Mattias Engdegård
  88 Miles Bader
  39 Paul Eggert
  18 Alan Mackenzie

Going by number of commits, it looks something much like that (though
Eggert has more commits than Bader).

Re: Creating a git branch for cond*

[Alan Mackenzie]

Hello, Stefan.

On Thu, Jan 25, 2024 at 11:47:36 -0800, Stefan Kangas wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > What I want to do early on in cond* development is convert
> > lisp/emacs-lisp/macroexp.el from pcase to cond*.

> I think such a decision should strongly involve the people mainly
> responsible for maintaining that file.

Of course.  It should be a decision reached factually after open
discussion on this mailing list.  I believe the benefits of this change
would be substantial, as outlined in another post.  But that is to be
demonstrated after cond* is up and running.

> Here are the top 5 contributors to that file, going by number of
> lines:

>  501 Stefan Monnier
>  136 Mattias Engdegård
>   88 Miles Bader
>   39 Paul Eggert
>   18 Alan Mackenzie

> Going by number of commits, it looks something much like that (though
> Eggert has more commits than Bader).

Miles is no longer actively contributing to Emacs (unfortunately).  If I
remember correctly, he was the prime mover in implementing lexical
binding, which probably explains his high activity with this file.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Creating a git branch for cond*

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

cond* is just one file, and no change in anyplace else is needed to
get it working and make it usable.  So there should be no need for a
branch for it.

-- 
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: Creating a git branch for cond*

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: acm@muc.de, emacs-devel@gnu.org
> Date: Sun, 28 Jan 2024 22:19:24 -0500
> 
> cond* is just one file, and no change in anyplace else is needed to
> get it working and make it usable.  So there should be no need for a
> branch for it.

The idea was to keep it on a branch until we decide it is ready to
land on master.  Having it on a branch will allow to work on
finilizing it more conveniently.  This includes solving any
significant issues and adding documentation.  I would prefer to keep
it on a branch during this (hopefully, short) period, since that would
allow us to keep its history afterwards, and will also avoid the
need to send whole files each time something changes.

Alan offered his technical help in managing this vis-a-vis Git, so you
personally don't need to worry about these aspects.  But for us,
having cond* on a branch during this period is a significant
advantage.

Re: Creating a git branch for cond*

[Jim Porter]

On 1/28/2024 7:36 PM, Eli Zaretskii wrote:
> The idea was to keep it on a branch until we decide it is ready to
> land on master.  Having it on a branch will allow to work on
> finilizing it more conveniently.  This includes solving any
> significant issues and adding documentation.  I would prefer to keep
> it on a branch during this (hopefully, short) period, since that would
> allow us to keep its history afterwards, and will also avoid the
> need to send whole files each time something changes.

One thing I especially hope for with a branch for cond* is that it would 
allow for making backwards-incompatible changes without (much) risk of 
causing problems for users of cond*. I'm open to the possibility that 
cond* is nicer than pcase (for my purposes, anyway), but I'm not sure 
yet. A branch would make it easier for me to track any changes to cond* 
and try my hand at rewriting some pcase-based code to use cond*. Such an 
attempt might reveal some area of improvement for cond*, and it would be 
a shame if it were too late to do anything about it. (Of course, we 
could probably change cond* in backwards-incompatible ways up until 
Emacs 30.1 or so, but I think it'd be nicer for everyone if it were 
mostly-stable by the time it hits master so that people who prefer it 
can start using it without worrying much about breaking changes.)

Re: Creating a git branch for cond*

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

  > The idea was to keep it on a branch until we decide it is ready to
  > land on master.  Having it on a branch will allow to work on
  > finilizing it more conveniently.  This includes solving any
  > significant issues and adding documentation.  I would prefer to keep
  > it on a branch during this (hopefully, short) period, since that would
  > allow us to keep its history afterwards, and will also avoid the
  > need to send whole files each time something changes.

I really don't want it to be in a branch, but I can commit some of the
past versions before committing te current versions.  I figure to start
with the earliet version that's not drastically different.  WDYT?
-- 
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: Creating a git branch for cond*

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: acm@muc.de, emacs-devel@gnu.org
> Date: Thu, 01 Feb 2024 22:40:24 -0500
> 
>   > The idea was to keep it on a branch until we decide it is ready to
>   > land on master.  Having it on a branch will allow to work on
>   > finilizing it more conveniently.  This includes solving any
>   > significant issues and adding documentation.  I would prefer to keep
>   > it on a branch during this (hopefully, short) period, since that would
>   > allow us to keep its history afterwards, and will also avoid the
>   > need to send whole files each time something changes.
> 
> I really don't want it to be in a branch, but I can commit some of the
> past versions before committing te current versions.  I figure to start
> with the earliet version that's not drastically different.  WDYT?

We can start with whatever version you like.  What's important is that
all the changes since the first commit are tracked by Git, rather than
maintaining the code aside, locally on someone's machine.