Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ‘match?’, a pattern-matching predicate #1690

Closed
leafac opened this issue May 12, 2017 · 14 comments
Closed

Add ‘match?’, a pattern-matching predicate #1690

leafac opened this issue May 12, 2017 · 14 comments

Comments

@leafac
Copy link
Contributor

leafac commented May 12, 2017

FEATURE PROPOSAL

Add match? to racket/match. It is given a pattern and a subject expression, if the expression evaluates to a value that matches the pattern, then match? returns #t, otherwise it returns #f. Also, as an alternative form, match? could be given just a pattern, in which case it returns a predicate function.

Here’s a proposed implementation:

#lang racket
(require syntax/parse/define)

(define-syntax-parser match?
  [(match? pattern:expr subject:expr)
   #'(match subject
       [pattern #t]
       [_ #f])]
  [(match? pattern:expr)
   #'(match-lambda
       [pattern #t]
       [_ #f])])

(match? `(,c ,d) `(a b)) ; => #t

((match? `(,c ,d)) `(a b)) ; => #t

This design follows redex-match?.


If you agree with this proposal, please let me know and I’ll send a pull request.

Thanks.

@samth
Copy link
Sponsor Member

samth commented May 12, 2017 via email

@lexi-lambda
Copy link
Member

I thought matches? at first, too, but the match? name is actually more consistent with regexp-match? and redex-match?.

@leafac
Copy link
Contributor Author

leafac commented May 12, 2017

We need to consider potential conflicts. Particularly interesting is that it seems match? was a thing in the past.

@samth
Copy link
Sponsor Member

samth commented May 12, 2017

Well, that wasn't any more of thing in the past than now, but it suggests we should use that name. But we do need to make sure there aren't conflicts.

@winny-
Copy link
Contributor

winny- commented May 27, 2018

Any other conflicts? This would be a very handy syntax :)

@rfindler
Copy link
Member

It is exported by redex: http://docs.racket-lang.org/search/index.html?q=match%3F

@samth
Copy link
Sponsor Member

samth commented May 27, 2018

match? is provided already by unstable/match, and could presumably be in a smaller package. Is there a reason this needs to be provided by racket/match?

@leafac
Copy link
Contributor Author

leafac commented May 28, 2018

  1. Convenience.
  2. unstable/match “is deprecated; use racket/match, instead.”

@samth
Copy link
Sponsor Member

samth commented May 28, 2018

Right, I think we should have a new package that provides the remaining components of unstable/match.

@stamourv
Copy link
Contributor

Having to install and require a separate package would cancel out the small convenience that match? would give, IMO.

@samth
Copy link
Sponsor Member

samth commented May 28, 2018

We likely can't add it to racket/match itself, as @rfindler points out, redex already exports the same name.

I think we should get to a point with the pkg ecosystem where adding a new dependency for something this small is a reasonable choice. Maybe we're not there yet, though.

@rfindler
Copy link
Member

I agree with Sam's sentiment about small packages (both that it would be nice and that perhaps we aren't there).

Is there another name to consider?

@stamourv
Copy link
Contributor

matches? was suggested, and sounds fine to me, given the constraints.

@leafac
Copy link
Contributor Author

leafac commented May 29, 2018

I’d be happy if matches? was available when I (require racket/match) the same way that hash-union is available when I (require racket/hash)meaning it wouldn’t be part of racket/base or racket. I’d be happier if it were part of racket/base and racket as well.

@leafac leafac closed this as completed Jul 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants