Re: Re: cond*

Re: Re: cond*

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

Richard writes:
> [[[ 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. ]]]
>
> Fall-through clauses are an important feature of cond* and a big
> advance in flexibility.  Precisely how to indicate one is a detail,
> and I've proposed three ways to design that:
>
> * A clause with one element.
> * A clause that starts with t.
> * A clause that starts with nil.
> * A keyword.
>
> If you have preferences about that detail, please let me know.
> I am also interested in other suggestions, but I will only accept
> it if it is as natural and simple as those above.

Hi,

wouldn't a clause starting with t be the most natural choice?
Just because it would mimic cond and make things consistent.

My .02cents,
/PA

--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1545 bytes --]

Re: Re: cond*

[Bob Rogers]

   From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
   Date: Sat, 23 Dec 2023 07:17:09 +0100

   Richard writes:

   > Fall-through clauses are an important feature of cond* and a big
   > advance in flexibility.  Precisely how to indicate one is a detail,
   > and I've proposed three ways to design that . . .

   Hi,

   wouldn't a clause starting with t be the most natural choice?
   Just because it would mimic cond and make things consistent.

   My .02cents,
   /PA

I fail to see how using "t" is consistent with cond.  Syntactically,
perhaps, but cond uses "t" to indicate an unconditional final test.
Richard is looking for a syntatic indicator for a fall-through clause,
which is the exact opposite thing semantically, a sure-fire source of
confusion IHMO.

   In fact, none of Richard's "three" options strike me as truly
palatable:

   * A clause with one element.  This seems to be Richard's preferred
option, and I can see the appeal, as it is simple, but it would be easy
to miss, and is also unlike the corresponding cond semantics.

   * A clause that starts with t.  This is a big semantic clash with
cond, as already described.

   * A clause that starts with nil.  Possibly confusing, but at least it
could make people realize that there's something subtle going on here,
and maybe they should do C-h f before proceeding.

   * A keyword.  Perhaps the ugliest, but it has the advantage of being
the most explicit about saying what's going to happen.

   Personally, I prefer the keyword, but for the sake of full
disclosure, I'm the one who suggested it (at the end of the clause,
though).  As further full disclosure, I don't use pcase, and haven't
really had to learn it, so I doubt I'm going to use cond* much, if at
all.  So you don't need to give my opinion much weight.  However, I did
want to point out what I thought was a severe drawback of using "t",
since no one else seemed to have noticed.

					-- Bob Rogers

RE: [External] : Re: Re: cond*

[Drew Adams]

> I fail to see how using "t" is consistent with cond.  Syntactically,
> perhaps, but cond uses "t" to indicate an unconditional final test.
> Richard is looking for a syntatic indicator for a fall-through clause,
> which is the exact opposite thing semantically, a sure-fire source of
> confusion IHMO.
> 
> In fact, none of Richard's "three" options strike me as truly
> palatable:
> 
> * A clause with one element.  This seems to be Richard's preferred
>   option, and I can see the appeal, as it is simple, but it would be easy
>   to miss, and is also unlike the corresponding cond semantics.
> 
> * A clause that starts with t.  This is a big semantic clash with
>   cond, as already described.
> 
> * A clause that starts with nil.  Possibly confusing, but at least it
>   could make people realize that there's something subtle going on here,
>   and maybe they should do C-h f before proceeding.
> 
> * A keyword.  Perhaps the ugliest, but it has the advantage of being
>   the most explicit about saying what's going to happen.
> 
> Personally, I prefer the keyword, but for the sake of full
> disclosure, I'm the one who suggested it (at the end of the clause,
> though).  As further full disclosure, I don't use pcase, and haven't
> really had to learn it, so I doubt I'm going to use cond* much, if at
> all.  So you don't need to give my opinion much weight.  However, I did
> want to point out what I thought was a severe drawback of using "t",
> since no one else seemed to have noticed.

Yes, this is essentially what I and others
have said.  It might be less confusing if
the name `cond*' weren't used, as that
really invites exactly such confusion.

`cond' doesn't have any "fall-through'
behavior - and rightfully so.  As soon as
you start mixing match/bind-only sexps
with conditional clauses that can return
from the form, you introduce a need to
clearly scope the former wrt the latter.

Something like `let[*]' clearly separates
the bindings from the `progn' behavior
that performs actions and returns the
form's value.

Something like `cond' clearly separates
its clauses that can perform actions and
return the form's value.  And each `cond'
clause contains a test.  And if it
contains only a test then its value, if
evaluated to non-nil, is the return value
of the `cond'.

IIUC, `cond*', on the other hand, allows
match/binding forms either inside an
action/return conditional clause or on
their own.

Richard says:

  Fall-through clauses are an important
  feature of cond* and a big advance in
  flexibility.  Precisely how to indicate
  one is a detail, and I've proposed three
  ways to design that:

  * A clause with one element.

Hard to notice (what prompted me to reply
to this thread).

  * A clause that starts with t.

Confusion with `cond's very different t.

  * A clause that starts with nil.

Confusion with `cond's very different nil.

  * A keyword.

Doable, but still not very satisfying, IMO.
___

I'm _no expert_ on `pcase' and its family.
I'm not particularly a fan of it, a priori.

I especially think it's clearer to use
other things, such as `cl-case' or the
usual conditionals, not equivalent `pcase'
sexps, when the latter is overkill.  E.g.,
when `cl-case' does the job, it's clearer.

But `pcase', like `cond' (and `cl-case')
at least has only clauses that each can 
return a value for the `pcase'.  And each
clause must have a pattern.

And bindings created by a pattern are in
effect only for the clause containing
that pattern.

`cond*' differs in all of those respects.
In all of those respects it seems weaker
and more confusing.

Associating each pattern with actions
and a return-value is important for a
clear syntax, IMO.  (A zero-action
`pcase' returns a non-nil pattern value
- just like `cond'.)

`pcase' syntax is complex, but at least
its overall structure is simple: a list
of clauses, each of which has a pattern
sexp and zero-or-more body sexps.

RE: [External] : Re: Re: cond*

[Bob Rogers]

   From: Drew Adams <drew.adams@oracle.com>
   Date: Mon, 25 Dec 2023 03:49:30 +0000

   > I fail to see how using "t" is consistent with cond . . .
   > 
   > In fact, none of Richard's "three" options strike me as truly
   > palatable . . .
   > 
   > . . . I did want to point out what I thought was a severe drawback
   > of using "t", since no one else seemed to have noticed.

   Yes, this is essentially what I and others
   have said.  It might be less confusing if
   the name `cond*' weren't used, as that
   really invites exactly such confusion . . .

If I have not added anything by my inattention, then I apologize for not
reading your (and others') posts more closely.  At least we seem to be
on the same page re cond*.

					-- Bob

Re: [External] : Re: Re: 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. ]]]

  > Yes, this is essentially what I and others
  > have said.  It might be less confusing if
  > the name `cond*' weren't used, as that
  > really invites exactly such confusion.

`cond*' means "much like `cond', but with some differences."  That
fits this feature and it's a natural name.  Once you get used to the
differences, if you permit yourself to do so.  Fortunately, what there
is to learn for `cond*' is far less than for `pcase'.

I'd be willing to use a different name if it is better.  Do you have
any suggestions for another name?

-- 
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: [External] : Re: Re: cond*

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: rogers@rgrjr.com, paaguti@gmail.com, emacs-devel@gnu.org
> Date: Thu, 28 Dec 2023 22:51:39 -0500
> 
> I'd be willing to use a different name if it is better.  Do you have
> any suggestions for another name?

Two candidates I can think of are 'case' and 'case*'.

(But I personally have no problem with 'cond*', and don't see Drew's
objections in this matter as serious ones.)

Re: [External] : Re: Re: 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. ]]]

  > > I'd be willing to use a different name if it is better.  Do you have
  > > any suggestions for another name?

  > Two candidates I can think of are 'case' and 'case*'.

If its name were `case', or based on `case', I think the same people
who expect `cond*' to imply a close similarity to `cond', would expect
`case*' to imply an equally close similarity to `cl-case'.  They would
be disappointed in te same way.  `cl-case' has no unconditional clauses.

I think this construct is closer to `cond' than to `cl-case', so the
name `cond*' is better.  Also, `cond' is more generic, which makes it
more suitable as a base from which a construct like this can branch off.

-- 
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: [External] : Re: Re: 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. ]]]

  >   * A clause that starts with t.

  > Confusion with `cond's very different t.

It's different, but that's the point of the * in cond*.

  >   * A clause that starts with nil.

  > Confusion with `cond's very different nil.

There is no such thibg as "cond's nil".  nil is not used to start a
cond clause.  We know what it would do there, but we never do that,
because it is useless.

nil as the first element of a cond* clause would act as a waving flag
that says, "Remember, this is different from cond."

  >   * A keyword.

  > Doable, but still not very satisfying, IMO.

Those are the four methods I have thought of.  Any of them would work,
so if people prefer the keyword approach, I'll support that one.

If you think of a better way of indicating this feature, please
suggest it to me.  If it is clearer, I could use 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: 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. ]]]

  > wouldn't a clause starting with t be the most natural choice?
  > Just because it would mimic cond and make things consistent.

A no-exit clause in cond* executes unconditionally but does not
terminate the cond*.  A cond clause that start with t does terminate
the cond, which is why it is useful only as the last clause.

The no-exit clause in cond* is an extension in capability over cond.
It is not the same as any way of using cond itself.  Whatever syntax
is used to specify a no-exit clause will not be parallel to the syntax
of cond.

That's not a reason there shouldn't be a new feature.

These are the four choices that seem plausible:

> * A clause with one element.
> * A clause that starts with t.
> * A clause that starts with nil.
> * A keyword.

I am interested in people's preferences between them.

If a no-exit clause is indicated by its first element, then a final
element in the clause, with no side effects, will make no difference
unless that clause is the last clause.  But if it is the last clause,
there is no need to make it a "no-exit" clause.

So you could add a keyword at the end -- :no-exit or :fall-through or
whatever you like -- and it would not change anything, but might serve
as a kind of comment.

A real comment, perhaps `;; no-exit clause', could serve the same
purpose.

You could add them at the beginning, too.

-- 
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)