RFC: hash table pattern matching

[samth]

A few thoughts on this:

1. We should look at actual uses of the hash-table pattern across real Racket code to see whether people are looking for partial or full matching.
2. What do other languages do here? There's a proposal for JavaScript, for example, here: GitHub - tc39/proposal-pattern-matching: Pattern matching syntax for ECMAScript In that, it uses partial matching and also allows a rest pattern for the other keys.

[LiberalArtist]

@sorawee

Maybe it would be useful to articulate why we’re discussing adding a pattern with special support from match, rather than a pure library extension? (That is what we’re discussing, right?) I think it’s a combination of (a) bugs in hash-table and (b) potential efficiency gains from cooperation with match’s optimizer, but maybe there are other reasons.

It’s mainly because of the bugs in the existing hash-table. I need to add something so that users can switch over and stop using the buggy pattern. hash-table is already expressible as a match expander. Same for the proposed hash and hash*. There’s no efficiency gain.

Isn't there?

Here's some pseudo-code based on the Activity Vocabulary:

(match-lambda
  [(hash '@context "https://www.w3.org/ns/activitystreams"
         'type "Like"
         'summary desc
         'actor who
         'object what)
   ...]
  [(hash '@context "https://www.w3.org/ns/activitystreams"
         'type "Question"
         'name question
         (and (or 'oneOf 'anyOf) mode) options)
   ...]
  [(hash '@context "https://www.w3.org/ns/activitystreams"
         'type "Block"
         'summary desc
         'actor who
         'object what)
   ...])

I see lots of opportunities for a sufficiently smart match to optimize this, but I don't think match can do them with just ? and app without trying doing an unreasonable amount of analysis to the procedure expressions.

(Writing this also made me think about how the potential choices might interact with and and or patterns.)

@AlexKnauth

This is also why I don't really like the words "partial" and "full". In the same message where @rocketnia pointed this out about structs, there were other naming suggestions floated: #:extensible or #:open instead of #:partial, and #:final or #:closed instead of #:full.

I also don't love the words "full" and "partial". I've been thinking of the word "exhaustive", but I'm not sure if the analogy to "exhaustiveness checking" would be helpful or confusing.

[sorawee]

I like “open” and “closed” better, so I will use those.

It’s been a week now. The results of both polls are: 9 vs 5 and 7 vs 3 for “closed” vs “open”. So the consensus seems to be having “closed” by default for hash.

I think I already have enough information from the RFC to start implementing the pattern. Of course, if you have any disagreement with the upcoming PR, you can still raise your concern there.

@LiberalArtist: When I said there’s no efficiency gain, I simply described the current state (of the existing hash-table and the proposed hash and hash*). With more effort, you can certainly add more optimization.

The second pattern in your code snippet is interesting. It is not possible to directly express it in the proposed patterns. However, you can do the following (assuming that options can't be false):

  [(hash* ['@context "[https://www.w3.org/ns/activitystreams](https://www.w3.org/ns/activitystreams)"]
          ['type "Question"]
          ['name question]
          ['oneOf options-one #:default #f]
          ['anyOf options-any #:default #f])
   #:when (or options-one options-any)
   (define options (or options-one options-any))
   (define mode (if options-one 'oneOf 'anyOf))
   ...]

[sorawee]

Oh, and thank you to everyone for participating!

[dstorrs]

I circled back on this in the process of looking something else up and was wondering where things stood? I use match an awful lot, and this particular feature would be very useful for me.

[shhyou]

The PR is sort of stuck.

match: add support for hash and hash* patterns

[sorawee]

I plan to resolve this issue with @samth at RacketCon.

[sorawee]

The PR is now merged! The feature is in the snapshot build now (docs here), so you can try it out if you want to.
Thanks everyone in this thread for the RFC participation. Special thanks to @samth for the PR review!

[bakgatviooldoos]

Net betyds vir my verjaarsdag!

Thanks, @sorawee (and to whomever thanks are in order). I've been eyeing this feature for a while now.