bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31311: 27.0; doc of `pcase'


From: Drew Adams
Subject: bug#31311: 27.0; doc of `pcase'
Date: Sat, 26 May 2018 08:26:02 -0700 (PDT)

>    The manual should refer to `cl-case', not `case'.

I disagree.  My (unsolicited) 2 cents:

`case' is aliased to `cl-case', IF you load `cl.el' at
byte-compile time.  It has always been so, and it should
remain so.  Or the other way around: we should instead
alias `cl-case' to `case'.

Encouraging everyone to instead load `cl-lib.el' does _not_
provide `case'.  If `cl-lib.el' is to be the way to go then
it should itself provide the alias.

Dunno whether this lack was an oversight or deliberate, but
it is a step backward.  We now (rightfully) encourage users
to load `cl-lib.el' instead of `cl.el', but we no longer
bother to encourage loading `cl.el' at compile time to pick
up macros.

But no one should even need to load `cl-lib.el' (or `cl.el'
at compile time).  Emacs should itself have `case', prominently
and first class.

And it is fine if the Emacs `case' is also the Common Lisp
`case', or close to it.  The same should be true elsewhere:
Emacs appropriating Common Lisp constructs is fine and dandy.

But yes, of course, as long as `case' (aka `cl-case') is not
*exactly* the same as the Common Lisp `case' the two should
remain aliased, and any differences from Common Lisp should
be documented.

But users should first and foremost see `case', not `cl-case'.
It should be as prominent as `cond' and `if', `when', and
`unless' - ALL of which also exist in Common Lisp.  We don't
call them `cl-cond', `cl-if', `cl-when', and `cl-unless'!
And rightfully so.

Preload the `cl-case' definition in Emacs, call it `case',
and alias `cl-case' to it.

There is no reason to force or encourage people to use
`cl-case' instead of `case'.  The opposite is true - they
should be encouraged to use `case', not `cl-case'.  Emacs
deserves `case', and it has `case' - you just have to know
about jumping through a hoop to reveal it.

[We even had the extreme position a few years ago that an
eager-beaver mmaintainer forced names like `cl-caddr' on
Emacs.  Fortunately, that craziness was eventually rescinded.

http://lists.gnu.org/archive/html/emacs-devel/2016-02/msg01394.html
]

_______

On a related subject, `pcase', and especially its derivatives,
should be renamed.  These things are not (are no longer) about
a kind of `case'.

Their names should share a common root, yes.  But it should not
be just `p', and it should definitely not be `case'.  Their
names should have a root that suggests pattern matching and, at
least in some cases, binding/destructuring.  (Start a contest to
find a good root name. ;-))

> I did ‘s/case/cl-&/g’ in commit 468e82790f1

Too bad.  That's a step backward, not forward, IMHO.
 
> Many computer languages have an intrinsic case-ish construct, so
> it was a bit surprising for me to learn that ‘case’ in Emacs
> Lisp is actually ‘cl-case’, which has a second-class citizen
> feel.

Exactly.  And there is no need for that second-class status.
And it is _new_.  In the past everyone just used `case' in
Emacs.  And they still can, the same way, by loading `cl.el'
at byte-compile time, to pick up the macro.  They should not
need to do that.

> In using ‘cl-case’ as one of the conceptual parents of ‘pcase’, 

But it's not, really.  Maybe "parent" in the sense of design
ancestor, but not "parent" in the sense of current derivation
or resemblance.

> - Build on "expectatious programmer" mindset.  Programmers new
>   to Emacs Lisp might feel that same surprise i felt and do what
>   i did: reach for ‘cl-case’ immediately, making it a habit to
>   such an extent as to consider it intrinsic (thus, familiar).

Yes.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]