Re: Code for cond*

[Stefan Monnier]

>   > Your syntax (FUN VAR ARGS...) has two disadvantages in my view:
>   > - It fixes the argument to be checked as the first argument.
>   > - It does not syntactically distinguish the VAR from the normal
>   >   arguments, making a bit too magical for my taste.
> I think this is not a real disadvantage.

What makes you think so?
I doubt you'd consider coders' confusion as a feature, so what makes you
think people won't find it confusing (and/or get confused, even when
they may not realize it's confusing)?

> The more general kind of constrained variable, with `constrain', does
> not have those two limitations.

Agreed.  `constrain` is fine by me (I'd prefer a shorter word, but for
the sake of avoiding bikeshedding, I'm fine with it).

> The special nature of the first argument is something that users
> will get used to as they see many instances of cond*.

That could turn into "it's a pain they'll learn to live with".
The question is whether introducing the risk of such problems is worth
the expected upside.

I suggest you grep for `(and.*(pred` to see which existing uses of
Pcase's `pred` could take advantage of that shorthand, so we have
a better idea of what's the expected upside.

>   > Of course, there remains the question whether this usage should be
>   > the one that gets the privilege of not needing a dedicated
>   > "keyword", i.e. to allowing using it without the surrounding
>   > `pred`:
>   >     (FUN ,VAR ARGS...)
>
> If this syntax is easy to implement and doesn't cause difficulties, I'll
> go along with it if people prefer it.

That doesn't answer the important part of my question:

    Of course, there remains the question whether this usage should be
    the one that gets the privilege of not needing a dedicated
    "keyword", i.e. to allowing using it without the surrounding `pred`.


-- Stefan