* Re: Re: cond*
@ 2023-12-23 6:17 Pedro Andres Aranda Gutierrez
2023-12-25 1:32 ` Bob Rogers
2023-12-26 4:03 ` cond* Richard Stallman
0 siblings, 2 replies; 9+ messages in thread
From: Pedro Andres Aranda Gutierrez @ 2023-12-23 6:17 UTC (permalink / raw)
To: Richard Stallman, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: cond* 2023-12-23 6:17 Re: cond* Pedro Andres Aranda Gutierrez @ 2023-12-25 1:32 ` Bob Rogers 2023-12-25 3:49 ` [External] : " Drew Adams 2023-12-26 4:03 ` cond* Richard Stallman 1 sibling, 1 reply; 9+ messages in thread From: Bob Rogers @ 2023-12-25 1:32 UTC (permalink / raw) To: Richard Stallman, Pedro Andres Aranda Gutierrez; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [External] : Re: Re: cond* 2023-12-25 1:32 ` Bob Rogers @ 2023-12-25 3:49 ` Drew Adams 2023-12-25 4:53 ` Bob Rogers ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Drew Adams @ 2023-12-25 3:49 UTC (permalink / raw) To: Bob Rogers, Richard Stallman, Pedro Andres Aranda Gutierrez; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [External] : Re: Re: cond* 2023-12-25 3:49 ` [External] : " Drew Adams @ 2023-12-25 4:53 ` Bob Rogers 2023-12-29 3:51 ` Richard Stallman 2023-12-29 3:51 ` Richard Stallman 2 siblings, 0 replies; 9+ messages in thread From: Bob Rogers @ 2023-12-25 4:53 UTC (permalink / raw) To: Drew Adams; +Cc: Richard Stallman, Pedro Andres Aranda Gutierrez, emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Re: Re: cond* 2023-12-25 3:49 ` [External] : " Drew Adams 2023-12-25 4:53 ` Bob Rogers @ 2023-12-29 3:51 ` Richard Stallman 2023-12-29 7:11 ` Eli Zaretskii 2023-12-29 3:51 ` Richard Stallman 2 siblings, 1 reply; 9+ messages in thread From: Richard Stallman @ 2023-12-29 3:51 UTC (permalink / raw) To: Drew Adams; +Cc: rogers, paaguti, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Re: Re: cond* 2023-12-29 3:51 ` Richard Stallman @ 2023-12-29 7:11 ` Eli Zaretskii 2023-12-31 3:15 ` Richard Stallman 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2023-12-29 7:11 UTC (permalink / raw) To: rms; +Cc: drew.adams, rogers, paaguti, emacs-devel > 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.) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Re: Re: cond* 2023-12-29 7:11 ` Eli Zaretskii @ 2023-12-31 3:15 ` Richard Stallman 0 siblings, 0 replies; 9+ messages in thread From: Richard Stallman @ 2023-12-31 3:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] : Re: Re: cond* 2023-12-25 3:49 ` [External] : " Drew Adams 2023-12-25 4:53 ` Bob Rogers 2023-12-29 3:51 ` Richard Stallman @ 2023-12-29 3:51 ` Richard Stallman 2 siblings, 0 replies; 9+ messages in thread From: Richard Stallman @ 2023-12-29 3:51 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: cond* 2023-12-23 6:17 Re: cond* Pedro Andres Aranda Gutierrez 2023-12-25 1:32 ` Bob Rogers @ 2023-12-26 4:03 ` Richard Stallman 1 sibling, 0 replies; 9+ messages in thread From: Richard Stallman @ 2023-12-26 4:03 UTC (permalink / raw) To: Pedro Andres Aranda Gutierrez; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-12-31 3:15 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-12-23 6:17 Re: cond* Pedro Andres Aranda Gutierrez 2023-12-25 1:32 ` Bob Rogers 2023-12-25 3:49 ` [External] : " Drew Adams 2023-12-25 4:53 ` Bob Rogers 2023-12-29 3:51 ` Richard Stallman 2023-12-29 7:11 ` Eli Zaretskii 2023-12-31 3:15 ` Richard Stallman 2023-12-29 3:51 ` Richard Stallman 2023-12-26 4:03 ` cond* Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.