NUL-terminated module name, as ASCII.

This syntax has been adapted as a variation of the <URL:[...]> convention from RFC 1738 (refer to its Appendix).

The form appearing here is a more general derivation, which (a) allows the omission of the "role" atom† ("URL" in RFC 1738), with clients instructed to intepret the omission to mean that "URL" is implied; (b) better accommodates more recent conventions that omits both this atom and the colon separator entirely, encoding instead just the URL, as in <https://example.com>; (c) doesn't lead to interference with the HTML5 parsing algorithm. The latter is crucial for compatibility with mainstream browsers--the leading colon prevents the the bracketed plain text from being interpreted as HTML.

Maybe if we were to spec this out, we'd allow an alternative for plain links of the form <@https://example.com/> (which permits no "role"--and is therefore only used where "URL" can be inferred)?

We also want there to be a way to denote links not meant for direct navigation, but rather things that you would otherwise use the Link HTTP header or the link HTML element for. Some candidates:

• <@!https://example.com/foo> (extending the syntax further)
• <:link:https://example.com/foo> (i.e. a link URI, no special syntax)

† NB: '"role" atom" is terminology of my own choosing. The RFC's authors only ever refer to it as a "prefix".

It's not clear that this ever became common--most use in the wild seems to omit the "prefix" entirely.

At https://www.colbyrussell.com/LP/debut/plain.txt.htm, I adopt an alternative "concise" form that permits the "URL" atom to be omitted, while still allowing for the colon to be left in, for reasons explained in an annotation left there:

doesn't lead to interference with the HTML5 parsing algorithm [...] crucial for compatibility with mainstream browsers--the leading colon prevents the the bracketed plain text from being interpreted as HTML

The idea is that the form with the leading colon should be treated equivalent to the form that omits the prefix entirely, except it may be used in contexts sensitive to parsing constraints as described above.

A nice turn of phrase that I really like. It goes well with the observation about the fragility of most software that is created.

This reads string data one character at a time into the module's "address space". So why is the on-disk format for RSC string data aligned by word? The cost of instructions executed by the CPU for a call to Files.Read for a single extra NUL byte is going to be more expensive than padding up to the nearest word boundary here, in the module loader, instead of in laying them down that way by the compiler's ORG module--and that's without even considering the additional cost for disk IO!

On the Yax landing page right now, the steps are labelled in Chinese:

Use a bookmarklet + BYFOB

What's really inexcusable (hello, from anagram year 2021) is that a "proper server or test environment" should even be required. There's no inherent virtue in this. We should have the appropriate infrastructure by now that allows this to be handled using nothing more than a commodity document viewer—i.e. a web browser. The notion that you should need to drop down and run a daemon—and that this is the "proper" way it should be done—is totally backwards.

This does not follow.

Unfortunately true! Daniel Kehoe has been working on an antidote to this at yax.com, which he refers to as the "stackless" way of development.

True and succinct in a way that lets it serve as a good memetic mindworm.

Hell, yeah!

Definitely. The way I wrote this in my own notes once upon a time was:

Conjecture:¶ Attempting to write a literate program and landing somewhere off the mark produces a program that is worse than if it were written in the ordinary tradition.

One of the perils that most programmers are probably familiar with, especially in the early years.

This is great and a restatement of the laconic truth that the slowest build toolchain is the one that the user is never able to coax to successful completion.

(Reproduced from the inaugural note to the Hypothesis group for triplescripts.org)

Hello, triplescripts.org!

Hypothesis is the official channel for feedback and community discussions related to triplescripts.org. And don't forget that we have a wiki at wiki.triplescripts.org (but please avoid using the Mediawiki "Talk" pages—use Hypothesis instead).

To use Hypothesis for feedback, create an account at https://hypothes.is if you haven't already, get the browser extension or bookmarklet, and join the triplescripts.org group. (The last step is critical; make sure you're sending your annotations to the correct group and not the hypothes.is's default "Public" stream.) This is a semi-private group in the sense that you need to use the invitation link, but it's open to almost everyone willing to abide by the community rules. For more info, refer to the page on community values on the triplescripts.org wiki. Feel free to use the invitation link to invite others.

As we progress in settling on a set of community processes and practices, they will gradually be documented both on the wiki and the official pages here on triplescripts.org.

Our thanks to those at 5apps, Hypothesis, and Miraheze for hosting the services essential our project and many others.