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

[Drew Adams <drew.adams@oracle.com>]

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