[HN Gopher] An alternate pattern-matching conditional for Elisp
       ___________________________________________________________________
        
       An alternate pattern-matching conditional for Elisp
        
       Author : signa11
       Score  : 75 points
       Date   : 2024-03-14 23:52 UTC (1 days ago)
        
 (HTM) web link (lwn.net)
 (TXT) w3m dump (lwn.net)
        
       | djaouen wrote:
       | I am not familiar with `pcase` in Elisp, but `case` is a
       | perennial favorite in languages like Elixir and Lisp Flavored
       | Erlang. I hope `cond*` doesn't deviate too far from this norm.
        
       | phoe-krk wrote:
       | _> (...) there would be no effort to switch away from pcase,
       | however, as it is  "to be considered a matter of stylistic
       | preference"._
       | 
       | I'm sometimes glad that the CL standard is frozen.
       | 
       | Sarcasm aside, this is literally https://xkcd.com/927/.
       | 
       | Sarcasm aside for real this time, getting this sort of binding
       | mechanism in a COND-like form is unusual. This effectively means
       | that a programmer needs to inspect all previous COND* forms,
       | instead of relying on lexical scope AND indentation as they
       | normally would, to see where new bindings are made. This is like
       | Common Lisp's LOOP, but even there bindings are only allowed at
       | the beginning of the loop, before any iteration clauses.
        
         | 48864w6ui wrote:
         | It may be unusual, but binding is the point of pattern
         | matching. Expressions take a bunch of bindings and give a
         | value; patterns take a value and give a bunch of bindings.
        
           | lispm wrote:
           | Scope of the bindings is the problem, not the bindings
           | itself.
        
             | 48864w6ui wrote:
             | I had assumed bindings would be scoped to their branch; if
             | they leak, yeah, definitely problematic.
        
         | hibbelig wrote:
         | I think you need to go down the conditionals in order anyway,
         | if cond* it's like cond in that it evaluates the conditions top
         | to bottom. So keeping track of "all the bindings so far" makes
         | intuitive sense to me.
         | 
         | I also see a parallel to if/else if/else cascades. You can
         | "break" and else if leg into ... else { zzz; if (...) ... } and
         | then you can declare new variables at the zzz spot that are
         | then available for the rest of the cascade.
         | 
         | I don't know much about pcase and cond* so I can't speak to the
         | more general point. I just wanted to mention one specific
         | aspect.
         | 
         | I miss emacs but as a Java developer what can you do...
        
           | lispm wrote:
           | Evaluating conditions don't introduce bindings in COND. In
           | Lisp typically bindings are only introduced in forms together
           | with scope: DEFUN, LET, and a lot of other constructs.
           | Binding construct which affect forms outside its syntactic
           | scope is rare in Lisp.
           | 
           | In Scheme there is sometimes:                   (define (foo)
           | (define a 10)           (+ a 42))
           | 
           | But even there all the embedded "define"s, by standard, need
           | to be at the top of the body, directly at the start.
        
         | alwaysbeconsing wrote:
         | Agree, it is Curse of Lisp mixed in NIH syndrome. Syntax of
         | cond* is no more straightforward than that of pcase. As was
         | pointed out on mailing list. Awkward decision by maintainers to
         | keep both into core.
        
       | lispm wrote:
       | the documentation of pcase:
       | https://www.gnu.org/software/emacs/manual/html_node/elisp/pc...
       | 
       | first cond* version: https://lwn.net/ml/emacs-
       | devel/E1rQJDv-0001UG-2E@fencepost.g...
        
       | asQuirreL wrote:
       | `cond*` reads more like `do` notation in Haskell than `match`.
        
       ___________________________________________________________________
       (page generated 2024-03-16 23:02 UTC)