tabatkins

Core Proposal real-world examples

Living Document. J. S. Choi, 2018-12.

WHATWG Fetch Standard

The [WHATWG Fetch Standard][] contains several examples of using the DOM fetch function, resolving its promises into values, then processing the values in various ways. These examples may become more easily readable with smart pipelines.

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

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

We've been deadlocked for a while on the pipeline operator proposal, for a few reasons. Partially it's just low implementor interest, as this is fundamentally just syntactic sugar, but also because there are three competing proposals and the proponents of each haven't been convinced by the others yet.

In this essay I hope to briefly outline the problem space, summarize the three proposals, and talk about what's gained/lost by each of them. (Spoiler: they're all nearly identical; we're arguing over very small potatoes.)

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

// 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.