tabatkins

Pattern Matching Rewrite

Intro

This proposal has several parts:

1. A new syntax construct, the "matcher pattern", which is an elaboration on

tabatkins

"Matchers Everywhere" Proposal

tldr:

• Matchers are mostly identical to what's in the repo today, except:
  • I added "predicate matchers" (if(<boolean-expr>)) and removed the if(...) part from the match() syntax.
  • Added ident when <matcher> binding-matcher form, to match its usage in destructuring.
  • Made regex matchers use /foo/ when <matcher> for consistency (and removed the named bindings for simplicity).
  • Added a simpler custom-matcher syntax (foo(<matchers>))

tabatkins

I think the rules for infinite-lookahead would be:

• If the first token is an ident or function, then:
  • If it's a dashed-ident (or function with a dashed-ident name), followed by any amount of whitespace, followed by a colon: it's a custom property.
  • If it's followed by any amount of whitespace and a colon, then look forward until you see either a semicolon or EOF (it's a property) or a {}-block (it's a rule).
  • Otherwise, it's a rule.
• Otherwise, it's a rule.

This gives us infinite lookahead, with arbitrary mixing of properties and selectors, with only three compromises:

tabatkins

On Sep 1 2022, Yulia and I had a VC to get past our misunderstandings/disagreements about pattern matching in a high-bandwidth fashion.

The high-level summary is that Yulia has three requests, all of which I think are reasonable. In order of complexity:

Allowing plain functions as custom matchers

Right now, custom matchers have to be done via an object with a Symbol.matcher key. The matcher function can be written as a plain boolean function now, but you still need that object wrapper, which is annoying as it prevents existing boolean functions from being easily used. Ideally you'd be able to write when(${someFunc}) and have it work exactly like when(${{[Symbol.matcher]: someFunc}}) does in today's spec.

The blocker for this is that we currently define Function.prototype[Symbol.matcher] to essentially do an instanceof check, so JS classes can be used by default: when(${MyClass}) will match if the matchable is an instance of MyClass or a subclass, wi

tabatkins

Checkbox

<div class=checkbox></div>

<style>
.checkbox {
	toggle: checked;
}
.checkbox:toggle(checked)::before {

tabatkins

PANEL 1

Beachside, camera facing away from the ocean.

A FIRBOLG and a DWARF relax in beach chairs, sipping pina coladas, with halos above their head. A skinny human man is building a sand castle at their feet.

DWARF: Gotta say, didn't expect to find myself enjoying this sorta afterlife.

tabatkins

// This is a decorated version of <https://github.com/tc39/proposal-pattern-matching#custom-matcher-protocol-interpolations>

// A predefined ADT decorator.
// Use it on static "constructor" methods only.
// Pass an extractor function, to produce a pattern-matching value.
// The instance must have an [ADT.kind] property
// set to the constructor method used.
const ADT = (valExtractor=()=>null) => (_, {methodName, isStatic, kind, addInitializer}) => {
	if(kind == "method" && isStatic) {
		addInitializer(function(){

tabatkins

1. Vowels are green, y is yellow.

2. Doubled letters in a word are yellow, tripled letters are green.

3. ???? My first guess gave me a yellow T and green A, and I just made words putting those lettes where they needed to be and solved all the challenges. Surely it's not that simple???

   (Edited to add: It's not that simple - the first letter in alphabetical order in your guess is green, the last is yellow. My first guess (and all subsequent) just happened to use A and T as the first/last letters.)

4. If you use the same letter in the same position as the immediately preceding guess, it's yellow. If a letter is used in the same position three guesses in a row, it's green. Good luck with the GGBGG pattern.

tabatkins

import io

# Gets my list of words taken from wordle source
# (91k raw, 33k compressed)
# down to 32k raw, 16k compressed.
# Squashing characters into 6 bits, and the separator into 4,
# would reduce the raw size ~30% more,
# at the cost of a more complex decoder.

separator = "\n"

tabatkins

There's currently five "linear dataflow" proposals bouncing around TC39: the pipe operator |>, the bind-this :: operator, the partial function application foo~() operator, the Extension operator ::/:, and the pipe()/flow() functions. @js-choi put together a wonderful diagram comparing and contrasting their functionality overlaps, along with an accompanying blogpost going over things in more detail.

My personal thoughts on the matter are that we need the Pipe operator, could use PFA and the pipe()/flow() methods, and don't need the other two.

Pipe Operator

As the diagram helpfully illustrates, the pipe operator nearly subsumes every other proposal