Re: Instead of pcase

[Michael Heerdegen <michael_heerdegen@web.de>]

Richard Stallman <rms@gnu.org> writes:

> What makes `pcase' such a complication is that it introduces an
> additional "little language" that duplicates the functionality of part
> of Emacs Lisp.  Even worse, that little language is so concise it is
> downright cryptic.

It is not cryptic per se.  People are sometimes frightened by the
syntax, for some it seems to be hard to learn and understand, I don't
know why, but I accept that as a fact.

> Those of you who are fans of `pcase' may not recognize the cost it
> imposes on the Emacs Lisp language.  You paid that cost already,
> perhaps a few years ago, and perhaps you enjoy each new language
> construct you learn.  Perhaps, for you, the more complexity of
> features to be learned, the better.
>
> But don't argue that this cost does not exist, simply because it
> doesn't feel like a burden to you.

Hmm, I must say that cost was small for me.  There is also a cost of
reading a more complicated rewrite using less suited language
constructs.  And i have to pay the price each time I need to read the
more complicated rewrite, instead of only once.

> I'm looking at adapting some of the features of `pcase' into other
> constructs, so as to make type-discrimination code more concise than
> in old-fashioned Lisp, but _not_ so concise as to be cryptic and
> burdensome.

I wonder how that would look like and if it would really be simpler.  Or
if it would be structurally more or less equivalent and only avoid the
concise syntax.

Because, we need different semantic features, and we want that it's
possible for them to be combined.  I think we would more or less end
either with `pattern-case' that is like pcase but more verbose, or with
something that is simpler, but when some requirement in the code
changes, like a destructering having to be made conditional, has to be
rewritten to use a more complicated construct, or plain Elisp.


Michael.