Skip to content

Instantly share code, notes, and snippets.

View tabatkins's full-sized avatar

Tab Atkins Jr. tabatkins

View GitHub Profile
@tabatkins
tabatkins / proposal.md
Last active September 29, 2023 22:43
Pattern Matching, 2023-07-10
View proposal.md

Pattern Matching Rewrite

Intro

This proposal has several parts:

  1. A new syntax construct, the "matcher pattern", which is an elaboration on
@tabatkins
tabatkins / proposal.md
Last active August 22, 2023 13:31
Pattern-matching across constructs
View proposal.md

"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
tabatkins / proposal.md
Last active January 18, 2023 18:28
Infinite-Lookahead nesting rules
View proposal.md

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
tabatkins / writeup.md
Last active September 3, 2022 21:18
Results of the discussion between Tab and Yulia
View writeup.md

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
tabatkins / toggle-patterns.md
Last active August 26, 2022 17:07
Various ARIA component patterns, and how they'd be naively built using toggle
View toggle-patterns.md

Checkbox

<div class=checkbox></div>

<style>
.checkbox {
	toggle: checked;
}
.checkbox:toggle(checked)::before {
@tabatkins
tabatkins / script.md
Last active December 28, 2022 19:11
Chester comic script
View script.md

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
tabatkins / option.js
Last active January 31, 2022 22:45
ADT, Decorators, Pattern Matching
View option.js
// 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
tabatkins / rules.md
Last active January 24, 2022 01:17
Obscurdle rules
View rules.md
  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.

View code.py
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
tabatkins / extension-thoughts.md
Last active January 6, 2022 18:51
Integrating the dataflow proposals
View extension-thoughts.md

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