(Feature request) add a new match pattern to support txexpr #7

I am a fan of match, but I do agree with your points at https://docs.racket-lang.org/txexpr/index.html#%28part..Why_not_just_use_match__quasiquote__and_so_on%29. However, there's a middle ground: add a new match pattern to support txexpr.

#lang racket

(require txexpr)

(define-match-expander txexpr
  (lambda (stx)
    (syntax-case stx ()
      [(_ tag attrs elems)
       #'(? txexpr?
            (app txexpr->list (list tag attrs elems)))])))

(match '(p ([class "foo"]) "hello" "world")
  [(txexpr t a e)
   (println t)
   (println a)
   (println e)])

Would you be interested in adding this to the library?

I am a fan of `match`, but I do agree with your points at https://docs.racket-lang.org/txexpr/index.html#%28part._.Why_not_just_use_match__quasiquote__and_so_on_%29. However, there's a middle ground: add a new match pattern to support `txexpr`. ```racket #lang racket (require txexpr) (define-match-expander txexpr (lambda (stx) (syntax-case stx () [(_ tag attrs elems) #'(? txexpr? (app txexpr->list (list tag attrs elems)))]))) (match '(p ([class "foo"]) "hello" "world") [(txexpr t a e) (println t) (println a) (println e)]) ``` Would you be interested in adding this to the library?

I have also wanted this, although of course you want want txexpr as both a function and a match expander, more like this:

;; -txexpr is the existing txexpr function

(define-match-expander txexpr
  (syntax-parser
    [(_ tag-pat:expr attrs-pat:expr elements-pat:expr)
     #'(? txexpr? (app txexpr->values tag-pat attrs-pat elements-pat))])
  (syntax-parser
    [:id #'-txexpr]
    [(_ tag:expr attrs:expr elements:expr)
     #'(-txexpr tag attrs elements)]))

By the way, I needed this enough (agreeing with that match+quasiquote wasn't good enough) that I wrote this code when I wanted to parse MusicXml: b4489c27d7/music/util/txexpr.rkt (L12-L19)

I have also wanted this, although of course you want want `txexpr` as both a function and a match expander, more like this: ```racket ;; -txexpr is the existing txexpr function (define-match-expander txexpr (syntax-parser [(_ tag-pat:expr attrs-pat:expr elements-pat:expr) #'(? txexpr? (app txexpr->values tag-pat attrs-pat elements-pat))]) (syntax-parser [:id #'-txexpr] [(_ tag:expr attrs:expr elements:expr) #'(-txexpr tag attrs elements)])) ``` By the way, I needed this enough (agreeing with that `match`+`quasiquote` wasn't good enough) that I wrote this code when I wanted to parse MusicXml: https://github.com/AlexKnauth/music/blob/b4489c27d7c0f7116d769344c787fa76b479e5fa/music/util/txexpr.rkt#L12-L19

(P.S. I'm thinking of making a pull-request, but I'm not sure how turning it into a macro like this affects the separate "safe" and "unsafe" versions, or how to handle providing a "macro with a contract" or a "match-expander with a contract")

I’d take PRs for this. I agree that macros & match expanders don’t need contracts. They can just be exported through safe as is.

I’d take PRs for this. I agree that macros & match expanders don’t need contracts. They can just be exported through `safe` as is.

The problem is that the way I currently know how, even when txexpr is used as a function, it is not be protected by a contract. The issue is that the code the macro expands to is on the wrong side of the contract boundary.

I might be able to fix this using define-module-boundary-contract...

The problem is that the way I currently know how, even when `txexpr` is used as a function, it is not be protected by a contract. The issue is that the code the macro expands to is on the wrong side of the contract boundary. I might be able to fix this using [`define-module-boundary-contract`](https://docs.racket-lang.org/reference/attaching-contracts-to-values.html?q=module-boundary-contract#%28form._%28%28lib._racket%2Fcontract%2Fprivate%2Fprovide..rkt%29._define-module-boundary-contract%29%29)...

Labels Milestones

(Feature request) add a new match pattern to support txexpr #7