Re: Instead of pcase

[T.V Raman]

Michael Heerdegen <michael_heerdegen@web.de> writes:

See my other response re pcase and its use in emacs core; specifically
completion-at-point. A good compromize might be for the pcase fan who
wrote that code to explain its use just before the function with some
comments; that would actually help someone looking at the code to
understand it, and perhaps even turn a pcase sceptic into a pcase fan.

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

--