Tab Atkins Jr. 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

D&D 5e Weapon Construction Rules

Way back in D&D 3rd edition, I noticed that the weapons table seemed very regular. There were certain patterns that were maintained almost completely across the board. I documented these and wrote them up (still on my very very old pbwiki), to help other people create new balanced weapons.

(Later, one of the 3e designers, Sean K Reynolds, confirmed for me that, while they hadn't quite formalized the rules in the form that I was presenting, my rules were accurate.)

Later, when 5th edition came out, I looked over the weapons again and attempted to extract a similar set of rules. They were a bit more complex, surprisingly, and not quite as regular - 5e seems to have embraced sometimes giving less-effective options for flavor or lower cost (look at the armor table, for instance, phew).

But if you look at the reasonably optimal weapons, the following rules will construct weapon

XML-in-KDL (XiK)

This specification describes a canonical way to losslessly encode XML in KDL. While this isn't a very useful thing to want to do on its own, it's occasionally useful when using a KDL toolchain while speaking with an XML-consuming or -emitting service.

This is version 1.0.0 of XiK.

XML-in-KDL (XiK from now on) is a kdl microsyntax for losslessly encoding XML into a KDL document. XML and KDL, luckily, have very similar data models (KDL is almost a superset of XML), so it's quite straightforward to encode most XML documents into KDL.

XML has four types of nodes, corresponding to certain KDL constructs:

JSON-in-KDL

This specification describes a canonical way to losslessly encode JSON in KDL. While this isn't a very useful thing to want to do on its own, it's occasionally useful when using a KDL toolchain while speaking with a JSON-consuming or -emitting service.

JSON-in-KDL (JiK from now on) is a kdl microsyntax consisting of three types of nodes:

literal nodes, with _ as the nodename
array nodes, with array as the nodename
dict nodes, with dict as the nodename

Real world use-case: someone asking for Object.values()/etc to be installed as Symbol-keyed properties on Object.prototype, so they can have method chains working on arrays/iterators that produce an Object at some intermediate point, without having to go back and wrap an entire chunk of the method chain in a big wrapping Object.values().

That is, they're prefer not to have to write this code:

const x = Object.values(array.filter(x=>x).map(x=>f(x)).reduce(intoObjectSomehow)).map(y=>g(y))

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

(Note that PEP 642 was rejected, but its points are intriguing; I discuss it at the end of this document.)

Basic patterns are identical to my proposal, modulo obvious differences in Python spelling vs JS spelling:

Identical "leaf" matchers (ident-matcher, nil-matcher, literal-matchers)
identical array-matcher,

Masterwork Properties

Masterwork properties can be applied to any masterwork weapon or suit of armor, provided you can spare the time and gold cost required to apply it. Each property entry details the property’s level and the type of equipment it can be applied to.

Unless otherwise noted, a piece of gear cannot have the same property more than once; for example, you cannot

	function construct(getNextStates) {
	return function ai(currentState) {
	const pieces = [
	{name:"S", annoyance:7},
	{name:"Z", annoyance:6},
	{name:"O", annoyance:5},
	{name:"I", annoyance:4},
	{name:"L", annoyance:3},
	{name:"J", annoyance:2},
	{name:"T", annoyance:1},

	There's a reason people don't like to write HTML tables,
	and it's because they don't write good HTML in the first place.

	Case in point, taken from a spec I'm editting right this moment:

	```html
	<table id="distinguishable-table" class="matrix data complex">
	<tr>
	<th class="corner"></th>
	<th><div>