Re: Instead of pcase

[T.V Raman]

Philip Kaludercic <philipk@posteo.net> writes:


RMS' message makes some very valuable points re specialized languages
like pcase -- pcase has its strengths, but in general, it's definitely
not easy to understand complex code that leverages it -- as an example:

I recently tried to understand some of the completion code; --
specifically, completion-at-point, and immediately hit the pcase wall
and gave up --- my lack of understanding of pcase made that code in
Emacs Core read like line-noise.
> Richard Stallman <rms@gnu.org> writes:
>
>> I can see why people want something along those lines.  Using `cond'
>> and `let' to do these jobs feels long-winded and cumbersome; they were
>> not designed to make this easy.  So we wish for something to make such
>> code more concise.
>
> [...]
>
>> 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.
>
> The critical feature of pcase is pattern matching.  The complexity of
> `pcase' is the extensibility -- a lisp-like flexibility that makes it so
> attractive -- that a simpler macro might not need.  The question is, if
> one would restrict pcase to just matching expressions using ` and , like
>
>   (pcase sexp ;match various top-level constructs
>     (`(defun ,name ,args ,body) ...)
>     (`(defvar ,name, ,value) ...)
>     (`(require ',symbol) ...)
>     ...)
>
> would that be simple enough in your opinion?  Anyone familiar with
> ML-style functional programming, Prolog or the notion of unification
> should be able to understand this quickly enough, I assume?
>

--