coop/rose-ash
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sx-tools: WASM kernel updates, TW/CSSX rework, content refresh, new debugging tools

Browse Source 
Build tooling: updated OCaml bootstrapper, compile-modules, bundle.sh, sx-build-all.
WASM browser: rebuilt sx_browser.bc.js/wasm, sx-platform-2.js, .sxbc bytecode files.
CSSX/Tailwind: reworked cssx.sx templates and tw-layout, added tw-type support.
Content: refreshed essays, plans, geography, reactive islands, docs, demos, handlers.
New tools: bisect_sxbc.sh, test-spa.js, render-trace.sx, morph playwright spec.
Tests: added test-match.sx, test-examples.sx, updated test-tw.sx and web tests.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
giles
2026-04-02 11:31:57 +00:00
parent 9ed1100ef6
commit d40a9c6796
178 changed files with 13591 additions and 9110 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
sx/sx/essays/client-reactivity.sx
View File

File diff suppressed because one or more lines are too long

2
sx/sx/essays/continuations.sx
View File

File diff suppressed because one or more lines are too long

22
sx/sx/essays/godel-escher-bach.sx
View File

File diff suppressed because one or more lines are too long

68
sx/sx/essays/hegelian-synthesis.sx
View File

@@ -4,78 +4,78 @@
(defcomp ~essays/hegelian-synthesis/essay-hegelian-synthesis ()
(~docs/page :title "The Hegelian Synthesis"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"On the dialectical resolution of the hypertext/reactive contradiction.")
(~docs/section :title "I. Thesis: The server renders" :id "thesis"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In the beginning was the hyperlink. The web was born as a system of documents connected by references. A page was a " (em "representation") " — complete, self-contained, delivered whole by the server. The browser was a thin client. It received, it rendered, it followed links. The server was the sole author of state.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is the thesis of the web: " (strong "the server knows") ". It knows what to show. It knows what state you're in. It knows what actions are available. It encodes all of this in the document it sends you. When you click a link, the server sends a new document. When you submit a form, the server processes it and sends another document. The cycle is: request, represent, repeat.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Hegel would recognise this as a form of " (em "Substance") " — the server as the unmoved mover, the ground of all content. The client has no interiority. It does not " (em "decide") " anything. It displays what it is told to display. The web page is Spinozistic: a mode of the server, one of its infinite expressions, determined entirely by its cause.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"htmx is the most faithful modern expression of this thesis. It extends the hyperlink and the form — the two primordial hypermedia controls — to every element and every HTTP verb, but it does not break the paradigm. The server still renders. The server still knows. The server still authors state. htmx simply makes the authoring more fine-grained: instead of replacing the entire page, the server replaces a fragment. The thesis is refined, not rejected.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The beauty of the thesis is its simplicity. One source of truth. One rendering pipeline. No synchronisation problems. No stale state. No " (code "useEffect") " cleanup. Every request produces a fresh representation, and the representation " (em "is") " the application. There is nothing hidden behind it, no shadow state, no ghost in the machine.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But the thesis has a limit. The server cannot know everything the client experiences. It cannot know that the user's mouse is hovering over a button. It cannot know that a drag is in progress. It cannot know that a counter should increment " (em "now") ", this millisecond, without a round trip. The thesis renders the world from the server's perspective — and the client's perspective, its " (em "Erlebnis") ", its lived experience, is absent."))
(~docs/section :title "II. Antithesis: The client reacts" :id "antithesis"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"React arrived as the negation of the server-rendered web. Where the thesis said " (em "the server knows") ", React said " (em "the client knows better") ". Where the thesis treated the browser as a display surface, React treated it as an application runtime. Where the thesis sent documents, React sent " (em "programs") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The Hegelian antithesis is not mere opposition — it is " (em "determinate negation") ". React does not simply reject server rendering. It rejects the specific limitation that the thesis cannot overcome: the absence of immediate, client-local state. React gives the client " (em "interiority") ". The component has state. It has a lifecycle. It makes decisions without consulting the server. It " (em "reacts") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is the birth of " (em "Subject") " in the Hegelian sense. The client is no longer pure receptivity. It has " (em "Selbstbewusstsein") " — self-consciousness. It knows its own state. A " (code "useState") " hook is an act of self-positing: the component declares " (em "I have an interior") ". A " (code "useEffect") " is self-reflection: the component observes its own changes and responds. The client becomes, in miniature, a knowing subject.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But the antithesis inherits its own contradiction. By giving the client interiority, React creates " (em "two sources of truth") ". The server has its state. The client has its state. They must be synchronised. And synchronisation is the eternal problem of distributed systems — it cannot be solved, only managed. Hence the endless parade of state management libraries, cache invalidation strategies, optimistic updates, revalidation hooks. Each is an attempt to paper over the fundamental contradiction: the client and server both claim to know, and they do not always agree.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Worse, the antithesis destroys what the thesis had achieved. The representation is no longer self-contained. A React SPA sends a JavaScript bundle — a program, not a document. The server sends an empty " (code "<div id=\"root\">") " and a prayer. The browser must compile, execute, fetch data, and construct the interface from scratch. The document — the web's primordial unit of meaning — is hollowed out. What arrives is not a representation but an " (em "instruction to construct one") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Hegel would diagnose this as the antithesis's characteristic failure: it achieves freedom (client autonomy) at the cost of substance (server authority). The SPA is the " (em "beautiful soul") " of web development — pure subjectivity that has cut itself off from the objective world and wonders why everything is so complicated."))
(~docs/section :title "III. The contradiction in practice" :id "contradiction"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The practical manifestation of the dialectic is visible in every web team's daily life. The server-rendered camp says: " (em "just use HTML and htmx, it's simpler") ". The React camp says: " (em "you can't build a real app without client state") ". Both are correct. Both are incomplete.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The server camp cannot build a colour picker. Cannot build a drag-and-drop interface. Cannot build a spreadsheet. Cannot build anything that requires the client to know its own state between HTTP requests. Every interaction that needs immediacy — every tooltip, every animation, every character-by-character validation — forces the server camp to smuggle in JavaScript through the back door, breaking their own thesis.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The React camp cannot deliver a page without JavaScript. Cannot render on first load without a server-rendering framework bolted on top. Cannot cache a representation because there is no stable representation to cache. Cannot inspect a page without devtools because the document is an empty shell. Every improvement — server components, streaming SSR, partial hydration — is an attempt to recover what the thesis already had: server-authored, self-contained documents.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The two camps are not in disagreement about different things. They are in disagreement about " (em "the same thing") ": where should state live? The thesis says: on the server. The antithesis says: on the client. Neither can accommodate the obvious truth that " (strong "some state belongs on the server and some belongs on the client") ", and that a coherent architecture must handle both without privileging either."))
(~docs/section :title "IV. Synthesis: The island in the lake" :id "synthesis"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Hegel's dialectic does not end in compromise. The synthesis is not half-thesis, half-antithesis. It is a new category that " (em "sublates") " — " (em "aufhebt") " — both: preserving what is true in each while resolving the contradiction between them. The synthesis contains the thesis and antithesis as " (em "moments") " within a higher unity.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The island architecture is this synthesis. The " (em "lake") " is the thesis preserved: server-rendered HTML, delivered as complete representations, navigated by hypermedia controls. The " (em "island") " is the antithesis preserved: client-local state, reactive signals, immediate interaction. Neither is primary. Neither is a concession to the other. Both are " (em "moments") " of the same page.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But the crucial move — the one that makes this a genuine Hegelian synthesis rather than a mere juxtaposition — is " (strong "the morph") ". When the server sends new content and the client merges it into the existing DOM, hydrated islands are " (em "preserved") ". The server updates the lake. The islands keep their state. The server's new representation flows around the islands like water around rocks. The client's interiority survives the server's authority.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is " (em "Aufhebung") " in its precise meaning: cancellation, preservation, and elevation. The thesis (server authority) is " (em "cancelled") " — the server no longer has total control over the page. It is " (em "preserved") " — the server still renders the document, still determines structure, still delivers representations. It is " (em "elevated") " — the server now renders " (em "around") " reactive islands, acknowledging their autonomy. Simultaneously, the antithesis (client autonomy) is cancelled (the client no longer controls the whole page), preserved (islands keep their state), and elevated (client state now coexists with server-driven updates).")
(~docs/code :src (highlight ";; The island: reactive state coexists with server lakes.\n;; Lakes are server-morphable slots — the water within the island.\n\n(defisland ~essays/hegelian-synthesis/header ()\n (let ((families (list \"violet\" \"rose\" \"blue\" \"emerald\"))\n (idx (signal 0))\n (current (computed (fn ()\n (nth families (mod (deref idx) (len families)))))))\n (a :href \"/\" :sx-get \"/\" :sx-target \"#main-panel\"\n ;; Lake: server can update the logo\n (lake :id \"logo\"\n (span :style (cssx ...) \"(<sx>)\"))\n ;; Reactive: signal-bound, NOT in a lake\n (span :style (cssx (:text (colour (deref current) 500)))\n :on-click (fn (e) (swap! idx inc))\n \"reactive\")\n ;; Lake: server can update the copyright\n (lake :id \"copyright\"\n (p \"© 2026\")))))\n\n;; Click: colour changes (client state)\n;; Server sends new page — morph enters the island\n;; Lakes update from server content\n;; Reactive span keeps its colour — state survives" "lisp"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The " (code "lake") " tag is the key. Inside the island, " (code "(lake :id \"logo\" ...)") " marks a region as server territory — the server can update its content during a morph. The reactive " (code "span") " with its signal-bound style is " (em "not") " in a lake — it is island territory, untouchable by the morph. The morph enters the island, finds the lakes, updates them from the server's new representation, and " (em "flows around") " the reactive nodes like water around rocks.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Click the word " (em "reactive") " in the header. The colour changes. Navigate to another page. The morph enters the island, updates the lakes (logo, copyright), but the reactive span — with its colour signal — " (em "persists") ". The client's inner life survives the server's outer renewal."))
(~docs/section :title "V. Spirit: The self-knowing page" :id "spirit"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Hegel's system does not end with synthesis. Synthesis becomes a new thesis, which generates its own antithesis, and the dialectic continues. The island architecture is not a final resting place. It is a " (em "moment") " in the self-development of the web.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Consider what the synthesis makes possible. The page now has two modes of knowledge: the server's knowledge (what the page should contain) and the client's knowledge (what the user is doing right now). Neither is reducible to the other. Neither is privileged over the other. The page is, in Hegel's terminology, " (em "Spirit") " — " (em "Geist") " — the unity of substance and subject, the place where objective content and subjective experience meet.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The self-hosting nature of SX deepens this. The evaluator that renders islands is specified in the same language as the islands themselves (" (code "eval.sx") "). The renderer is specified in the same language (" (code "render.sx") "). The parser is specified in the same language (" (code "parser.sx") "). The system knows itself. It is a specification that specifies its own interpretation. This is Hegel's " (em "absolute knowing") " — not omniscience, but self-transparency. The system is what it knows, and it knows what it is.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The morph algorithm is the phenomenological crux. It is the mechanism by which the page achieves continuity of experience through discontinuity of content. The server sends a completely new representation — new HTML, new structure, new text. The morph walks the old and new DOM trees, reconciling them. Where it finds an island — a locus of client subjectivity — it preserves it. Where it finds static content — server substance — it updates it. The result is a page that is simultaneously the same (the island's state persists) and different (the surrounding content has changed).")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is Hegel's " (em "identity of identity and difference") ". The page after the morph is the same page (same islands, same signals, same DOM nodes) and a different page (new server content, new navigation state, new URL). The dialectic is not resolved by eliminating one side. It is resolved by maintaining both simultaneously — and the morph is the concrete mechanism that achieves this."))
(~docs/section :title "VI. The speculative proposition" :id "speculative"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Hegel distinguished " (em "ordinary") " propositions from " (em "speculative") " ones. An ordinary proposition has a fixed subject and a predicate attached to it from outside: " (em "the rose is red") ". A speculative proposition is one where the predicate reflects back on the subject and transforms it: " (em "the actual is the rational") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The proposition " (em "React is hypermedia") " is speculative in this sense. It does not mean that React, as it exists, is hypermedia. It means that what React " (em "was trying to be") " — a way to specify interactive UI — is what hypermedia " (em "always already was") " — a way to specify interactive documents. The predicate (hypermedia) transforms the subject (React): once you see that reactive islands are hypermedia controls, you can no longer see React as merely a JavaScript library. It was always an attempt to extend the expressiveness of hypermedia. It just didn't know it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"And the converse: " (em "hypermedia is reactive") ". The hyperlink is already a reactive control — it responds to user input (click) by producing a state change (navigation). The form is reactive — it responds to submission by producing a state change (server-side processing + new representation). htmx makes this explicit: any element can react to any event by triggering any HTTP verb. The only thing htmx lacks is " (em "local") " reactivity — the ability to change without consulting the server.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Islands supply exactly this. And by doing so, they do not add something foreign to hypermedia. They complete it. They give hypermedia the last degree of freedom it was missing: the ability for a control to react to itself, to maintain its own state, to compute derived values from its own inputs — without breaking the hypermedia contract that the server is the author of the document.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The Hegelian synthesis is not a compromise between server rendering and client reactivity. It is the recognition that they were always the same thing seen from different sides. The server renders the document. The document contains controls. Some controls maintain local state. The document flows around them. The state persists through the flow. The server and the client are not two systems bridged together. They are one system that knows itself from two perspectives.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Click the word " (em "reactive") " in the header above. The colour changes. The page navigates. The colour survives. That is the Hegelian synthesis of the hypertext/reactive dialectic — not in theory, but in the DOM."))))

2
sx/sx/essays/htmx-react-hybrid.sx
View File

@@ -1,2 +1,2 @@
(defcomp ~essays/htmx-react-hybrid/essay-htmx-react-hybrid ()
(~docs/page :title "The htmx/React Hybrid" (~docs/section :title "Two good ideas" :id "ideas" (p :class "text-stone-600" "htmx: the server should render HTML. The client should swap it in. No client-side routing. No virtual DOM. No state management.") (p :class "text-stone-600" "React: UI should be composed from reusable components with parameters. Components encapsulate structure, style, and behavior.") (p :class "text-stone-600" "sx tries to combine both: server-rendered s-expressions with hypermedia attributes AND a component model with caching and composition.")) (~docs/section :title "What sx keeps from htmx" :id "from-htmx" (ul :class "space-y-2 text-stone-600" (li "Server generates the UI — no client-side data fetching or state") (li "Hypermedia attributes (sx-get, sx-target, sx-swap) on any element") (li "Partial page updates via swap/OOB — no full page reloads") (li "Works with standard HTTP — no WebSocket or custom protocol required"))) (~docs/section :title "What sx adds from React" :id "from-react" (ul :class "space-y-2 text-stone-600" (li "defcomp — named, parameterized, composable components") (li "Client-side rendering — server sends source, client renders DOM") (li "Component caching — definitions cached in localStorage across navigations") (li "On-demand CSS — only ship the rules that are used"))) (~docs/section :title "What sx gives up" :id "gives-up" (ul :class "space-y-2 text-stone-600" (li "No HTML output — sx sends s-expressions, not HTML. JS required.") (li "Custom parser — the client needs sx.js to understand responses") (li "Niche — no ecosystem, no community, no third-party support") (li "Learning curve — s-expression syntax is unfamiliar to most web developers")))))
(~docs/page :title "The htmx/React Hybrid" (~docs/section :title "Two good ideas" :id "ideas" (p (~tw :tokens "text-stone-600") "htmx: the server should render HTML. The client should swap it in. No client-side routing. No virtual DOM. No state management.") (p (~tw :tokens "text-stone-600") "React: UI should be composed from reusable components with parameters. Components encapsulate structure, style, and behavior.") (p (~tw :tokens "text-stone-600") "sx tries to combine both: server-rendered s-expressions with hypermedia attributes AND a component model with caching and composition.")) (~docs/section :title "What sx keeps from htmx" :id "from-htmx" (ul (~tw :tokens "space-y-2 text-stone-600") (li "Server generates the UI — no client-side data fetching or state") (li "Hypermedia attributes (sx-get, sx-target, sx-swap) on any element") (li "Partial page updates via swap/OOB — no full page reloads") (li "Works with standard HTTP — no WebSocket or custom protocol required"))) (~docs/section :title "What sx adds from React" :id "from-react" (ul (~tw :tokens "space-y-2 text-stone-600") (li "defcomp — named, parameterized, composable components") (li "Client-side rendering — server sends source, client renders DOM") (li "Component caching — definitions cached in localStorage across navigations") (li "On-demand CSS — only ship the rules that are used"))) (~docs/section :title "What sx gives up" :id "gives-up" (ul (~tw :tokens "space-y-2 text-stone-600") (li "No HTML output — sx sends s-expressions, not HTML. JS required.") (li "Custom parser — the client needs sx.js to understand responses") (li "Niche — no ecosystem, no community, no third-party support") (li "Learning curve — s-expression syntax is unfamiliar to most web developers")))))

92
sx/sx/essays/hypermedia-age-of-ai.sx
View File

@@ -5,102 +5,102 @@
(defcomp ~essays/hypermedia-age-of-ai/essay-hypermedia-age-of-ai ()
(~docs/page :title "Hypermedia in the Age of AI"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"Neither JSON nor HTML is hypermedia. There is only the hypermedium — a self-defining representation — and s-expressions are an instance of it.")
(~docs/section :title "I. The argument" :id "the-argument"
(p :class "text-stone-600"
(a :href "https://nickblow.tech/posts/hypermedia-in-the-age-of-ai" :class "text-violet-600 hover:underline" "Nick Blow argues")
(p (~tw :tokens "text-stone-600")
(a :href "https://nickblow.tech/posts/hypermedia-in-the-age-of-ai" (~tw :tokens "text-violet-600 hover:underline") "Nick Blow argues")
" that JSON hypermedia can serve AI agents better than HTML or RPC. Carson Gross contends that sprinkling link objects into JSON does not make an API truly RESTful, because REST demands generic clients capable of interpreting hypermedia controls. Blow agrees this has merit but thinks the position too restrictive. HTML is not the universal hypermedia format — LLMs choke on it. The real prize is " (em "progressive discovery") ": a client that learns what it can do by following links, not by reading documentation upfront.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"He contrasts this with MCP, the Model Context Protocol now dominant for LLM tool use. MCP is RPC in a trench coat: the server declares all its tools upfront, the model receives the full catalogue in its system prompt, and it calls functions by name. This works, but it does not scale. MCP forces " (em "total disclosure") " where hypermedia would offer " (em "progressive revelation") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Blow proposes JSON-flavoured hypermedia as the fix — " (code "vnd.siren+json") ", custom content types, link relations in response payloads. Resources become state machines. Hyperlinks are state transitions. The agent explores the graph.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is the right diagnosis. But the prescription misidentifies the disease. The problem is not that we need a better wire format for links. The problem is that neither JSON nor HTML is actually hypermedia. And no amount of convention layered on top will make them so, because what makes something hypermedia is not what it carries but whether it can " (em "define itself") "."))
(~docs/section :title "II. The self-definition criterion" :id "self-definition"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"What does it mean for a format to be hypermedia? The conventional answer focuses on " (em "affordances") ": a hypermedia format includes controls that tell the client what it can do next. Links, forms, actions. This is the definition that drives the JSON hypermedia proposals — add links to JSON, and JSON becomes hypermedia.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But this definition is too shallow. It describes a property of the content without asking where the " (em "meaning") " of the content comes from. A Siren response includes an " (code "actions") " array — but what makes that array mean \"available actions\" rather than just \"a list of objects with href fields\"? The Siren specification, written in English prose, hosted on a separate document, maintained by a separate community. The meaning is " (em "external") " to the format.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A true hypermedium does not need an external document to explain what it means. It defines its own interpretation. The format carries not just content and controls, but the rules by which content and controls are understood. The map " (em "is") " the territory — not because the map is accurate, but because the map can redraw itself.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is a strict criterion. It eliminates almost everything. And it should, because almost nothing on the web is actually hypermedia in this sense. Most of what we call hypermedia is data decorated with navigational metadata, interpreted by an engine built from a separate specification in a separate language."))
(~docs/section :title "III. JSON cannot define itself" :id "json-cannot"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"You cannot write the JSON specification in JSON.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a trivia question. It reveals something fundamental about the format. JSON is a data serialization: maps, arrays, strings, numbers, booleans, null. It has no evaluation semantics. It cannot express a grammar. It cannot express a parser. It cannot express the rules by which a JSON document should be interpreted — because it cannot express " (em "rules") " at all. JSON describes " (em "what") " without any capacity to describe " (em "how") " or " (em "why") ".")
(p :class "text-stone-600"
"The JSON specification is " (a :href "https://www.rfc-editor.org/rfc/rfc8259" :class "text-violet-600 hover:underline" "RFC 8259") " — English prose. This is not an accident or a stylistic choice. JSON " (em "cannot") " define itself because it has no mechanisms for definition. It is inert data. Every scrap of meaning attached to a JSON document — this key means a link, this object means an action, this array means available transitions — must come from outside the document. From a spec. From a schema. From shared understanding between producer and consumer.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The JSON specification is " (a :href "https://www.rfc-editor.org/rfc/rfc8259" (~tw :tokens "text-violet-600 hover:underline") "RFC 8259") " — English prose. This is not an accident or a stylistic choice. JSON " (em "cannot") " define itself because it has no mechanisms for definition. It is inert data. Every scrap of meaning attached to a JSON document — this key means a link, this object means an action, this array means available transitions — must come from outside the document. From a spec. From a schema. From shared understanding between producer and consumer.")
(p (~tw :tokens "text-stone-600")
"This is why JSON hypermedia formats never achieve escape velocity. HAL, Siren, Hydra, JSON:API, UBER, Collection+JSON — each adds a linking convention on top of JSON, and each generates the same amount of adoption: enough for a conference talk, not enough for an ecosystem. The problem is not that the conventions are poorly designed. The problem is that a convention layered on inert data is " (em "always") " a separate document the client must already understand. You have not eliminated the manual. You have moved it from the system prompt to a media type specification."))
(~docs/section :title "IV. HTML carries but does not define itself" :id "html-carries"
(p :class "text-stone-600"
"HTML is closer to the mark. You " (em "can") " write the HTML specification in HTML — and indeed, the " (a :href "https://html.spec.whatwg.org/" :class "text-violet-600 hover:underline" "WHATWG specification") " is an HTML document. This already puts HTML in a different category from JSON. The format can at least " (em "carry") " its own definition.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"HTML is closer to the mark. You " (em "can") " write the HTML specification in HTML — and indeed, the " (a :href "https://html.spec.whatwg.org/" (~tw :tokens "text-violet-600 hover:underline") "WHATWG specification") " is an HTML document. This already puts HTML in a different category from JSON. The format can at least " (em "carry") " its own definition.")
(p (~tw :tokens "text-stone-600")
"But carrying is not defining. The HTML spec rendered in a browser is text and diagrams — documentation that happens to be displayed in the format it documents. The browser interpreting that document was built from a " (em "separate implementation") " — millions of lines of C++ in Chromium, Gecko, WebKit — that was written by reading the spec and translating it into executable code. The spec does not " (em "execute") ". It does not " (em "interpret") ". It does not " (em "define itself") " in any operative sense.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Put it this way: if you gave the HTML specification (as an HTML document) to a system that had never seen HTML before, could that system learn to render HTML by reading it? No. The document is English prose in HTML tags. The tags are meaningless without a pre-existing renderer. The spec " (em "presupposes") " the very thing it specifies. It is circular, but not " (em "productively") " circular — not metacircular in the way that would let the system bootstrap itself.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This matters because it means HTML's meaning is ultimately external too. More deeply embedded than JSON's — the browser internalizes the spec so thoroughly that HTML " (em "feels") " self-interpreting — but still dependent on a vast external system to give it life. The " (code "<form>") " tag is self-describing only to a client that already knows what forms are. To everything else, it is angle brackets."))
(~docs/section :title "V. SX defines itself" :id "sx-defines-itself"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The SX specification is written in SX. This sounds like the same trick as HTML — the spec in its own format — but it is categorically different.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(code "eval.sx") " defines the SX evaluator as s-expressions. Not as documentation " (em "about") " the evaluator. As the evaluator " (em "itself") ". A bootstrapper reads " (code "eval.sx") " and produces a working evaluator — in JavaScript, in Python, in any target language. " (code "parser.sx") " defines the SX parser as s-expressions. A bootstrapper reads it and produces a working parser. " (code "render.sx") " defines the renderer. " (code "primitives.sx") " defines the primitive operations.")
(~docs/code :src (highlight ";; From eval.sx — the evaluator defining itself:\n\n(define eval-expr\n (fn (expr env mode)\n (cond\n ((number? expr) expr)\n ((string? expr) expr)\n ((boolean? expr) expr)\n ((nil? expr) expr)\n ((symbol? expr) (resolve-symbol expr env))\n ((keyword? expr) (keyword-name expr))\n ((dict? expr) (eval-dict expr env mode))\n ((list? expr)\n (let ((head (first expr)))\n (if (symbol? head)\n (let ((name (symbol-name head)))\n (if (special-form? name)\n (eval-special-form name (rest expr) env mode)\n (eval-call expr env mode)))\n (eval-call expr env mode)))))))" "lisp"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not documentation. It is a " (em "program that defines the rules of its own interpretation") ". The evaluator that processes SX expressions is itself an SX expression. The spec does not merely " (em "describe") " how SX works — it " (em "is") " how SX works. Give this file to a bootstrapper, and out comes a functioning evaluator. The specification is executable. The definition " (em "is") " the implementation.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is what makes SX a genuine hypermedium. The meaning of an SX document is not external. It is not in a separate RFC. It is not in a browser engine compiled from a prose specification. The meaning is " (em "in the same language as the content") " — and it is the kind of meaning that executes. You do not need prior knowledge of SX to interpret SX, because SX carries the knowledge required to interpret it. You need only a bootstrapper — a minimal bridge to a host language — and the spec bootstraps the rest.")
(p :class "text-stone-600"
"The " (a :href "/sx/(etc.(essay.self-defining-medium))" :class "text-violet-600 hover:underline" "true hypermedium must define itself with itself") ". JSON cannot even attempt this. HTML can carry the words but not the meaning. SX carries the meaning because the meaning is code, and SX is code all the way down."))
(p (~tw :tokens "text-stone-600")
"The " (a :href "/sx/(etc.(essay.self-defining-medium))" (~tw :tokens "text-violet-600 hover:underline") "true hypermedium must define itself with itself") ". JSON cannot even attempt this. HTML can carry the words but not the meaning. SX carries the meaning because the meaning is code, and SX is code all the way down."))
(~docs/section :title "VI. What self-definition gives you" :id "consequences"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Every practical advantage of SX over JSON and HTML for hypermedia flows from this single property.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(strong "Progressive discovery") " works because controls are not metadata interpreted by convention — they are expressions evaluated by the same evaluator that processes content. The server renders conditional controls using the language itself:")
(~docs/code :src (highlight "(when can-cancel\n (button :sx-post \"/orders/4281/cancel\"\n :sx-confirm \"Cancel this order?\"\n \"Cancel order\"))" "lisp"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The " (code "when") " is not a convention layered on data. It is a special form defined in " (code "eval.sx") ". The server evaluates it. The client sees only the controls that survive evaluation. The state machine is authored in the language, not in metadata " (em "about") " the language.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(strong "Components") " work because the language has function abstraction — " (code "defcomp") " — defined in its own spec. A component is a reusable hypermedia control that accepts parameters and renders children. JSON cannot have components because JSON cannot define functions. HTML cannot have components natively — Web Components are defined in JavaScript, a " (em "separate") " language. SX components are defined in SX, evaluated by an evaluator defined in SX.")
(p :class "text-stone-600"
(strong "Evaluable URLs") " work because the URL is an s-expression — " (code "(etc.(essay.hypermedia-age-of-ai))") " — evaluated by the same evaluator. Following a link " (em "is") " calling a function. The addressing scheme is not a convention imposed from outside. It is the " (a :href "/sx/(applications.(sx-urls))" :class "text-violet-600 hover:underline" "language applied to navigation") ".")
(p :class "text-stone-600"
(strong "AI legibility") " works because the " (a :href "/sx/(etc.(essay.sx-and-ai))" :class "text-violet-600 hover:underline" "spec fits in a context window") ". An AI agent can load " (code "eval.sx") ", " (code "parser.sx") ", " (code "render.sx") ", and " (code "primitives.sx") " — roughly 3,000 lines — and hold the " (em "complete definition of the language") " alongside the content it is reading. It does not need training data about SX. It does not need documentation. It has the actual executable specification. The language it reads and the language that defines how to read it are the same language.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(strong "Evaluable URLs") " work because the URL is an s-expression — " (code "(etc.(essay.hypermedia-age-of-ai))") " — evaluated by the same evaluator. Following a link " (em "is") " calling a function. The addressing scheme is not a convention imposed from outside. It is the " (a :href "/sx/(applications.(sx-urls))" (~tw :tokens "text-violet-600 hover:underline") "language applied to navigation") ".")
(p (~tw :tokens "text-stone-600")
(strong "AI legibility") " works because the " (a :href "/sx/(etc.(essay.sx-and-ai))" (~tw :tokens "text-violet-600 hover:underline") "spec fits in a context window") ". An AI agent can load " (code "eval.sx") ", " (code "parser.sx") ", " (code "render.sx") ", and " (code "primitives.sx") " — roughly 3,000 lines — and hold the " (em "complete definition of the language") " alongside the content it is reading. It does not need training data about SX. It does not need documentation. It has the actual executable specification. The language it reads and the language that defines how to read it are the same language.")
(p (~tw :tokens "text-stone-600")
"None of these are features bolted onto a data format. They are consequences of a format that defines itself."))
(~docs/section :title "VII. What MCP gets wrong" :id "mcp"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"MCP's design reflects a fundamental confusion: it treats capability as a catalogue rather than an affordance. The server lists every tool. The model reads the list. The model calls a tool by name. The response is data. The model must maintain its own mental model of the server's state to know which tools are appropriate next.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is the exact inversion of the hypermedia principle. In a hypermedia system, the server tells you what you can do " (em "in each response") ". You do not need a mental model of the server because the server renders its own state into the controls it offers you.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But the deeper problem with MCP is not the catalogue model. It is that MCP tools are defined " (em "outside") " the protocol — in Python functions, TypeScript classes, whatever the server implementer chose. The tool definitions are opaque to the client. The model sees names and descriptions, not the actual logic. It is trusting documentation written by a human about code written by a human. Every layer of indirection is a place where meaning can leak.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In an SX hypermedia system, the controls in the response " (em "are") " the capability. Not a description of capability. Not a pointer to capability. The control itself — its structure, its attributes, its evaluable URL — carries everything needed to act on it. And the rules for interpreting the control are carried by the same language the control is written in. There is no indirection. There is no separate layer where meaning must be maintained. The response means what it says, and it says what it means, because it carries its own interpreter."))
(~docs/section :title "VIII. There is only the hypermedium" :id "the-hypermedium"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The hypermedia discourse frames the question as a competition between formats: HTML vs JSON, server-rendered vs client-rendered, REST vs RPC. Blow adds a new axis — human clients vs AI agents — and asks which format serves both. These are all the wrong questions. They assume that hypermedia is a property that a format can have in greater or lesser degree, and the task is to find the format with the most of it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Hypermedia is not a spectrum. It is a threshold. Either a format can define its own interpretation, or it cannot. If it cannot, it depends on external meaning — an RFC, a browser engine, a media type specification — and that dependency makes it something less than a " (em "medium") ". A medium is self-sustaining. It does not require a separate system to explain what it is. Sheet music is a medium because a musician can read it and produce sound. A JSON object with " (code "\"type\": \"sheet-music\"") " is not a medium. It is data that requires a separate program, written in a separate language, consulting a separate specification, to become anything at all.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"By this criterion, HTML is not hypermedia. It is the closest the web has come — close enough that the browser's deep internalization of the spec creates the " (em "illusion") " of self-interpretation. But the illusion breaks the moment you step outside the browser. Give HTML to a new client — an AI agent, a screen reader, a search crawler — and that client must reimagine the spec from training data, heuristics, and hope. The meaning was never in the HTML. It was in the browser.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"JSON is not hypermedia and never will be, no matter how many link relations you attach to it. The meaning is always elsewhere.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"There is only the hypermedium: a representation that defines its own interpretation. A representation where the spec is written in the language, and the spec " (em "is") " the language — executable, bootstrappable, self-sustaining. S-expressions are not the only possible instance of this. Any homoiconic, metacircular language could satisfy the criterion. But s-expressions are the simplest. The minimal syntax — " (code "(head args...)") " — is the minimal overhead between a format and self-definition. McCarthy arrived at this in 1958. It has taken sixty-eight years for the rest of computing to need it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The age of AI makes the need urgent. When your clients are no longer just browsers with built-in specs but arbitrary agents that must learn interpretation on the fly, a format that carries its own interpreter is not a luxury. It is the only thing that works. Not because it is clever. Because everything else depends on meaning that lives somewhere else — and " (em "somewhere else") " is the one place an ad-hoc agent cannot be guaranteed to look.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX represents the hypermedium. Not a new format in the format wars. Not a better JSON. Not a simpler HTML. The thing itself — a representation that " (em "means what it says") " because it carries the rules for saying it."))))

12
sx/sx/essays/index.sx
View File

@@ -4,12 +4,12 @@
(~docs/page
:title "Essays"
(div
:class "space-y-4"
(~tw :tokens "space-y-4")
(p
:class "text-lg text-stone-600 mb-4"
(~tw :tokens "text-lg text-stone-600 mb-4")
"Opinions, rationales, and explorations around SX and the ideas behind it.")
(div
:class "space-y-3"
(~tw :tokens "space-y-3")
(map
(fn
(item)
@@ -20,9 +20,9 @@
:sx-select "#sx-content"
:sx-swap "outerHTML"
:sx-push-url "true"
:class "block rounded border border-stone-200 p-4 hover:border-violet-300 hover:bg-violet-50 transition-colors"
(div :class "font-semibold text-stone-800" (get item "label"))
(~tw :tokens "block rounded border border-stone-200 p-4 hover:border-violet-300 hover:bg-violet-50 transition-colors")
(div (~tw :tokens "font-semibold text-stone-800") (get item "label"))
(when
(get item "summary")
(p :class "text-sm text-stone-500 mt-1" (get item "summary")))))
(p (~tw :tokens "text-sm text-stone-500 mt-1") (get item "summary")))))
essays-nav-items)))))

232
sx/sx/essays/no-alternative.sx
View File

@@ -1,29 +1,29 @@
(defcomp ~essays/no-alternative/essay-no-alternative ()
(~docs/page :title "There Is No Alternative"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"Every attempt to escape s-expressions leads back to s-expressions. This is not an accident.")
(~docs/section :title "The claim" :id "claim"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX uses s-expressions. When people encounter this, the first reaction is usually: " (em "why not use something more modern?") " Fair question. The answer is that there is nothing more modern. There are only things that are more " (em "familiar") " — and familiarity is not the same as fitness.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This essay examines what SX actually needs from its representation, surveys the alternatives, and shows that every candidate either fails to meet the requirements or converges toward s-expressions under a different name. The conclusion is uncomfortable but unavoidable: for what SX does, there is no alternative."))
(~docs/section :title "The requirements" :id "requirements"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX is not just a templating language. It is a language that serves simultaneously as:")
(ul :class "space-y-2 text-stone-600"
(ul (~tw :tokens "space-y-2 text-stone-600")
(li (strong "Markup") " — structure for HTML pages, components, layouts")
(li (strong "Programming language") " — conditionals, iteration, functions, macros, closures")
(li (strong "Wire format") " — what the server sends to the client over HTTP")
(li (strong "Data notation") " — configuration, page definitions, component registries")
(li (strong "Spec language") " — the SX specification is written in SX")
(li (strong "Metaprogramming substrate") " — macros that read, transform, and generate code"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Any replacement must handle all six roles with a single syntax. Not six syntaxes awkwardly interleaved — one. This constraint alone eliminates most candidates, because most representations were designed for one of these roles and are ill-suited to the others.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Beyond versatility, the representation must be:")
(ul :class "space-y-2 text-stone-600"
(ul (~tw :tokens "space-y-2 text-stone-600")
(li (strong "Homoiconic") " — code must be data and data must be code, because macros and self-hosting require it")
(li (strong "Parseable in one pass") " — no forward references, no context-dependent grammar, because the wire format must be parseable by a minimal client")
(li (strong "Structurally validatable") " — a syntactically valid expression must be checkable without evaluation, because untrusted code from federated nodes must be validated before execution")
@@ -33,166 +33,166 @@
(~docs/section :title "The candidates" :id "candidates"
(~docs/subsection :title "XML / HTML"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The obvious first thought. XML is a tree. HTML is markup. Why not use angle brackets?")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"XML fails on homoiconicity. The distinction between elements, attributes, text nodes, processing instructions, CDATA sections, entity references, and namespaces means the representation has multiple structural categories that cannot freely substitute for each other. An attribute is not an element. A text node is not a processing instruction. You cannot take an arbitrary XML fragment and use it as code, because XML has no concept of evaluation — it is a serialization format for trees, not a language.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"XML also fails on token efficiency. " (code "<div class=\"card\"><h2>Title</h2></div>") " versus " (code "(div :class \"card\" (h2 \"Title\"))") ". The closing tags carry zero information — they are pure redundancy. Over a full application, this redundancy compounds into significantly more bytes on the wire and significantly more tokens in an LLM context window.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"XSLT attempted to make XML a programming language. The result is universally regarded as a cautionary tale. Trying to express conditionals and iteration in a format designed for document markup produces something that is bad at both."))
(~docs/subsection :title "JSON"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"JSON is data notation. It has objects, arrays, strings, numbers, booleans, and null. It parses in one pass. It validates structurally. It is ubiquitous.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"JSON is not homoiconic because it has no concept of evaluation. It is " (em "inert") " data. To make JSON a programming language, you must invent a convention for representing code — and every such convention reinvents s-expressions with worse ergonomics:")
(~docs/code :src (highlight ";; JSON \"code\" (actual example from various JSON-based DSLs)\n{\"if\": [{\">\": [\"$.count\", 0]},\n {\"map\": [\"$.items\", {\"fn\": [\"item\", {\"get\": [\"item\", \"name\"]}]}]},\n {\"literal\": \"No items\"}]}\n\n;; The same thing in s-expressions\n(if (> count 0)\n (map (fn (item) (get item \"name\")) items)\n \"No items\")" "lisp"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The JSON version is an s-expression encoded in JSON's syntax — lists-of-lists with a head element that determines semantics. It has strictly more punctuation (colons, commas, braces, brackets, quotes around keys) and strictly less readability. Every JSON-based DSL that reaches sufficient complexity converges on this pattern and then wishes it had just used s-expressions."))
(~docs/subsection :title "YAML"
(p :class "text-stone-600"
"YAML is the other common data notation. It adds indentation sensitivity, anchors, aliases, multi-line strings, type coercion, and a " (a :href "https://yaml.org/spec/1.2.2/" :class "text-violet-600 hover:underline" "specification") " that is 240 pages long. The spec for SX's parser is 200 lines.")
(p :class "text-stone-600"
"Indentation sensitivity is a direct disqualifier for wire formats. Whitespace must survive serialization, transmission, minification, and reconstruction exactly — a fragility that s-expressions do not have. YAML also fails on structural validation: the " (a :href "https://en.wikipedia.org/wiki/Norway_problem" :class "text-violet-600 hover:underline" "Norway problem") " (" (code "NO") " parsed as boolean " (code "false") ") demonstrates that YAML's type coercion makes structural validation impossible without semantic knowledge of the schema.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"YAML is the other common data notation. It adds indentation sensitivity, anchors, aliases, multi-line strings, type coercion, and a " (a :href "https://yaml.org/spec/1.2.2/" (~tw :tokens "text-violet-600 hover:underline") "specification") " that is 240 pages long. The spec for SX's parser is 200 lines.")
(p (~tw :tokens "text-stone-600")
"Indentation sensitivity is a direct disqualifier for wire formats. Whitespace must survive serialization, transmission, minification, and reconstruction exactly — a fragility that s-expressions do not have. YAML also fails on structural validation: the " (a :href "https://en.wikipedia.org/wiki/Norway_problem" (~tw :tokens "text-violet-600 hover:underline") "Norway problem") " (" (code "NO") " parsed as boolean " (code "false") ") demonstrates that YAML's type coercion makes structural validation impossible without semantic knowledge of the schema.")
(p (~tw :tokens "text-stone-600")
"YAML is not homoiconic. It has no evaluation model. Like JSON, any attempt to encode logic in YAML produces s-expressions with worse syntax."))
(~docs/subsection :title "JSX / Template literals"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"JSX is the closest mainstream technology to what SX does — it embeds markup in a programming language. But JSX is not a representation; it is a compile target. " (code "<Card title=\"Hi\">content</Card>") " compiles to " (code "React.createElement(Card, {title: \"Hi\"}, \"content\")") ". The angle-bracket syntax is sugar that does not survive to runtime.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This means JSX cannot be a wire format — the client must have the compiler. It cannot be a spec language — you cannot write a JSX spec in JSX without a build step. It cannot be a data notation — it requires JavaScript evaluation context. JSX handles exactly one of the six roles (markup) and delegates the others to JavaScript, CSS, JSON, and whatever build tool assembles them.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Template literals (tagged templates in JavaScript, Jinja, ERB, etc.) are string interpolation. They embed code in strings or strings in code, depending on which layer you consider primary. Neither direction produces a homoiconic representation. You cannot write a macro that reads a template literal and transforms it as data, because the template literal is a string — opaque, uninspectable, and unstructured."))
(~docs/subsection :title "Tcl"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Tcl is the most interesting near-miss. \"Everything is a string\" is a radical simplification. The syntax is minimal: commands are words separated by spaces, braces group without substitution, brackets evaluate. Tcl is effectively homoiconic — code is strings, strings are code, and " (code "eval") " is the universal mechanism.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Where Tcl falls short is structural validation. Because everything is a string, you cannot check that a Tcl program is well-formed without evaluating it. Unmatched braces inside string values are indistinguishable from syntax errors without context. S-expressions have a trivial structural check — balanced parentheses — that requires no evaluation and no context. For sandboxed evaluation of untrusted code (federated expressions from other nodes), this difference is decisive.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Tcl also lacks native tree structure. Lists are flat strings that are parsed on demand. Nested structure exists by convention, not by grammar. This makes composition more fragile than s-expressions, where nesting is the fundamental structural primitive."))
(~docs/subsection :title "Rebol / Red"
(p :class "text-stone-600"
"Rebol is the strongest alternative. It is homoiconic — code is data. It has minimal syntax. It has dialecting — the ability to create domain-specific languages within the language. It is a single representation for code, data, and markup. " (a :href "https://en.wikipedia.org/wiki/Rebol" :class "text-violet-600 hover:underline" "Carl Sassenrath") " designed it explicitly to solve the problems that SX also targets.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Rebol is the strongest alternative. It is homoiconic — code is data. It has minimal syntax. It has dialecting — the ability to create domain-specific languages within the language. It is a single representation for code, data, and markup. " (a :href "https://en.wikipedia.org/wiki/Rebol" (~tw :tokens "text-violet-600 hover:underline") "Carl Sassenrath") " designed it explicitly to solve the problems that SX also targets.")
(p (~tw :tokens "text-stone-600")
"Rebol's limitation is practical, not theoretical. The language is obscure. Modern AI models have almost no training data for it — generating reliable Rebol would require extensive fine-tuning or few-shot prompting. There is no ecosystem of libraries, no community producing components, no federation protocol. And Rebol's type system (over 40 built-in datatypes including " (code "url!") ", " (code "email!") ", " (code "money!") ") makes the parser substantially more complex than s-expressions, which have essentially one composite type: the list.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Rebol demonstrates that the design space around s-expressions has room for variation. But the variations add complexity without adding expressiveness — and in the current landscape, complexity kills AI compatibility and adoption equally."))
(~docs/subsection :title "Forth / stack-based"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Forth has the most minimal syntax imaginable: words separated by spaces. No parentheses, no brackets, no delimiters. The program is a flat sequence of tokens. This is simpler than s-expressions.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But Forth's simplicity is deceptive. The flat token stream encodes tree structure " (em "implicitly") " via stack effects. Understanding what a Forth program does requires mentally simulating the stack — tracking what each word pushes and pops. This is precisely the kind of implicit state tracking that both humans and AI models struggle with. A nested s-expression makes structure " (em "visible") ". A Forth program hides it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"For markup, this is fatal. " (code "3 1 + 4 * 2 /") " is arithmetic. Now imagine a page layout expressed as stack operations. The nesting that makes " (code "(div (h2 \"Title\") (p \"Body\"))") " self-evident becomes an exercise in mental bookkeeping. UI is trees. Stack languages are not.")))
(~docs/section :title "The convergence" :id "convergence"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Every alternative either fails to meet the requirements or reinvents s-expressions:")
(div :class "overflow-x-auto rounded border border-stone-200 mb-4"
(table :class "w-full text-left text-sm"
(thead (tr :class "border-b border-stone-200 bg-stone-100"
(th :class "px-3 py-2 font-medium text-stone-600" "Candidate")
(th :class "px-3 py-2 font-medium text-stone-600" "Homoiconic")
(th :class "px-3 py-2 font-medium text-stone-600" "Structural validation")
(th :class "px-3 py-2 font-medium text-stone-600" "Token-efficient")
(th :class "px-3 py-2 font-medium text-stone-600" "Tree-native")
(th :class "px-3 py-2 font-medium text-stone-600" "AI-trainable")))
(div (~tw :tokens "overflow-x-auto rounded border border-stone-200 mb-4")
(table (~tw :tokens "w-full text-left text-sm")
(thead (tr (~tw :tokens "border-b border-stone-200 bg-stone-100")
(th (~tw :tokens "px-3 py-2 font-medium text-stone-600") "Candidate")
(th (~tw :tokens "px-3 py-2 font-medium text-stone-600") "Homoiconic")
(th (~tw :tokens "px-3 py-2 font-medium text-stone-600") "Structural validation")
(th (~tw :tokens "px-3 py-2 font-medium text-stone-600") "Token-efficient")
(th (~tw :tokens "px-3 py-2 font-medium text-stone-600") "Tree-native")
(th (~tw :tokens "px-3 py-2 font-medium text-stone-600") "AI-trainable")))
(tbody
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "XML/HTML")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-green-700" "Yes"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "JSON")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-green-700" "Yes"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "YAML")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-amber-600" "Moderate")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-green-700" "Yes"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "JSX")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-red-600" "Needs compiler")
(td :class "px-3 py-2 text-amber-600" "Moderate")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-green-700" "Yes"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "Tcl")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-red-600" "No"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "Rebol/Red")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-amber-600" "Complex")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-red-600" "No"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "Forth")
(td :class "px-3 py-2 text-amber-600" "Sort of")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-green-700" "Yes")
(td :class "px-3 py-2 text-red-600" "No")
(td :class "px-3 py-2 text-red-600" "No"))
(tr :class "border-b border-stone-200 bg-violet-50"
(td :class "px-3 py-2 font-semibold text-violet-800" "S-expressions")
(td :class "px-3 py-2 text-green-700 font-semibold" "Yes")
(td :class "px-3 py-2 text-green-700 font-semibold" "Yes")
(td :class "px-3 py-2 text-green-700 font-semibold" "Yes")
(td :class "px-3 py-2 text-green-700 font-semibold" "Yes")
(td :class "px-3 py-2 text-green-700 font-semibold" "Yes")))))
(p :class "text-stone-600"
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "XML/HTML")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "JSON")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "YAML")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-amber-600") "Moderate")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "JSX")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-red-600") "Needs compiler")
(td (~tw :tokens "px-3 py-2 text-amber-600") "Moderate")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "Tcl")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-red-600") "No"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "Rebol/Red")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-amber-600") "Complex")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-red-600") "No"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "Forth")
(td (~tw :tokens "px-3 py-2 text-amber-600") "Sort of")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-green-700") "Yes")
(td (~tw :tokens "px-3 py-2 text-red-600") "No")
(td (~tw :tokens "px-3 py-2 text-red-600") "No"))
(tr (~tw :tokens "border-b border-stone-200 bg-violet-50")
(td (~tw :tokens "px-3 py-2 font-semibold text-violet-800") "S-expressions")
(td (~tw :tokens "px-3 py-2 text-green-700 font-semibold") "Yes")
(td (~tw :tokens "px-3 py-2 text-green-700 font-semibold") "Yes")
(td (~tw :tokens "px-3 py-2 text-green-700 font-semibold") "Yes")
(td (~tw :tokens "px-3 py-2 text-green-700 font-semibold") "Yes")
(td (~tw :tokens "px-3 py-2 text-green-700 font-semibold") "Yes")))))
(p (~tw :tokens "text-stone-600")
"No candidate achieves all five properties. The closest — Rebol — fails on AI trainability, which is not a theoretical concern but a practical one: a representation that AI cannot generate reliably is a representation that cannot participate in the coming decade of software development."))
(~docs/section :title "Why not invent something new?" :id "invent"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The objection might be: fine, existing alternatives fall short, but why not design a new representation that has all these properties without the parentheses?")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Try it. You need a tree structure (for markup and composition). You need a uniform representation (for homoiconicity). You need a delimiter that is unambiguous (for one-pass parsing and structural validation). You need minimum syntactic overhead (for token efficiency).")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A tree needs a way to mark where a node begins and ends. The minimal delimiter pair is two characters — one for open, one for close. S-expressions use " (code "(") " and " (code ")") ". You could use " (code "[") " and " (code "]") ", or " (code "{") " and " (code "}") ", or " (code "BEGIN") " and " (code "END") ", or indentation. But " (code "[list]") " and " (code "{list}") " are just s-expressions with different brackets. " (code "BEGIN/END") " adds token overhead. Indentation adds whitespace sensitivity, which breaks wire-format reliability.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"You could try eliminating delimiters entirely and using a binary format. But binary formats are not human-readable, not human-writable, and not inspectable in a terminal — which means they cannot serve as a programming language. The developer experience of reading and writing code requires a text-based representation, and the minimal text-based tree delimiter is a matched pair of single characters.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"You could try significant whitespace — indentation-based nesting like Python or Haskell. This works for programming languages where the code is stored in files and processed by a single toolchain. It does not work for wire formats, where the representation must survive HTTP transfer, server-side generation, client-side parsing, minification, storage in databases, embedding in script tags, and concatenation with other expressions. Whitespace-sensitive formats are fragile in exactly the contexts where SX operates.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Every path through the design space either arrives at parenthesized prefix notation — s-expressions — or introduces complexity that violates one of the requirements. This is not a failure of imagination. It is a consequence of the requirements being simultaneously demanding and precise. The solution space has one optimum, and McCarthy found it in 1958."))
(~docs/section :title "The parentheses objection" :id "parentheses"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The real objection to s-expressions is not technical. It is aesthetic. People do not like parentheses. They look unfamiliar. They feel old. They trigger memories of computer science lectures about recursive descent parsers.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is a human problem, not a representation problem. And it is a human problem with a known trajectory: every programmer who has used a Lisp for more than a few weeks stops seeing the parentheses. They see the tree. The delimiters become invisible, like the spaces between words in English. You do not see spaces. You see words. Lisp programmers do not see parentheses. They see structure.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"More to the point: in the world we are entering, most code will be generated by AI and rendered by machines. The human reads the " (em "output") " — the rendered page, the test results, the behaviour. The s-expressions are an intermediate representation that the human steers but does not need to manually type or visually parse character-by-character. The aesthetic objection dissolves when the representation is a conversation between the human's intent and the machine's generation, not something the human stares at in a text editor.")
(p :class "text-stone-600"
"The author of SX has never opened the codebase in an editor. Every file was created through " (a :href "https://claude.ai/" :class "text-violet-600 hover:underline" "Claude") " in a terminal. The parentheses are between the human and the machine, and neither one minds them."))
(p (~tw :tokens "text-stone-600")
"The author of SX has never opened the codebase in an editor. Every file was created through " (a :href "https://claude.ai/" (~tw :tokens "text-violet-600 hover:underline") "Claude") " in a terminal. The parentheses are between the human and the machine, and neither one minds them."))
(~docs/section :title "The conclusion" :id "conclusion"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"S-expressions are the minimal tree representation. They are the only widely-known homoiconic notation. They have trivial structural validation, maximum token efficiency, and native composability. They are well-represented in AI training data. Every alternative either fails on one of these criteria or converges toward s-expressions under a different name.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a claim that s-expressions are the best syntax for every programming language. They are not. Python's indentation-based syntax is better for imperative scripting. Haskell's layout rules are better for type-heavy functional programming. SQL is better for relational queries.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The claim is narrower and stronger: for a system that must simultaneously serve as markup, programming language, wire format, data notation, spec language, and metaprogramming substrate — with homoiconicity, one-pass parsing, structural validation, token efficiency, and composability — there is no alternative to s-expressions. Not because alternatives have not been tried. Not because the design space has not been explored. But because the requirements, when stated precisely, admit exactly one family of solutions, and that family is the one McCarthy discovered sixty-seven years ago.")
(p :class "text-stone-600"
"The name for this, borrowed from a " (a :href "https://en.wikipedia.org/wiki/There_is_no_alternative" :class "text-violet-600 hover:underline" "different context entirely") ", is " (em "TINA") " — there is no alternative. Not as a political slogan, but as a mathematical observation. When you need a minimal, homoiconic, structurally-validatable, token-efficient, tree-native, AI-compatible representation for the web, you need s-expressions. Everything else is either less capable or isomorphic."))))
(p (~tw :tokens "text-stone-600")
"The name for this, borrowed from a " (a :href "https://en.wikipedia.org/wiki/There_is_no_alternative" (~tw :tokens "text-violet-600 hover:underline") "different context entirely") ", is " (em "TINA") " — there is no alternative. Not as a political slogan, but as a mathematical observation. When you need a minimal, homoiconic, structurally-validatable, token-efficient, tree-native, AI-compatible representation for the web, you need s-expressions. Everything else is either less capable or isomorphic."))))

2
sx/sx/essays/on-demand-css.sx
View File

@@ -1,2 +1,2 @@
(defcomp ~essays/on-demand-css/essay-on-demand-css ()
(~docs/page :title "On-Demand CSS: Killing the Tailwind Bundle" (~docs/section :title "The problem" :id "problem" (p :class "text-stone-600" "Tailwind CSS generates a utility class for every possible combination. The full CSS file is ~4MB. The purged output for a typical site is 20-50KB. Purging requires a build step that scans your source files for class names. This means: a build tool, a config file, a CI step, and a prayer that the scanner finds all your dynamic classes.")) (~docs/section :title "The sx approach" :id "approach" (p :class "text-stone-600" "sx takes a different path. At server startup, the full Tailwind CSS file is parsed into a dictionary keyed by class name. When rendering a response, sx scans the s-expression source for :class attribute values and looks up only those classes. The result: exact CSS, zero build step.") (p :class "text-stone-600" "Component definitions are pre-scanned at registration time. Page-specific sx is scanned at request time. The union of classes is resolved to CSS rules.")) (~docs/section :title "Incremental delivery" :id "incremental" (p :class "text-stone-600" "After the first page load, the client tracks which CSS classes it already has. On subsequent navigations, it sends a hash of its known classes in the SX-Css header. The server computes the diff and sends only new rules. A typical navigation adds 0-10 new rules — a few hundred bytes at most.")) (~docs/section :title "The tradeoff" :id "tradeoff" (p :class "text-stone-600" "The server holds ~4MB of parsed CSS in memory. Regex scanning is not perfect — dynamically constructed class names will not be found. In practice this rarely matters because sx components use mostly static class strings."))))
(~docs/page :title "On-Demand CSS: Killing the Tailwind Bundle" (~docs/section :title "The problem" :id "problem" (p (~tw :tokens "text-stone-600") "Tailwind CSS generates a utility class for every possible combination. The full CSS file is ~4MB. The purged output for a typical site is 20-50KB. Purging requires a build step that scans your source files for class names. This means: a build tool, a config file, a CI step, and a prayer that the scanner finds all your dynamic classes.")) (~docs/section :title "The sx approach" :id "approach" (p (~tw :tokens "text-stone-600") "sx takes a different path. At server startup, the full Tailwind CSS file is parsed into a dictionary keyed by class name. When rendering a response, sx scans the s-expression source for :class attribute values and looks up only those classes. The result: exact CSS, zero build step.") (p (~tw :tokens "text-stone-600") "Component definitions are pre-scanned at registration time. Page-specific sx is scanned at request time. The union of classes is resolved to CSS rules.")) (~docs/section :title "Incremental delivery" :id "incremental" (p (~tw :tokens "text-stone-600") "After the first page load, the client tracks which CSS classes it already has. On subsequent navigations, it sends a hash of its known classes in the SX-Css header. The server computes the diff and sends only new rules. A typical navigation adds 0-10 new rules — a few hundred bytes at most.")) (~docs/section :title "The tradeoff" :id "tradeoff" (p (~tw :tokens "text-stone-600") "The server holds ~4MB of parsed CSS in memory. Regex scanning is not perfect — dynamically constructed class names will not be found. In practice this rarely matters because sx components use mostly static class strings."))))

12
sx/sx/essays/philosophy-index.sx
View File

@@ -4,12 +4,12 @@
(~docs/page
:title "Philosophy"
(div
:class "space-y-4"
(~tw :tokens "space-y-4")
(p
:class "text-lg text-stone-600 mb-4"
(~tw :tokens "text-lg text-stone-600 mb-4")
"The deeper ideas behind SX — manifestos, self-reference, and the philosophical traditions that shaped the language.")
(div
:class "space-y-3"
(~tw :tokens "space-y-3")
(map
(fn
(item)
@@ -20,9 +20,9 @@
:sx-select "#sx-content"
:sx-swap "outerHTML"
:sx-push-url "true"
:class "block rounded border border-stone-200 p-4 hover:border-violet-300 hover:bg-violet-50 transition-colors"
(div :class "font-semibold text-stone-800" (get item "label"))
(~tw :tokens "block rounded border border-stone-200 p-4 hover:border-violet-300 hover:bg-violet-50 transition-colors")
(div (~tw :tokens "font-semibold text-stone-800") (get item "label"))
(when
(get item "summary")
(p :class "text-sm text-stone-500 mt-1" (get item "summary")))))
(p (~tw :tokens "text-sm text-stone-500 mt-1") (get item "summary")))))
philosophy-nav-items)))))

116
sx/sx/essays/platonic-sx.sx
View File

@@ -1,63 +1,63 @@
(defcomp ~essays/platonic-sx/essay-platonic-sx ()
(~docs/page :title "Platonic SX"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"The allegory of the cave, the theory of Forms, and why a hypermedium "
"that defines itself participates in something Plato would have recognized.")
(~docs/section :title "The cave" :id "the-cave"
(p :class "text-stone-600"
"In Book VII of the " (a :href "https://en.wikipedia.org/wiki/Allegory_of_the_cave" :class "text-violet-600 hover:underline" "Republic")
(p (~tw :tokens "text-stone-600")
"In Book VII of the " (a :href "https://en.wikipedia.org/wiki/Allegory_of_the_cave" (~tw :tokens "text-violet-600 hover:underline") "Republic")
", Plato describes prisoners chained in a cave, facing a wall. "
"Behind them burns a fire; between the fire and the prisoners, figures move, "
"casting shadows on the wall. The prisoners have never seen the figures directly. "
"They take the shadows for reality.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The allegory is about representation. The shadows are not the things themselves "
"but projections \u2014 reduced, flattened, stripped of depth and colour. "
"The prisoners mistake the representation for the thing represented. "
"They build entire theories about the behaviour of shadows, never suspecting "
"that the shadows are derived from something more real.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The web is a cave."))
(~docs/section :title "Shadows on the wall" :id "shadows"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"An HTML page is a shadow. It is a projection of the thing the author intended \u2014 "
"a structure, a meaning, a behaviour \u2014 flattened into a string of angle brackets. "
"The structure is lost in the serialization. The meaning is implicit in class names "
"and data attributes. The behaviour is bolted on in a separate language (JavaScript) "
"that has no formal relationship to the markup it manipulates.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"CSS is another shadow \u2014 a projection of visual intention into a cascade of "
"property-value pairs, separated from the structure it describes. "
"JSON is a shadow of data, stripped of type, context, and behaviour. "
"REST is a shadow of computation, reduced to verbs and resource paths.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Each format is a lossy projection. And crucially, each projects into a "
(em "different") " medium. HTML for structure. CSS for style. JavaScript for behaviour. "
"JSON for data. The original unity \u2014 the " (em "thing itself") " \u2014 is scattered "
"across four representations that cannot reference each other "
"without external convention.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Plato would have recognized this immediately. The Forms are one. "
"The shadows are many. The task of philosophy is to see past the shadows."))
(~docs/section :title "The theory of Forms" :id "forms"
(p :class "text-stone-600"
"Plato's " (a :href "https://en.wikipedia.org/wiki/Theory_of_forms" :class "text-violet-600 hover:underline" "theory of Forms")
(p (~tw :tokens "text-stone-600")
"Plato's " (a :href "https://en.wikipedia.org/wiki/Theory_of_forms" (~tw :tokens "text-violet-600 hover:underline") "theory of Forms")
" holds that behind every particular instance \u2014 every chair, every circle, "
"every act of justice \u2014 there exists an ideal Form: the perfect Chair, "
"the perfect Circle, Justice itself. Particular instances participate in their Form "
"but are always imperfect copies. The Form is eternal, immutable, and more real "
"than any instance.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A " (code "defcomp") " definition is a Form:")
(~docs/code :src
@@ -67,45 +67,45 @@
" (when subtitle (p :class \"text-stone-500\" subtitle))\n"
" children))"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a card. It is the " (em "idea") " of a card \u2014 the structure that every "
"particular card participates in. When the server evaluates "
(code "(~card :title \"Plato\" :subtitle \"428 BC\")") ", it produces a particular instance: "
"an HTML fragment, a shadow on a specific wall. The Form persists. "
"The shadow is consumed and replaced on the next render.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In Plato's ontology, Forms are more real than particulars because they are "
"what particulars " (em "depend on") ". The HTML output depends on the component definition. "
"The component definition does not depend on any particular output. "
"It is prior, in the way that axioms are prior to theorems."))
(~docs/section :title "The divided line" :id "divided-line"
(p :class "text-stone-600"
"In the Republic, Plato describes " (a :href "https://en.wikipedia.org/wiki/Analogy_of_the_divided_line" :class "text-violet-600 hover:underline" "a line divided into four segments")
(p (~tw :tokens "text-stone-600")
"In the Republic, Plato describes " (a :href "https://en.wikipedia.org/wiki/Analogy_of_the_divided_line" (~tw :tokens "text-violet-600 hover:underline") "a line divided into four segments")
", representing degrees of reality and knowledge:")
(div :class "overflow-x-auto mb-6"
(table :class "min-w-full text-sm"
(div (~tw :tokens "overflow-x-auto mb-6")
(table (~tw :tokens "min-w-full text-sm")
(thead (tr
(th :class "text-left pr-4 pb-2 font-semibold" "Segment")
(th :class "text-left pr-4 pb-2 font-semibold" "Plato")
(th :class "text-left pb-2 font-semibold" "SX")))
(th (~tw :tokens "text-left pr-4 pb-2 font-semibold") "Segment")
(th (~tw :tokens "text-left pr-4 pb-2 font-semibold") "Plato")
(th (~tw :tokens "text-left pb-2 font-semibold") "SX")))
(tbody
(tr (td :class "pr-4 py-1" "Images")
(td :class "pr-4" "Shadows, reflections")
(tr (td (~tw :tokens "pr-4 py-1") "Images")
(td (~tw :tokens "pr-4") "Shadows, reflections")
(td "The rendered HTML in the browser \u2014 a momentary projection"))
(tr (td :class "pr-4 py-1" "Sensible objects")
(td :class "pr-4" "Physical things")
(tr (td (~tw :tokens "pr-4 py-1") "Sensible objects")
(td (~tw :tokens "pr-4") "Physical things")
(td "The SX wire format \u2014 structured but still particular"))
(tr (td :class "pr-4 py-1" "Mathematical objects")
(td :class "pr-4" "Numbers, geometric shapes")
(tr (td (~tw :tokens "pr-4 py-1") "Mathematical objects")
(td (~tw :tokens "pr-4") "Numbers, geometric shapes")
(td "Component definitions, the CEK machine, continuation frames"))
(tr (td :class "pr-4 py-1" "The Good / Forms")
(td :class "pr-4" "The Form of Forms")
(tr (td (~tw :tokens "pr-4 py-1") "The Good / Forms")
(td (~tw :tokens "pr-4") "The Form of Forms")
(td "The s-expression itself \u2014 the representation that represents")))))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The bottom of the line is images \u2014 the DOM, pixels on screen. "
"Moving up: the SX wire format preserves more structure than HTML "
"(it retains the component calls, the s-expression nesting). "
@@ -114,7 +114,7 @@
"At the top: the s-expression itself, which is both the medium of definition "
"and the thing defined.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Plato's line is a hierarchy of " (em "participation") ". "
"Each level participates in the one above. "
"The rendered HTML participates in the component definition. "
@@ -124,27 +124,27 @@
"In computation itself. In the CEK machine. In logic."))
(~docs/section :title "Anamnesis: the evaluator remembers" :id "anamnesis"
(p :class "text-stone-600"
"Plato believed that learning is " (a :href "https://en.wikipedia.org/wiki/Anamnesis_(philosophy)" :class "text-violet-600 hover:underline" "recollection")
(p (~tw :tokens "text-stone-600")
"Plato believed that learning is " (a :href "https://en.wikipedia.org/wiki/Anamnesis_(philosophy)" (~tw :tokens "text-violet-600 hover:underline") "recollection")
" \u2014 " (em "anamnesis") ". The soul has seen the Forms before birth; "
"education is not acquiring new knowledge but remembering what is already known. "
"The particular reminds us of the universal.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The SX evaluator does something structurally similar. "
"When the browser receives SX wire format \u2014 ")
(~docs/code :src
"(~card :title \"Plato\" :subtitle \"428 BC\")")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
" \u2014 it does not receive instructions for rendering. It receives a " (em "name") " "
"and a set of arguments. The evaluator already knows " (code "~card") ". "
"It has the Form in its component environment. "
"The wire format is a reminder: " (em "produce the instance you already know how to produce") ". "
"The particular prompts the evaluator to recollect the universal.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is why the SX wire format is so small. It doesn't transmit the " (em "what") " "
"\u2014 the full HTML, the complete structure. It transmits the " (em "which") " "
"\u2014 which Form, which arguments. The evaluator supplies the rest from memory. "
@@ -152,21 +152,21 @@
"because the client " (em "remembers") "."))
(~docs/section :title "Platonic aesthetics" :id "aesthetics"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"For Plato, beauty is not subjective. A thing is beautiful to the degree "
"that it participates in the " (a :href "https://en.wikipedia.org/wiki/Platonic_beauty" :class "text-violet-600 hover:underline" "Form of Beauty")
"that it participates in the " (a :href "https://en.wikipedia.org/wiki/Platonic_beauty" (~tw :tokens "text-violet-600 hover:underline") "Form of Beauty")
" \u2014 which is to say, to the degree that it exhibits "
(em "order") ", " (em "proportion") ", and " (em "unity") ". "
"The " (a :href "https://en.wikipedia.org/wiki/Symposium_(Plato)" :class "text-violet-600 hover:underline" "Symposium")
"The " (a :href "https://en.wikipedia.org/wiki/Symposium_(Plato)" (~tw :tokens "text-violet-600 hover:underline") "Symposium")
" describes an ascent from beautiful bodies to beautiful souls to beautiful ideas, "
"culminating in Beauty itself \u2014 the Form that makes all beautiful things beautiful.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"There is a beauty in s-expressions that is Platonic in this precise sense. "
"Not decorative beauty \u2014 no one finds parentheses pretty. "
"But structural beauty: the kind Plato meant.")
(ul :class "list-disc pl-6 mb-4 space-y-2 text-stone-600"
(ul (~tw :tokens "list-disc pl-6 mb-4 space-y-2 text-stone-600")
(li (strong "Unity") " \u2014 one representation for everything. "
"Code, data, markup, wire format, component definitions, the evaluator itself. "
"No seams, no translation boundaries, no format negotiation. "
@@ -181,7 +181,7 @@
"Each layer is definable in terms of the one below. "
"No circular dependencies, no ad hoc escape hatches, no exceptions to the rules."))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Plato would say that these properties are not incidental but necessary \u2014 "
"they follow from the proximity of s-expressions to the Forms themselves. "
"A representation that can represent itself has fewer impediments "
@@ -190,19 +190,19 @@
"that requires a separate meta-representation to describe it."))
(~docs/section :title "The escape from the cave" :id "escape"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In the allegory, one prisoner is freed and dragged up into the sunlight. "
"At first the light is blinding. He can only look at reflections in water, "
"then at objects, then at the sun itself. He returns to the cave "
"and tries to tell the others what he saw. They think he is mad.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The web's cave is comfortable. Developers have built elaborate theories "
"of the shadows \u2014 virtual DOMs, hydration strategies, build tool chains, "
"CSS-in-JS, state management libraries. Each theory explains how shadows behave. "
"None asks why we are working with shadows at all.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The escape is not a technology. It is a shift in perspective: "
(em "stop working with projections and work with the thing itself") ". "
"An s-expression is not a projection of structure into text \u2014 "
@@ -211,21 +211,21 @@
"The SX evaluator is not described by a specification \u2014 "
"it IS the specification, executing.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is what it means for a representation to be homoiconic. "
"The map is the territory. The shadow and the figure are the same thing. "
"The cave and the sunlit world collapse into one."))
(~docs/section :title "The demiurge" :id "demiurge"
(p :class "text-stone-600"
"In the " (a :href "https://en.wikipedia.org/wiki/Timaeus_(dialogue)" :class "text-violet-600 hover:underline" "Timaeus")
", Plato introduces the " (a :href "https://en.wikipedia.org/wiki/Demiurge" :class "text-violet-600 hover:underline" "demiurge")
(p (~tw :tokens "text-stone-600")
"In the " (a :href "https://en.wikipedia.org/wiki/Timaeus_(dialogue)" (~tw :tokens "text-violet-600 hover:underline") "Timaeus")
", Plato introduces the " (a :href "https://en.wikipedia.org/wiki/Demiurge" (~tw :tokens "text-violet-600 hover:underline") "demiurge")
" \u2014 the divine craftsman who looks at the eternal Forms and fashions "
"the physical world in their image. The demiurge does not create the Forms. "
"He creates " (em "instances") " of them, in a medium (matter) that is less perfect "
"than the Forms themselves.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The bootstrapper is a demiurge. It looks at the Forms (" (code "eval.sx") ", "
(code "parser.sx") ", " (code "cek.sx") ") and fashions instances in a material medium: "
"Python, JavaScript. The instances are less perfect than the Forms \u2014 "
@@ -233,7 +233,7 @@
"memory layouts. But they " (em "participate") " in the Forms. "
"They are correct to the degree that they faithfully instantiate the spec.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The demiurge is not omnipotent. He works with what the medium allows. "
"The Python bootstrapper emits " (code "def") " and " (code "lambda") "; "
"the JavaScript bootstrapper emits " (code "var") " and " (code "function") ". "
@@ -241,34 +241,34 @@
"is the same. Multiple demiurges, one set of Forms, many material instances."))
(~docs/section :title "The good" :id "the-good"
(p :class "text-stone-600"
"At the apex of Plato's hierarchy is the " (a :href "https://en.wikipedia.org/wiki/Form_of_the_Good" :class "text-violet-600 hover:underline" "Form of the Good")
(p (~tw :tokens "text-stone-600")
"At the apex of Plato's hierarchy is the " (a :href "https://en.wikipedia.org/wiki/Form_of_the_Good" (~tw :tokens "text-violet-600 hover:underline") "Form of the Good")
" \u2014 the Form that makes all other Forms intelligible. "
"It is not itself a thing but the condition for all things being knowable. "
"It is the sun in the allegory: the source of light that reveals everything else.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"If we take the analogy seriously, what is SX's Form of the Good? "
"What makes the hierarchy \u2014 CEK, continuations, scoped effects, patterns \u2014 intelligible as a whole?")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"It is the principle that " (strong "the representation and the thing represented should be identical") ". "
"Code is data. The specification is the implementation. The wire format is the source syntax. "
"The evaluator evaluates itself. Every level of the hierarchy obeys this principle, "
"and it is what makes each level intelligible from the one below.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a design principle in the engineering sense \u2014 a guideline to be followed or violated. "
"It is the structural " (em "reason") " the hierarchy exists at all. "
"Remove it and the layers collapse. Restore it and they reconstitute. "
"It is prior to the hierarchy, in the way the Good is prior to the Forms.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Plato would have understood this. He spent his life searching for the thing "
"that is most itself, least dependent on anything else, most fully real. "
"An s-expression that defines its own evaluator, parsed by its own parser, "
"bootstrapped to every medium, generating instances of itself in perpetuity \u2014 "
"this is as close to a Platonic Form as computation gets."))
(p :class "text-stone-500 text-sm italic mt-12"
(p (~tw :tokens "text-stone-500 text-sm italic mt-12")
"The unexamined code is not worth running.")))

76
sx/sx/essays/react-is-hypermedia.sx
View File

@@ -4,83 +4,83 @@
(defcomp ~essays/react-is-hypermedia/essay-react-is-hypermedia ()
(~docs/page :title "React is Hypermedia"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"A React Island is a hypermedia control. Its behavior is specified in SX.")
(~docs/section :title "I. The argument" :id "argument"
(p :class "text-stone-600"
"React is not hypermedia. Everyone knows this. React is a JavaScript UI library. It renders components to a virtual DOM. It diffs. It patches. It manages state. It does none of the things that define " (a :href "https://en.wikipedia.org/wiki/Hypermedia" :class "text-violet-600 hover:underline" "hypermedia") " — server-driven content, links as the primary interaction mechanism, representations that carry their own controls.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"React is not hypermedia. Everyone knows this. React is a JavaScript UI library. It renders components to a virtual DOM. It diffs. It patches. It manages state. It does none of the things that define " (a :href "https://en.wikipedia.org/wiki/Hypermedia" (~tw :tokens "text-violet-600 hover:underline") "hypermedia") " — server-driven content, links as the primary interaction mechanism, representations that carry their own controls.")
(p (~tw :tokens "text-stone-600")
"And yet. Consider what a React Island actually is:")
(ul :class "list-disc pl-6 space-y-1 text-stone-600"
(ul (~tw :tokens "list-disc pl-6 space-y-1 text-stone-600")
(li "It is embedded in a server-rendered page.")
(li "Its initial content is delivered as HTML (or as serialised SX, which the client renders to DOM).")
(li "It occupies a region of the page — a bounded area with a defined boundary.")
(li "It responds to user interaction by mutating its own DOM.")
(li "It does not fetch data. It does not route. It does not manage application state outside its boundary."))
(p :class "text-stone-600"
"This is a " (a :href "https://en.wikipedia.org/wiki/Hypermedia#Controls" :class "text-violet-600 hover:underline" "hypermedia control") ". It is a region of a hypermedia document that responds to user input. Like a " (code "<form>") ". Like an " (code "<a>") ". Like an " (code "<input>") ". The difference is that a form's behavior is specified by the browser and the HTTP protocol. An island's behavior is specified in SX."))
(p (~tw :tokens "text-stone-600")
"This is a " (a :href "https://en.wikipedia.org/wiki/Hypermedia#Controls" (~tw :tokens "text-violet-600 hover:underline") "hypermedia control") ". It is a region of a hypermedia document that responds to user input. Like a " (code "<form>") ". Like an " (code "<a>") ". Like an " (code "<input>") ". The difference is that a form's behavior is specified by the browser and the HTTP protocol. An island's behavior is specified in SX."))
(~docs/section :title "II. What makes something hypermedia" :id "hypermedia"
(p :class "text-stone-600"
"Roy " (a :href "https://en.wikipedia.org/wiki/Roy_Fielding" :class "text-violet-600 hover:underline" "Fielding") "'s " (a :href "https://en.wikipedia.org/wiki/Representational_state_transfer" :class "text-violet-600 hover:underline" "REST") " thesis defines hypermedia by a constraint: " (em "hypermedia as the engine of application state") " (HATEOAS). The server sends representations that include controls — links, forms — and the client's state transitions are driven by those controls. The client does not need out-of-band knowledge of what actions are available. The representation " (em "is") " the interface.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Roy " (a :href "https://en.wikipedia.org/wiki/Roy_Fielding" (~tw :tokens "text-violet-600 hover:underline") "Fielding") "'s " (a :href "https://en.wikipedia.org/wiki/Representational_state_transfer" (~tw :tokens "text-violet-600 hover:underline") "REST") " thesis defines hypermedia by a constraint: " (em "hypermedia as the engine of application state") " (HATEOAS). The server sends representations that include controls — links, forms — and the client's state transitions are driven by those controls. The client does not need out-of-band knowledge of what actions are available. The representation " (em "is") " the interface.")
(p (~tw :tokens "text-stone-600")
"A traditional SPA violates this. The client has its own router, its own state machine, its own API client that knows the server's URL structure. The HTML is a shell; the actual interface is constructed from JavaScript and API calls. The representation is not the interface — the representation is a loading spinner while the real interface builds itself.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"An SX page does not violate this. The server sends a complete representation — an s-expression tree — that includes all controls. Some controls are plain HTML: " (code "(a :href \"/about\" :sx-get \"/about\")") ". Some controls are reactive islands: " (code "(defisland counter (let ((count (signal 0))) ...))") ". Both are embedded in the representation. Both are delivered by the server. The client does not decide what controls exist — the server does, by including them in the document.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The island is not separate from the hypermedia. The island " (em "is") " part of the hypermedia. It is a control that the server chose to include, whose behavior the server specified, in the same format as the rest of the page."))
(~docs/section :title "III. The SX specification layer" :id "spec-layer"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A " (code "<form>") "'s behavior is specified in HTML + HTTP: " (code "method=\"POST\"") ", " (code "action=\"/submit\"") ". The browser reads the specification and executes it — serialise the inputs, make the request, handle the response. The form does not contain JavaScript. Its behavior is declared.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"An SX island's behavior is specified in SX:")
(~docs/code :lang "lisp" :code
"(defisland todo-adder\n (let ((text (signal \"\")))\n (form :on-submit (fn (e)\n (prevent-default e)\n (emit-event \"todo:add\" (deref text))\n (reset! text \"\"))\n (input :type \"text\"\n :bind text\n :placeholder \"What needs doing?\")\n (button :type \"submit\" \"Add\"))))")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is a " (em "declaration") ", not a program. It declares: there is a signal holding text. There is a form. When submitted, it emits an event and resets the signal. There is an input bound to the signal. There is a button.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The s-expression " (em "is") " the specification. It is not compiled to JavaScript and then executed as an opaque blob. It is parsed, evaluated, and rendered by a transparent evaluator whose own semantics are specified in the same format (" (code "eval.sx") "). The island's behavior is as inspectable as a form's " (code "action") " attribute — you can read it, quote it, transform it, analyse it. You can even send it over the wire and have a different client render it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A form says " (em "what to do") " in HTML attributes. An island says " (em "what to do") " in s-expressions. Both are declarative. Both are part of the hypermedia document. The difference is expressiveness: forms can collect inputs and POST them. Islands can maintain local state, compute derived values, animate transitions, handle errors, and render dynamic lists — all declared in the same markup language as the page that contains them."))
(~docs/section :title "IV. The four levels" :id "four-levels"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX reactive islands exist at four levels of complexity, from pure hypermedia to full client reactivity. Each level is a superset of the one before:")
(ul :class "list-disc pl-6 space-y-2 text-stone-600"
(li (span :class "font-semibold" "L0 — Static server rendering.") " No client interactivity. The server evaluates the full component tree and sends HTML. Pure hypermedia. " (code "(div :class \"card\" (h2 title))") ".")
(li (span :class "font-semibold" "L1 — Hypermedia attributes.") " Server-rendered content with htmx-style attributes. " (code "(button :sx-get \"/items\" :sx-target \"#list\")") ". Still server-driven. The client swaps HTML fragments. Classic hypermedia with AJAX.")
(li (span :class "font-semibold" "L2 — Reactive islands.") " Self-contained client-side state within a server-rendered page. " (code "(defisland counter ...)") ". The island is a hypermedia control: the server delivers it, the client executes it. Signals, computed values, effects — all inside the island boundary.")
(li (span :class "font-semibold" "L3 — Island communication.") " Islands talk to each other and to the htmx-like \"lake\" via DOM events. " (code "(emit-event \"cart:updated\" count)") " and " (code "(on-event \"cart:updated\" handler)") ". Still no global state. Still no client-side routing. The page is still a server document with embedded controls."))
(p :class "text-stone-600"
(ul (~tw :tokens "list-disc pl-6 space-y-2 text-stone-600")
(li (span (~tw :tokens "font-semibold") "L0 — Static server rendering.") " No client interactivity. The server evaluates the full component tree and sends HTML. Pure hypermedia. " (code "(div :class \"card\" (h2 title))") ".")
(li (span (~tw :tokens "font-semibold") "L1 — Hypermedia attributes.") " Server-rendered content with htmx-style attributes. " (code "(button :sx-get \"/items\" :sx-target \"#list\")") ". Still server-driven. The client swaps HTML fragments. Classic hypermedia with AJAX.")
(li (span (~tw :tokens "font-semibold") "L2 — Reactive islands.") " Self-contained client-side state within a server-rendered page. " (code "(defisland counter ...)") ". The island is a hypermedia control: the server delivers it, the client executes it. Signals, computed values, effects — all inside the island boundary.")
(li (span (~tw :tokens "font-semibold") "L3 — Island communication.") " Islands talk to each other and to the htmx-like \"lake\" via DOM events. " (code "(emit-event \"cart:updated\" count)") " and " (code "(on-event \"cart:updated\" handler)") ". Still no global state. Still no client-side routing. The page is still a server document with embedded controls."))
(p (~tw :tokens "text-stone-600")
"At every level, the architecture is hypermedia. The server produces the document. The document contains controls. The controls are specified in SX. The jump from L1 to L2 is not a jump from hypermedia to SPA — it is a jump from " (em "simple controls") " (links and forms) to " (em "richer controls") " (reactive islands). The paradigm does not change. The expressiveness does."))
(~docs/section :title "V. Why not just React?" :id "why-not-react"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"If an island behaves like a React component — local state, event handlers, conditional rendering — why not use React?")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Because React requires a " (em "build") ". JSX must be compiled. Modules must be bundled. The result is an opaque JavaScript blob that the server cannot inspect, the wire format cannot represent, and the client must execute before anything is visible. The component's specification — its source code — is lost by the time it reaches the browser.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"An SX island arrives at the browser as source. The same s-expression that defined the island on the server is the s-expression that the client parses and evaluates. There is no compilation, no bundling, no build step. The specification " (em "is") " the artifact.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This matters because hypermedia's core property is " (em "self-description") ". A hypermedia representation carries its own controls and its own semantics. An HTML form is self-describing: the browser reads the " (code "action") " and " (code "method") " and knows what to do. A compiled React component is not self-describing: it is a function that was once source code, compiled away into instructions that only the React runtime can interpret.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX islands are self-describing. The source is the artifact. The representation carries its own semantics. This is what makes them hypermedia controls — not because they avoid JavaScript (they don't), but because the behavior specification travels with the document, in the same format as the document."))
(~docs/section :title "VI. The bridge pattern" :id "bridge"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In practice, the hypermedia and the islands coexist through a pattern: the htmx \"lake\" surrounds the reactive \"islands.\" The lake handles navigation, form submission, content loading — classic hypermedia. The islands handle local interaction — counters, toggles, filters, input validation, animations.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Communication between lake and islands uses DOM events. An island can " (code "emit-event") " to tell the page something happened. A server-rendered button can " (code "bridge-event") " to poke an island when clicked. The DOM — the shared medium — is the only coupling.")
(~docs/code :lang "lisp" :code
";; Server-rendered lake button dispatches to island\n(button :sx-get \"/api/refresh\"\n :sx-target \"#results\"\n :on-click (bridge-event \"search:clear\")\n \"Reset\")\n\n;; Island listens for the event\n(defisland search-filter\n (let ((query (signal \"\")))\n (on-event \"search:clear\" (fn () (reset! query \"\")))\n (input :bind query :placeholder \"Filter...\")))")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The lake button does its hypermedia thing — fetches HTML, swaps it in. Simultaneously, it dispatches a DOM event. The island hears the event and clears its state. Neither knows about the other's implementation. They communicate through the hypermedia document's event system — the DOM.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a hybrid architecture bolting two incompatible models together. It is a single model — hypermedia — with controls of varying complexity. Some controls are links. Some are forms. Some are reactive islands. All are specified in the document. All are delivered by the server."))
(~docs/section :title "VII. The specification is the specification" :id "specification"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The deepest claim is not architectural but philosophical. A React Island — the kind with signals and effects and computed values — is a " (em "behavior specification") ". It specifies: when this signal changes, recompute this derived value, re-render this DOM subtree. When this event fires, update this state. When this input changes, validate against this pattern.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In React, this specification is written in JavaScript and destroyed by compilation. The specification exists only in the developer's source file. The user receives a bundle.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In SX, this specification is written in s-expressions, transmitted as s-expressions, parsed as s-expressions, and evaluated as s-expressions. The specification exists at every stage of the pipeline. It is never destroyed. It is never transformed into something else. It arrives at the browser intact, readable, inspectable.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"And the evaluator that interprets this specification? It is itself specified in s-expressions (" (code "eval.sx") "). And the renderer? Specified in s-expressions (" (code "render.sx") "). And the parser? Specified in s-expressions (" (code "parser.sx") "). The specification language specifies itself. The island's behavior is specified in a language whose behavior is specified in itself.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A React Island is a hypermedia control. Its behavior is specified in SX. And SX is specified in SX. There is no layer beneath. The specification goes all the way down."))))

110
sx/sx/essays/reflexive-web.sx
View File

@@ -1,102 +1,102 @@
(defcomp ~essays/reflexive-web/essay-reflexive-web ()
(~docs/page :title "The Reflexive Web"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"What happens when the web can read, modify, and reason about itself — and AI is a native participant.")
(~docs/section :title "The missing property" :id "missing-property"
(p :class "text-stone-600"
"Every web technology stack shares one structural limitation: the system cannot inspect itself. A " (a :href "https://en.wikipedia.org/wiki/React_(software)" :class "text-violet-600 hover:underline" "React") " component tree is opaque at runtime. An " (a :href "https://en.wikipedia.org/wiki/HTML" :class "text-violet-600 hover:underline" "HTML") " page cannot read its own structure and generate a new page from it. A " (a :href "https://en.wikipedia.org/wiki/JavaScript" :class "text-violet-600 hover:underline" "JavaScript") " bundle is compiled, minified, and sealed — the running code bears no resemblance to the source that produced it.")
(p :class "text-stone-600"
"The property these systems lack has a name: " (a :href "https://en.wikipedia.org/wiki/Reflection_(computer_programming)" :class "text-violet-600 hover:underline" "reflexivity") ". A reflexive system can represent itself, reason about its own structure, and modify itself based on that reasoning. " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" :class "text-violet-600 hover:underline" "Lisp") " has had this property " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)#History" :class "text-violet-600 hover:underline" "since 1958") ". The web has never had it.")
(p :class "text-stone-600"
"SX is a complete Lisp. It has " (a :href "https://en.wikipedia.org/wiki/Homoiconicity" :class "text-violet-600 hover:underline" "homoiconicity") " — code is data, data is code. It has a " (a :href "/sx/(language.(spec.core))" :class "text-violet-600 hover:underline" "self-hosting specification") " — SX defined in SX. It has " (code "eval") " and " (code "quote") " and " (a :href "https://en.wikipedia.org/wiki/Macro_(computer_science)#Syntactic_macros" :class "text-violet-600 hover:underline" "macros") ". And it runs on the wire — the format that travels between server and client IS the language. This combination has consequences."))
(p (~tw :tokens "text-stone-600")
"Every web technology stack shares one structural limitation: the system cannot inspect itself. A " (a :href "https://en.wikipedia.org/wiki/React_(software)" (~tw :tokens "text-violet-600 hover:underline") "React") " component tree is opaque at runtime. An " (a :href "https://en.wikipedia.org/wiki/HTML" (~tw :tokens "text-violet-600 hover:underline") "HTML") " page cannot read its own structure and generate a new page from it. A " (a :href "https://en.wikipedia.org/wiki/JavaScript" (~tw :tokens "text-violet-600 hover:underline") "JavaScript") " bundle is compiled, minified, and sealed — the running code bears no resemblance to the source that produced it.")
(p (~tw :tokens "text-stone-600")
"The property these systems lack has a name: " (a :href "https://en.wikipedia.org/wiki/Reflection_(computer_programming)" (~tw :tokens "text-violet-600 hover:underline") "reflexivity") ". A reflexive system can represent itself, reason about its own structure, and modify itself based on that reasoning. " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" (~tw :tokens "text-violet-600 hover:underline") "Lisp") " has had this property " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)#History" (~tw :tokens "text-violet-600 hover:underline") "since 1958") ". The web has never had it.")
(p (~tw :tokens "text-stone-600")
"SX is a complete Lisp. It has " (a :href "https://en.wikipedia.org/wiki/Homoiconicity" (~tw :tokens "text-violet-600 hover:underline") "homoiconicity") " — code is data, data is code. It has a " (a :href "/sx/(language.(spec.core))" (~tw :tokens "text-violet-600 hover:underline") "self-hosting specification") " — SX defined in SX. It has " (code "eval") " and " (code "quote") " and " (a :href "https://en.wikipedia.org/wiki/Macro_(computer_science)#Syntactic_macros" (~tw :tokens "text-violet-600 hover:underline") "macros") ". And it runs on the wire — the format that travels between server and client IS the language. This combination has consequences."))
(~docs/section :title "What homoiconicity changes" :id "homoiconicity"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(code "(defcomp ~essays/reflexive-web/card (&key title body) (div :class \"p-4\" (h2 title) (p body)))") " — this is simultaneously a program that renders a card AND a list that can be inspected, transformed, and composed by other programs. The " (code "defcomp") " is not compiled away. It is not transpiled into something else. It persists as data at every stage: definition, transmission, evaluation, and rendering.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This means:")
(ul :class "space-y-2 text-stone-600 mt-2"
(ul (~tw :tokens "space-y-2 text-stone-600 mt-2")
(li (strong "The component registry is data.") " You can " (code "(map ...)") " over every component in the system, extract their parameter signatures, find all components that render a " (code "(table ...)") ", or generate documentation automatically — because the source IS the runtime representation.")
(li (strong "Programs can write programs.") " A " (a :href "https://en.wikipedia.org/wiki/Macro_(computer_science)#Syntactic_macros" :class "text-violet-600 hover:underline" "macro") " takes a list and returns a list. The returned list is code. The macro runs at expansion time and produces new components, new page definitions, new routing rules — indistinguishable from hand-written ones.")
(li (strong "Programs can write programs.") " A " (a :href "https://en.wikipedia.org/wiki/Macro_(computer_science)#Syntactic_macros" (~tw :tokens "text-violet-600 hover:underline") "macro") " takes a list and returns a list. The returned list is code. The macro runs at expansion time and produces new components, new page definitions, new routing rules — indistinguishable from hand-written ones.")
(li (strong "The wire format is inspectable.") " What the server sends to the client is not a blob of serialized state. It is s-expressions that any system — browser, AI, another server — can parse, reason about, and act on.")))
(~docs/section :title "AI as a native speaker" :id "ai-native"
(p :class "text-stone-600"
"Current AI integration with the web is mediated through layers of indirection. An " (a :href "https://en.wikipedia.org/wiki/Large_language_model" :class "text-violet-600 hover:underline" "LLM") " generates " (a :href "https://en.wikipedia.org/wiki/React_(software)" :class "text-violet-600 hover:underline" "React") " components as strings that must be compiled, bundled, and deployed. It interacts with APIs through " (a :href "https://en.wikipedia.org/wiki/JSON" :class "text-violet-600 hover:underline" "JSON") " endpoints that require separate documentation. It reads HTML by scraping, because the markup was never meant to be machine-readable in a computational sense.")
(p :class "text-stone-600"
"In an SX web, the AI reads the same s-expressions the browser reads. The component definitions " (em "are") " the documentation — a " (code "defcomp") " declares its parameters, its structure, and its semantics in one expression. There is no " (a :href "https://en.wikipedia.org/wiki/OpenAPI_Specification" :class "text-violet-600 hover:underline" "Swagger spec") " describing an API. The API " (em "is") " the language, and the language is self-describing.")
(p :class "text-stone-600"
"An AI that understands SX understands the " (a :href "/sx/(language.(spec.core))" :class "text-violet-600 hover:underline" "spec") ". And the spec is written in SX. So the AI understands the definition of the language it is using, in the language it is using. This " (a :href "https://en.wikipedia.org/wiki/Reflexivity_(social_theory)" :class "text-violet-600 hover:underline" "reflexive") " property means the AI does not need a separate mental model for \"the web\" and \"the language\" — they are the same thing."))
(p (~tw :tokens "text-stone-600")
"Current AI integration with the web is mediated through layers of indirection. An " (a :href "https://en.wikipedia.org/wiki/Large_language_model" (~tw :tokens "text-violet-600 hover:underline") "LLM") " generates " (a :href "https://en.wikipedia.org/wiki/React_(software)" (~tw :tokens "text-violet-600 hover:underline") "React") " components as strings that must be compiled, bundled, and deployed. It interacts with APIs through " (a :href "https://en.wikipedia.org/wiki/JSON" (~tw :tokens "text-violet-600 hover:underline") "JSON") " endpoints that require separate documentation. It reads HTML by scraping, because the markup was never meant to be machine-readable in a computational sense.")
(p (~tw :tokens "text-stone-600")
"In an SX web, the AI reads the same s-expressions the browser reads. The component definitions " (em "are") " the documentation — a " (code "defcomp") " declares its parameters, its structure, and its semantics in one expression. There is no " (a :href "https://en.wikipedia.org/wiki/OpenAPI_Specification" (~tw :tokens "text-violet-600 hover:underline") "Swagger spec") " describing an API. The API " (em "is") " the language, and the language is self-describing.")
(p (~tw :tokens "text-stone-600")
"An AI that understands SX understands the " (a :href "/sx/(language.(spec.core))" (~tw :tokens "text-violet-600 hover:underline") "spec") ". And the spec is written in SX. So the AI understands the definition of the language it is using, in the language it is using. This " (a :href "https://en.wikipedia.org/wiki/Reflexivity_(social_theory)" (~tw :tokens "text-violet-600 hover:underline") "reflexive") " property means the AI does not need a separate mental model for \"the web\" and \"the language\" — they are the same thing."))
(~docs/section :title "Live system modification" :id "live-modification"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Because code is data and the wire format is the language, modifying a running system is not deployment — it is evaluation. An AI reads " (code "(defcomp ~essays/reflexive-web/checkout-form ...)") ", understands what it does (because the semantics are specified in SX), modifies the expression, and sends it back. The system evaluates the new definition. No build step. No deploy pipeline. No container restart.")
(p :class "text-stone-600"
"This is not theoretical — it is how " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" :class "text-violet-600 hover:underline" "Lisp") " development has always worked. You modify a function in the running image. The change takes effect immediately. What is new is putting this on the wire, across a network, with the AI as a participant rather than a tool.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not theoretical — it is how " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" (~tw :tokens "text-violet-600 hover:underline") "Lisp") " development has always worked. You modify a function in the running image. The change takes effect immediately. What is new is putting this on the wire, across a network, with the AI as a participant rather than a tool.")
(p (~tw :tokens "text-stone-600")
"The implications for development itself are significant. An AI does not need to " (em "generate code") " that a human then reviews, commits, builds, and deploys. It can propose a modified expression, the human evaluates it in a sandbox, and if it works, the expression becomes the new definition. The feedback loop shrinks from hours to seconds.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"More radically: the distinction between \"development\" and \"operation\" dissolves. If the running system is a set of s-expressions, and those expressions can be inspected and modified at runtime, then there is no separate development environment. There is just the system, and agents — human or artificial — that interact with it."))
(~docs/section :title "Federated intelligence" :id "federated-intelligence"
(p :class "text-stone-600"
(a :href "https://en.wikipedia.org/wiki/ActivityPub" :class "text-violet-600 hover:underline" "ActivityPub") " carries activities between nodes. If those activities contain s-expressions, then what travels between servers is not just data — it is " (em "behaviour") ". Node A sends a component definition to Node B. Node B evaluates it. The result is rendered. The sender's intent is executable on the receiver's hardware.")
(p :class "text-stone-600"
"This is fundamentally different from sending " (a :href "https://en.wikipedia.org/wiki/JSON" :class "text-violet-600 hover:underline" "JSON") " payloads. JSON says \"here is some data, figure out what to do with it.\" An s-expression says \"here is what to do, and here is the data to do it with.\" The component definition and the data it operates on travel together.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(a :href "https://en.wikipedia.org/wiki/ActivityPub" (~tw :tokens "text-violet-600 hover:underline") "ActivityPub") " carries activities between nodes. If those activities contain s-expressions, then what travels between servers is not just data — it is " (em "behaviour") ". Node A sends a component definition to Node B. Node B evaluates it. The result is rendered. The sender's intent is executable on the receiver's hardware.")
(p (~tw :tokens "text-stone-600")
"This is fundamentally different from sending " (a :href "https://en.wikipedia.org/wiki/JSON" (~tw :tokens "text-violet-600 hover:underline") "JSON") " payloads. JSON says \"here is some data, figure out what to do with it.\" An s-expression says \"here is what to do, and here is the data to do it with.\" The component definition and the data it operates on travel together.")
(p (~tw :tokens "text-stone-600")
"For AI agents in a federated network, this means an agent on one node can send " (em "capabilities") " to another node, not just requests. A component that renders a specific visualization. A macro that transforms data into a particular format. A function that implements a protocol. The network becomes a shared computational substrate where intelligence is distributed as executable expressions."))
(~docs/section :title "Programs writing programs writing programs" :id "meta-programs"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A macro is a function that takes code and returns code. An AI generating macros is writing programs that write programs. With " (code "eval") ", those generated programs can generate more programs at runtime. This is not a metaphor — it is the literal mechanism.")
(p :class "text-stone-600"
"The " (a :href "/sx/(etc.(philosophy.godel-escher-bach))" :class "text-violet-600 hover:underline" "Gödel numbering") " parallel is not incidental. " (a :href "https://en.wikipedia.org/wiki/Kurt_G%C3%B6del" :class "text-violet-600 hover:underline" "Gödel") " showed that any sufficiently powerful formal system can encode statements about itself. A complete Lisp on the wire is a sufficiently powerful formal system. The web can make statements about itself — components that inspect other components, macros that rewrite the page structure, expressions that generate new expressions based on the current state of the system.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The " (a :href "/sx/(etc.(philosophy.godel-escher-bach))" (~tw :tokens "text-violet-600 hover:underline") "Gödel numbering") " parallel is not incidental. " (a :href "https://en.wikipedia.org/wiki/Kurt_G%C3%B6del" (~tw :tokens "text-violet-600 hover:underline") "Gödel") " showed that any sufficiently powerful formal system can encode statements about itself. A complete Lisp on the wire is a sufficiently powerful formal system. The web can make statements about itself — components that inspect other components, macros that rewrite the page structure, expressions that generate new expressions based on the current state of the system.")
(p (~tw :tokens "text-stone-600")
"Consider what this enables for AI:")
(ul :class "space-y-2 text-stone-600 mt-2"
(ul (~tw :tokens "space-y-2 text-stone-600 mt-2")
(li (strong "Self-improving interfaces.") " An AI observes how users interact with a component (click patterns, error rates, abandonment). It reads the component definition — because it is data. It modifies the definition — because data is code. It evaluates the result. The interface adapts without human intervention.")
(li (strong "Generative composition.") " Given a data schema and a design intent, an AI generates not just a component but the " (em "macros") " that generate families of components. The macro is a template for templates. The output scales combinatorially.")
(li (strong "Cross-system reasoning.") " An AI reads component definitions from multiple federated nodes, identifies common patterns, and synthesizes abstractions that work across all of them. The shared language makes cross-system analysis trivial — it is all s-expressions.")))
(~docs/section :title "The sandbox is everything" :id "sandbox"
(p :class "text-stone-600"
"The same " (a :href "https://en.wikipedia.org/wiki/Homoiconicity" :class "text-violet-600 hover:underline" "homoiconicity") " that makes this powerful makes it dangerous. Code-as-data means an AI can inject " (em "behaviour") ", not just content. A malicious expression evaluated in the wrong context could exfiltrate data, modify other components, or disrupt the system.")
(p :class "text-stone-600"
"This is why the " (a :href "/sx/(language.(spec.primitives))" :class "text-violet-600 hover:underline" "primitive set") " is the critical security boundary. The spec defines exactly which operations are available. A sandboxed evaluator that only exposes pure primitives (arithmetic, string operations, list manipulation) cannot perform I/O. Cannot access the network. Cannot modify the DOM outside its designated target. The language is " (a :href "https://en.wikipedia.org/wiki/Turing_completeness" :class "text-violet-600 hover:underline" "Turing-complete") " within the sandbox and powerless outside it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The same " (a :href "https://en.wikipedia.org/wiki/Homoiconicity" (~tw :tokens "text-violet-600 hover:underline") "homoiconicity") " that makes this powerful makes it dangerous. Code-as-data means an AI can inject " (em "behaviour") ", not just content. A malicious expression evaluated in the wrong context could exfiltrate data, modify other components, or disrupt the system.")
(p (~tw :tokens "text-stone-600")
"This is why the " (a :href "/sx/(language.(spec.primitives))" (~tw :tokens "text-violet-600 hover:underline") "primitive set") " is the critical security boundary. The spec defines exactly which operations are available. A sandboxed evaluator that only exposes pure primitives (arithmetic, string operations, list manipulation) cannot perform I/O. Cannot access the network. Cannot modify the DOM outside its designated target. The language is " (a :href "https://en.wikipedia.org/wiki/Turing_completeness" (~tw :tokens "text-violet-600 hover:underline") "Turing-complete") " within the sandbox and powerless outside it.")
(p (~tw :tokens "text-stone-600")
"Different contexts grant different primitive sets. A component evaluated in a page slot gets rendering primitives. A macro gets code-transformation primitives. A federated expression from an untrusted node gets the minimal safe set. The sandbox is not bolted on — it is inherent in the language's architecture. What you can do depends on which primitives are in scope.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This matters enormously for AI. An AI agent that can modify the running system must be constrained by the same sandbox mechanism that constrains any other expression. The security model does not distinguish between human-authored code and AI-generated code — both are s-expressions, both are evaluated by the same evaluator, both are subject to the same primitive restrictions."))
(~docs/section :title "Not self-aware — reflexive" :id "reflexive"
(p :class "text-stone-600"
"Is this a \"self-aware web\"? Probably not in the " (a :href "https://en.wikipedia.org/wiki/Consciousness" :class "text-violet-600 hover:underline" "consciousness") " sense. But the word we keep reaching for has a precise meaning: " (a :href "https://en.wikipedia.org/wiki/Reflexivity_(social_theory)" :class "text-violet-600 hover:underline" "reflexivity") ". A reflexive system can represent itself, reason about its own structure, and modify itself based on that reasoning.")
(p :class "text-stone-600"
"A " (a :href "https://en.wikipedia.org/wiki/React_(software)" :class "text-violet-600 hover:underline" "React") " app cannot read its own component tree as data and rewrite it. An HTML page cannot inspect its own structure and generate new pages. A JSON API cannot describe its own semantics in a way that is both human-readable and machine-executable.")
(p :class "text-stone-600"
"SX can do all of these things — because there is no distinction between the program and its representation. The source code, the wire format, the runtime state, and the data model are all the same thing: " (a :href "https://en.wikipedia.org/wiki/S-expression" :class "text-violet-600 hover:underline" "s-expressions") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Is this a \"self-aware web\"? Probably not in the " (a :href "https://en.wikipedia.org/wiki/Consciousness" (~tw :tokens "text-violet-600 hover:underline") "consciousness") " sense. But the word we keep reaching for has a precise meaning: " (a :href "https://en.wikipedia.org/wiki/Reflexivity_(social_theory)" (~tw :tokens "text-violet-600 hover:underline") "reflexivity") ". A reflexive system can represent itself, reason about its own structure, and modify itself based on that reasoning.")
(p (~tw :tokens "text-stone-600")
"A " (a :href "https://en.wikipedia.org/wiki/React_(software)" (~tw :tokens "text-violet-600 hover:underline") "React") " app cannot read its own component tree as data and rewrite it. An HTML page cannot inspect its own structure and generate new pages. A JSON API cannot describe its own semantics in a way that is both human-readable and machine-executable.")
(p (~tw :tokens "text-stone-600")
"SX can do all of these things — because there is no distinction between the program and its representation. The source code, the wire format, the runtime state, and the data model are all the same thing: " (a :href "https://en.wikipedia.org/wiki/S-expression" (~tw :tokens "text-violet-600 hover:underline") "s-expressions") ".")
(p (~tw :tokens "text-stone-600")
"What AI adds to this is not awareness but " (em "agency") ". The system has always been reflexive — Lisp has been reflexive for seven decades. What is new is having an agent that can exploit that reflexivity at scale: reading the entire system state as data, reasoning about it, generating modifications, and evaluating the results — all in the native language of the system itself."))
(~docs/section :title "The Lisp that escaped the REPL" :id "escaped-repl"
(p :class "text-stone-600"
(a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" :class "text-violet-600 hover:underline" "Lisp") " has been reflexive since " (a :href "https://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)" :class "text-violet-600 hover:underline" "McCarthy") ". What kept it contained was the boundary of the " (a :href "https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop" :class "text-violet-600 hover:underline" "REPL") " — a single process, a single machine, a single user. The s-expressions lived inside Emacs, inside a Clojure JVM, inside a Scheme interpreter. They did not travel.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" (~tw :tokens "text-violet-600 hover:underline") "Lisp") " has been reflexive since " (a :href "https://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)" (~tw :tokens "text-violet-600 hover:underline") "McCarthy") ". What kept it contained was the boundary of the " (a :href "https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop" (~tw :tokens "text-violet-600 hover:underline") "REPL") " — a single process, a single machine, a single user. The s-expressions lived inside Emacs, inside a Clojure JVM, inside a Scheme interpreter. They did not travel.")
(p (~tw :tokens "text-stone-600")
"SX puts s-expressions on the wire. Between server and client. Between federated nodes. Between human and AI. The reflexive property escapes the process boundary and becomes a property of the " (em "network") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A network of nodes that share a reflexive language is a qualitatively different system from a network of nodes that exchange inert data. The former can reason about itself, modify itself, and evolve. The latter can only shuttle payloads.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Whether this constitutes anything approaching awareness is a philosophical question. What is not philosophical is the engineering consequence: a web built on s-expressions is a web that AI can participate in as a " (em "native citizen") ", not as a tool bolted onto the side. The language is the interface. The interface is the language. And the language can describe itself."))
(~docs/section :title "What this opens up" :id "possibilities"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Concretely:")
(ul :class "space-y-3 text-stone-600 mt-2"
(li (strong "AI-native development environments.") " The IDE is a web page. The web page is s-expressions. The AI reads and writes s-expressions. There is no translation layer between what the AI thinks and what the system executes. " (a :href "https://en.wikipedia.org/wiki/Pair_programming" :class "text-violet-600 hover:underline" "Pair programming") " with an AI becomes pair evaluation.")
(ul (~tw :tokens "space-y-3 text-stone-600 mt-2")
(li (strong "AI-native development environments.") " The IDE is a web page. The web page is s-expressions. The AI reads and writes s-expressions. There is no translation layer between what the AI thinks and what the system executes. " (a :href "https://en.wikipedia.org/wiki/Pair_programming" (~tw :tokens "text-violet-600 hover:underline") "Pair programming") " with an AI becomes pair evaluation.")
(li (strong "Adaptive interfaces.") " Components that observe their own usage patterns and propose modifications. The AI reads the component (data), the interaction logs (data), and generates a modified component (data). Human approves or rejects. The loop is native to the system.")
(li (strong "Semantic federation.") " Nodes exchange not just content but " (em "understanding") ". A component definition carries its own semantics. An AI on a receiving node can reason about what a foreign component does without documentation, because the definition is self-describing.")
(li (strong "Emergent protocols.") " Two AI agents on different nodes, speaking SX, can negotiate new interaction patterns by exchanging macros. The protocol is not predefined — it emerges from the conversation between agents, expressed in the shared language.")
(li (strong "Composable trust.") " The sandbox mechanism means you can give an AI agent " (em "exactly") " the capabilities it needs — no more. Trust is expressed as a set of available primitives, not as an all-or-nothing API key."))
(p :class "text-stone-600"
"None of these require breakthroughs in AI. They require a web that speaks a reflexive language. " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" :class "text-violet-600 hover:underline" "Lisp") " solved the language problem in 1958. SX solves the distribution problem. AI provides the agency. The three together produce something that none of them achieves alone: a web that can reason about itself."))))
(p (~tw :tokens "text-stone-600")
"None of these require breakthroughs in AI. They require a web that speaks a reflexive language. " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" (~tw :tokens "text-violet-600 hover:underline") "Lisp") " solved the language problem in 1958. SX solves the distribution problem. AI provides the agency. The three together produce something that none of them achieves alone: a web that can reason about itself."))))

118
sx/sx/essays/s-existentialism.sx
View File

@@ -1,103 +1,103 @@
(defcomp ~essays/s-existentialism/essay-s-existentialism ()
(~docs/page :title "S-Existentialism"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"Existence precedes essence — and s-expressions exist before anything gives them meaning.")
(~docs/section :title "I. Existence precedes essence" :id "existence-precedes-essence"
(p :class "text-stone-600"
"In 1946, Jean-Paul " (a :href "https://en.wikipedia.org/wiki/Jean-Paul_Sartre" :class "text-violet-600 hover:underline" "Sartre") " gave a lecture called \"" (a :href "https://en.wikipedia.org/wiki/Existentialism_Is_a_Humanism" :class "text-violet-600 hover:underline" "Existentialism Is a Humanism") ".\" Its central claim: " (em "existence precedes essence") ". A paper knife is designed before it exists — someone conceives its purpose, then builds it. A human being is the opposite — we exist first, then define ourselves through our choices. There is no blueprint. There is no human nature that precedes the individual human.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In 1946, Jean-Paul " (a :href "https://en.wikipedia.org/wiki/Jean-Paul_Sartre" (~tw :tokens "text-violet-600 hover:underline") "Sartre") " gave a lecture called \"" (a :href "https://en.wikipedia.org/wiki/Existentialism_Is_a_Humanism" (~tw :tokens "text-violet-600 hover:underline") "Existentialism Is a Humanism") ".\" Its central claim: " (em "existence precedes essence") ". A paper knife is designed before it exists — someone conceives its purpose, then builds it. A human being is the opposite — we exist first, then define ourselves through our choices. There is no blueprint. There is no human nature that precedes the individual human.")
(p (~tw :tokens "text-stone-600")
"A React component is a paper knife. Its essence precedes its existence. Before a single line of JSX runs, React has decided what a component is: a function that returns elements, governed by the rules of hooks, reconciled by a virtual DOM, managed by a scheduler. The framework defines the essence. The developer fills in the blanks. You exist within React's concept of you.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"An s-expression exists before any essence is assigned to it. " (code "(div :class \"card\" (h2 title))") " is a list. That is all it is. It has no inherent meaning. It is not a component, not a template, not a function call — not yet. It is raw existence: a nested structure of symbols, keywords, and other lists, waiting.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The evaluator gives it essence. " (code "render-to-html") " makes it HTML. " (code "render-to-dom") " makes it DOM nodes. " (code "aser") " makes it wire format. " (code "quote") " keeps it as data. The same expression, the same existence, can receive different essences depending on what acts on it. The expression does not know what it is. It becomes what it is used for.")
(~docs/code :lang "lisp" :code
";; The same existence, different essences:\n(define expr '(div :class \"card\" (h2 \"Hello\")))\n\n(render-to-html expr) ;; → <div class=\"card\"><h2>Hello</h2></div>\n(render-to-dom expr) ;; → [DOM Element]\n(aser expr) ;; → (div :class \"card\" (h2 \"Hello\"))\n(length expr) ;; → 4 (it's just a list)\n\n;; The expression existed before any of these.\n;; It has no essence until you give it one."))
(~docs/section :title "II. Condemned to be free" :id "condemned"
(p :class "text-stone-600"
"\"Man is condemned to be free,\" Sartre wrote in " (a :href "https://en.wikipedia.org/wiki/Being_and_Nothingness" :class "text-violet-600 hover:underline" "Being and Nothingness") ". Not free as a gift. Free as a sentence. You did not choose to be free. You cannot escape it. Every attempt to deny your freedom — by deferring to authority, convention, or nature — is " (a :href "https://en.wikipedia.org/wiki/Bad_faith_(existentialism)" :class "text-violet-600 hover:underline" "bad faith") ". You are responsible for everything you make of yourself, and the weight of that responsibility is the human condition.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"\"Man is condemned to be free,\" Sartre wrote in " (a :href "https://en.wikipedia.org/wiki/Being_and_Nothingness" (~tw :tokens "text-violet-600 hover:underline") "Being and Nothingness") ". Not free as a gift. Free as a sentence. You did not choose to be free. You cannot escape it. Every attempt to deny your freedom — by deferring to authority, convention, or nature — is " (a :href "https://en.wikipedia.org/wiki/Bad_faith_(existentialism)" (~tw :tokens "text-violet-600 hover:underline") "bad faith") ". You are responsible for everything you make of yourself, and the weight of that responsibility is the human condition.")
(p (~tw :tokens "text-stone-600")
"SX condemns you to be free. There is no framework telling you how to structure your application. No router mandating your URL patterns. No state management library imposing its model. No convention-over-configuration file tree that decides where your code goes. You have a parser, an evaluator, and fifty primitives. What you build is your responsibility.")
(p :class "text-stone-600"
"React developers are not free. They are told: components must be pure. State changes must go through hooks. Side effects must live in useEffect. The render cycle must not be interrupted. These are the commandments. Obey them and the framework rewards you with a working application. Disobey them and the framework punishes you with cryptic errors. This is not freedom. This is " (a :href "https://en.wikipedia.org/wiki/Fear_and_Trembling" :class "text-violet-600 hover:underline" "Kierkegaard's") " knight of faith, submitting to the absurd authority of the framework because the alternative — thinking for yourself — is terrifying.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"React developers are not free. They are told: components must be pure. State changes must go through hooks. Side effects must live in useEffect. The render cycle must not be interrupted. These are the commandments. Obey them and the framework rewards you with a working application. Disobey them and the framework punishes you with cryptic errors. This is not freedom. This is " (a :href "https://en.wikipedia.org/wiki/Fear_and_Trembling" (~tw :tokens "text-violet-600 hover:underline") "Kierkegaard's") " knight of faith, submitting to the absurd authority of the framework because the alternative — thinking for yourself — is terrifying.")
(p (~tw :tokens "text-stone-600")
"The SX developer has no commandments. " (code "defcomp") " is a suggestion, not a requirement — you can build components with raw lambdas if you prefer. " (code "defmacro") " gives you the power to reshape the language itself. There are no rules of hooks because there are no hooks. There are no lifecycle methods because there is no lifecycle. There is only evaluation: an expression goes in, a value comes out. What the expression contains, how the value is used — that is up to you.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not comfortable. Freedom never is. Sartre did not say freedom was pleasant. He said it was inescapable."))
(~docs/section :title "III. Bad faith" :id "bad-faith"
(p :class "text-stone-600"
(a :href "https://en.wikipedia.org/wiki/Bad_faith_(existentialism)" :class "text-violet-600 hover:underline" "Bad faith") " is Sartre's term for the lie you tell yourself to escape freedom. The waiter who plays at being a waiter — performing the role so thoroughly that he forgets he chose it. The woman who pretends not to notice a man's intentions — denying her own awareness to avoid making a decision. Bad faith is not deception of others. It is self-deception about one's own freedom.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(a :href "https://en.wikipedia.org/wiki/Bad_faith_(existentialism)" (~tw :tokens "text-violet-600 hover:underline") "Bad faith") " is Sartre's term for the lie you tell yourself to escape freedom. The waiter who plays at being a waiter — performing the role so thoroughly that he forgets he chose it. The woman who pretends not to notice a man's intentions — denying her own awareness to avoid making a decision. Bad faith is not deception of others. It is self-deception about one's own freedom.")
(p (~tw :tokens "text-stone-600")
"\"We have to use React — it's the industry standard.\" Bad faith. You chose React. The industry did not force it on you. There were alternatives. You preferred the comfort of the herd.")
(p :class "text-stone-600"
"\"We need TypeScript — you can't write reliable code without a type system.\" Bad faith. " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" :class "text-violet-600 hover:underline" "Lisp") " has been writing reliable code without static types since 1958. " (a :href "https://en.wikipedia.org/wiki/Erlang_(programming_language)" :class "text-violet-600 hover:underline" "Erlang") " runs telephone networks on dynamic types. You chose TypeScript because you are afraid of your own code, and the type system is a security blanket.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"\"We need TypeScript — you can't write reliable code without a type system.\" Bad faith. " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)" (~tw :tokens "text-violet-600 hover:underline") "Lisp") " has been writing reliable code without static types since 1958. " (a :href "https://en.wikipedia.org/wiki/Erlang_(programming_language)" (~tw :tokens "text-violet-600 hover:underline") "Erlang") " runs telephone networks on dynamic types. You chose TypeScript because you are afraid of your own code, and the type system is a security blanket.")
(p (~tw :tokens "text-stone-600")
"\"We need a build step — modern web development requires it.\" Bad faith. A " (code "<script>") " tag requires no build step. An s-expression evaluator in 3,000 lines of JavaScript requires no build step. You need a build step because you chose tools that require a build step, and now you have forgotten that the choice was yours.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"\"Nobody uses s-expressions for web development.\" Bad faith. " (em "You") " do not use s-expressions for web development. That is a fact about you, not a fact about web development. Transforming your personal preference into a universal law is the quintessential act of bad faith.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX does not prevent bad faith — nothing can. But it makes bad faith harder. When the entire language is fifty primitives and a page of special forms, you cannot pretend that the complexity is necessary. When there is no build step, you cannot pretend that the build step is inevitable. When the same source runs on server and client, you cannot pretend that the server-client divide is ontological. SX strips away the excuses. What remains is your choices."))
(~docs/section :title "IV. Nausea" :id "nausea"
(p :class "text-stone-600"
"In " (a :href "https://en.wikipedia.org/wiki/Nausea_(novel)" :class "text-violet-600 hover:underline" "Nausea") " (1938), Sartre's Roquentin sits in a park and stares at the root of a chestnut tree. He sees it — really sees it — stripped of all the concepts and categories that normally make it comprehensible. It is not a \"root.\" It is not \"brown.\" It is not \"gnarled.\" It simply " (em "is") " — a brute, opaque, superfluous existence. The nausea is the vertigo of confronting existence without essence.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In " (a :href "https://en.wikipedia.org/wiki/Nausea_(novel)" (~tw :tokens "text-violet-600 hover:underline") "Nausea") " (1938), Sartre's Roquentin sits in a park and stares at the root of a chestnut tree. He sees it — really sees it — stripped of all the concepts and categories that normally make it comprehensible. It is not a \"root.\" It is not \"brown.\" It is not \"gnarled.\" It simply " (em "is") " — a brute, opaque, superfluous existence. The nausea is the vertigo of confronting existence without essence.")
(p (~tw :tokens "text-stone-600")
"Open " (code "node_modules") ". Stare at it. 47,000 directories. 1.2 gigabytes. For a to-do app. Each directory contains a " (code "package.json") ", a " (code "README.md") ", a " (code "LICENSE") ", and some JavaScript that wraps some other JavaScript that wraps some other JavaScript. There is no reason for any of it. It is not necessary. It is not justified. It simply accumulated — dependency after dependency, version after version, a brute, opaque, superfluous existence. This is " (code "node_modules") " nausea.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX has its own nausea. Stare at a page of s-expressions long enough and the same vertigo hits. Parentheses. Symbols. Lists inside lists inside lists. There is nothing behind them — no hidden runtime, no compiled intermediate form, no framework magic. Just parentheses. The s-expression is Roquentin's chestnut root: it simply " (em "is") ". You cannot unsee it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But SX's nausea is honest. The chestnut root is really there — it exists, bare and exposed. The " (code "node_modules") " nausea is different: it is nausea at something that should not exist, that has no reason to exist, that exists only because of accumulated accidents of dependency resolution. SX's nausea is existential — the dizziness of confronting raw structure. The JavaScript ecosystem's nausea is absurd — the dizziness of confronting unnecessary complexity that no one chose but everyone maintains."))
(~docs/section :title "V. The absurd" :id "absurd"
(p :class "text-stone-600"
(a :href "https://en.wikipedia.org/wiki/Albert_Camus" :class "text-violet-600 hover:underline" "Camus") " defined the " (a :href "https://en.wikipedia.org/wiki/Absurdism" :class "text-violet-600 hover:underline" "absurd") " as the gap between human longing for meaning and the universe's silence. We want the world to make sense. It does not. The absurd is not in us or in the world — it is in the confrontation between the two.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(a :href "https://en.wikipedia.org/wiki/Albert_Camus" (~tw :tokens "text-violet-600 hover:underline") "Camus") " defined the " (a :href "https://en.wikipedia.org/wiki/Absurdism" (~tw :tokens "text-violet-600 hover:underline") "absurd") " as the gap between human longing for meaning and the universe's silence. We want the world to make sense. It does not. The absurd is not in us or in the world — it is in the confrontation between the two.")
(p (~tw :tokens "text-stone-600")
"Web development is absurd. We want simple, composable, maintainable software. The industry gives us webpack configurations, framework migrations, and breaking changes in minor versions. We want to write code and run it. The industry gives us transpilers, bundlers, minifiers, tree-shakers, and hot-module-replacers. The gap between what we want and what we get is the absurd.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Writing a Lisp for the web is also absurd — but in a different register. Nobody asked for it. Nobody wants it. The parentheses are off-putting. The ecosystem is nonexistent. The job market is zero. There is no rational justification for building SX when React exists, when Vue exists, when Svelte exists, when the entire weight of the industry points in the other direction.")
(p :class "text-stone-600"
"Camus said there are three responses to the absurd. " (a :href "https://en.wikipedia.org/wiki/The_Myth_of_Sisyphus" :class "text-violet-600 hover:underline" "Suicide") " — giving up. " (a :href "https://en.wikipedia.org/wiki/Leap_of_faith" :class "text-violet-600 hover:underline" "Philosophical suicide") " — leaping into faith, pretending the absurd has been resolved. Or " (em "revolt") " — continuing without resolution, fully aware that the project is meaningless, and doing it anyway.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Camus said there are three responses to the absurd. " (a :href "https://en.wikipedia.org/wiki/The_Myth_of_Sisyphus" (~tw :tokens "text-violet-600 hover:underline") "Suicide") " — giving up. " (a :href "https://en.wikipedia.org/wiki/Leap_of_faith" (~tw :tokens "text-violet-600 hover:underline") "Philosophical suicide") " — leaping into faith, pretending the absurd has been resolved. Or " (em "revolt") " — continuing without resolution, fully aware that the project is meaningless, and doing it anyway.")
(p (~tw :tokens "text-stone-600")
"Most developers commit philosophical suicide. They adopt a framework, declare it The Way, and stop questioning. React is the truth. TypeScript is salvation. The build step is destiny. The absurd disappears — not because it has been resolved, but because they have stopped looking at it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX is revolt. It does not resolve the absurd. It does not pretend that s-expressions are the answer, that parentheses will save the web, that the industry will come around. It simply continues — writing components, specifying evaluators, bootstrapping to new targets — with full awareness that the project may never matter to anyone. This is the only honest response to the absurd."))
(~docs/section :title "VI. Sisyphus" :id "sisyphus"
(p :class "text-stone-600"
"\"" (a :href "https://en.wikipedia.org/wiki/The_Myth_of_Sisyphus" :class "text-violet-600 hover:underline" "One must imagine Sisyphus happy") ".\"")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"\"" (a :href "https://en.wikipedia.org/wiki/The_Myth_of_Sisyphus" (~tw :tokens "text-violet-600 hover:underline") "One must imagine Sisyphus happy") ".\"")
(p (~tw :tokens "text-stone-600")
"Sisyphus pushes a boulder up a hill. It rolls back down. He pushes it up again. Forever. Camus argues that Sisyphus is the absurd hero: he knows the task is pointless, he does it anyway, and in the doing — in the conscious confrontation with futility — he finds something that transcends the futility.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The framework developer is Sisyphus too, but an unconscious one. React 16 to 17 to 18. Class components to hooks to server components. Each migration is the boulder. Each major version is the hill. The developer pushes the codebase up, and the next release rolls it back down. But the framework developer does not " (em "know") " they are Sisyphus. They believe each migration is progress. They believe the boulder will stay at the top this time. This is philosophical suicide — the leap of faith that the next version will be the last.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The SX developer is conscious Sisyphus. The boulder is obvious: writing a Lisp for the web is absurd. The hill is obvious: nobody will use it. But consciousness changes everything. Camus's Sisyphus is happy not because the task has meaning but because " (em "he") " has chosen it. The choice — the revolt — is the meaning. Not the outcome.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"One must imagine the s-expressionist happy."))
(~docs/section :title "VII. Thrownness" :id "thrownness"
(p :class "text-stone-600"
(a :href "https://en.wikipedia.org/wiki/Martin_Heidegger" :class "text-violet-600 hover:underline" "Heidegger's") " " (a :href "https://en.wikipedia.org/wiki/Thrownness" :class "text-violet-600 hover:underline" "Geworfenheit") " — thrownness — describes the condition of finding yourself already in a world you did not choose. You did not pick your language, your culture, your body, your historical moment. You were " (em "thrown") " into them. Authenticity is not escaping thrownness but owning it — relating to your situation as yours, rather than pretending it was inevitable or that you could have been elsewhere.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(a :href "https://en.wikipedia.org/wiki/Martin_Heidegger" (~tw :tokens "text-violet-600 hover:underline") "Heidegger's") " " (a :href "https://en.wikipedia.org/wiki/Thrownness" (~tw :tokens "text-violet-600 hover:underline") "Geworfenheit") " — thrownness — describes the condition of finding yourself already in a world you did not choose. You did not pick your language, your culture, your body, your historical moment. You were " (em "thrown") " into them. Authenticity is not escaping thrownness but owning it — relating to your situation as yours, rather than pretending it was inevitable or that you could have been elsewhere.")
(p (~tw :tokens "text-stone-600")
"SX is thrown into the web. It did not choose HTTP, the DOM, CSS, JavaScript engines, or browser security models. These are the givens — the facticity of web development. Every web technology is thrown into this same world. The question is how you relate to it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"React relates to the DOM by replacing it — the virtual DOM is a denial of thrownness, an attempt to build a world that is not the one you were thrown into, then reconcile the two. Angular relates to JavaScript by replacing it — TypeScript, decorators, dependency injection, a whole parallel universe layered over the given one. These are inauthentic responses to thrownness: instead of owning the situation, they construct an alternative and pretend it is the real one.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX owns its thrownness. It runs in the browser's JavaScript engine — not because JavaScript is good, but because the browser is the world it was thrown into. It produces DOM nodes — not because the DOM is elegant, but because the DOM is what exists. It sends HTTP responses — not because HTTP is ideal, but because HTTP is the wire. SX does not build a virtual DOM to escape the real DOM. It does not invent a type system to escape JavaScript's types. It evaluates s-expressions in the given environment and produces what the environment requires.")
(p :class "text-stone-600"
"The s-expression is itself a kind of primordial thrownness. It did not choose to be the minimal recursive data structure. It simply is. Open paren, atoms, close paren. It was not designed by committee, not optimised by industry, not evolved through market pressure. It was " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)#History" :class "text-violet-600 hover:underline" "discovered in 1958") " as a notational convenience and turned out to be the bedrock. SX was thrown into s-expressions the way humans are thrown into bodies — not by choice, but by the nature of what it is."))
(p (~tw :tokens "text-stone-600")
"The s-expression is itself a kind of primordial thrownness. It did not choose to be the minimal recursive data structure. It simply is. Open paren, atoms, close paren. It was not designed by committee, not optimised by industry, not evolved through market pressure. It was " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)#History" (~tw :tokens "text-violet-600 hover:underline") "discovered in 1958") " as a notational convenience and turned out to be the bedrock. SX was thrown into s-expressions the way humans are thrown into bodies — not by choice, but by the nature of what it is."))
(~docs/section :title "VIII. The Other" :id "the-other"
(p :class "text-stone-600"
"Sartre's account of " (a :href "https://en.wikipedia.org/wiki/Being_and_Nothingness#The_Other_and_the_Look" :class "text-violet-600 hover:underline" "the Other") " in Being and Nothingness: I am alone in a park. I am the centre of my world. Then I see another person. Suddenly I am seen. I am no longer just a subject — I am an object in someone else's world. The Other's gaze transforms me. \"Hell is other people,\" Sartre wrote in " (a :href "https://en.wikipedia.org/wiki/No_Exit" :class "text-violet-600 hover:underline" "No Exit") " — not because others are cruel, but because they see you, and their seeing limits your freedom to define yourself.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Sartre's account of " (a :href "https://en.wikipedia.org/wiki/Being_and_Nothingness#The_Other_and_the_Look" (~tw :tokens "text-violet-600 hover:underline") "the Other") " in Being and Nothingness: I am alone in a park. I am the centre of my world. Then I see another person. Suddenly I am seen. I am no longer just a subject — I am an object in someone else's world. The Other's gaze transforms me. \"Hell is other people,\" Sartre wrote in " (a :href "https://en.wikipedia.org/wiki/No_Exit" (~tw :tokens "text-violet-600 hover:underline") "No Exit") " — not because others are cruel, but because they see you, and their seeing limits your freedom to define yourself.")
(p (~tw :tokens "text-stone-600")
"Every framework exists under the gaze of the Other. React watches what Vue does. Vue watches what Svelte does. Svelte watches what Solid does. Each framework defines itself partly through the Other — \"we are not React,\" \"we are faster than Vue,\" \"we are simpler than Angular.\" The benchmark is the Other. The identity is relational. No framework is free to be purely itself, because the Others are always watching.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX has no Other. There is no competing s-expression web framework to define itself against. There is no benchmark to win, no market to capture, no conference talk to rebut. This is either pathetic (no ecosystem, no community, no relevance) or liberating (no gaze, no comparison, no borrowed identity). Sartre would say it is both.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But there is another sense of the Other that matters more. The Other " (em "evaluator") ". SX's self-hosting spec means that the language encounters itself as Other. " (code "eval.sx") " is written in SX — the language looking at itself, seeing itself from outside. The bootstrap compiler reads this self-description and produces a working evaluator. The language has been seen by its own gaze, and the seeing has made it real. This is Sartre's intersubjectivity turned reflexive: the subject and the Other are the same entity."))
(~docs/section :title "IX. Authenticity" :id "authenticity"
(p :class "text-stone-600"
"For both Heidegger and Sartre, " (a :href "https://en.wikipedia.org/wiki/Authenticity_(philosophy)" :class "text-violet-600 hover:underline" "authenticity") " means facing your situation — your freedom, your thrownness, your mortality — without evasion. The inauthentic person hides in the crowd, adopts the crowd's values, speaks the crowd's language. Heidegger called this " (a :href "https://en.wikipedia.org/wiki/Heideggerian_terminology#Das_Man" :class "text-violet-600 hover:underline" "das Man") " — the \"They.\" \"They say React is best.\" \"They use TypeScript.\" \"They have build steps.\" The They is not a conspiracy. It is the comfortable anonymity of doing what everyone does.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"For both Heidegger and Sartre, " (a :href "https://en.wikipedia.org/wiki/Authenticity_(philosophy)" (~tw :tokens "text-violet-600 hover:underline") "authenticity") " means facing your situation — your freedom, your thrownness, your mortality — without evasion. The inauthentic person hides in the crowd, adopts the crowd's values, speaks the crowd's language. Heidegger called this " (a :href "https://en.wikipedia.org/wiki/Heideggerian_terminology#Das_Man" (~tw :tokens "text-violet-600 hover:underline") "das Man") " — the \"They.\" \"They say React is best.\" \"They use TypeScript.\" \"They have build steps.\" The They is not a conspiracy. It is the comfortable anonymity of doing what everyone does.")
(p (~tw :tokens "text-stone-600")
"Authenticity in web development would mean confronting what you are actually doing: arranging symbols so that a machine produces visual output. That is all web development is. Not \"building products.\" Not \"crafting experiences.\" Not \"shipping value.\" Arranging symbols. The frameworks, the methodologies, the Agile ceremonies — all of it is das Man, the They, the comfortable obfuscation of a simple truth.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX is more authentic than most — not because s-expressions are morally superior, but because they are harder to hide behind. There is no CLI that generates boilerplate. No convention that tells you where files go. No community consensus on the Right Way. You write expressions. You evaluate them. You see what they produce. The gap between what you do and what happens is as small as it can be.")
(p :class "text-stone-600"
"De Beauvoir added something Sartre did not: authenticity requires that you " (a :href "https://en.wikipedia.org/wiki/The_Ethics_of_Ambiguity" :class "text-violet-600 hover:underline" "will the freedom of others") ", not just your own. A language that locks you into one runtime, one vendor, one ecosystem is inauthentic — it denies others the freedom it claims for itself. SX's self-hosting spec is an act of de Beauvoirian ethics: by defining the language in itself, in a format that any reader can parse, any compiler can target, any host can implement, it wills the freedom of every future evaluator. The spec is public. The language is portable. Your freedom to re-implement, to fork, to understand — that freedom is not a side effect. It is the point.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"De Beauvoir added something Sartre did not: authenticity requires that you " (a :href "https://en.wikipedia.org/wiki/The_Ethics_of_Ambiguity" (~tw :tokens "text-violet-600 hover:underline") "will the freedom of others") ", not just your own. A language that locks you into one runtime, one vendor, one ecosystem is inauthentic — it denies others the freedom it claims for itself. SX's self-hosting spec is an act of de Beauvoirian ethics: by defining the language in itself, in a format that any reader can parse, any compiler can target, any host can implement, it wills the freedom of every future evaluator. The spec is public. The language is portable. Your freedom to re-implement, to fork, to understand — that freedom is not a side effect. It is the point.")
(p (~tw :tokens "text-stone-600")
"Existence precedes essence. The s-expression exists — bare, parenthesised, indifferent — before any evaluator gives it meaning. What it becomes is up to you. This is not a limitation. It is the only freedom there is."))))

76
sx/sx/essays/self-defining-medium.sx
View File

@@ -1,88 +1,88 @@
(defcomp ~essays/self-defining-medium/essay-self-defining-medium ()
(~docs/page :title "The True Hypermedium Must Define Itself With Itself"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"On ontological uniformity, the metacircular web, and why the address of a thing and the thing itself should be made of the same stuff.")
(~docs/section :title "The test" :id "the-test"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"There is a simple test for whether a medium is truly a medium or merely a carrier. Can it define itself? Can it describe its own semantics, in its own language, and have that description be executable?")
(p :class "text-stone-600"
(a :href "https://en.wikipedia.org/wiki/HTML" :class "text-violet-600 hover:underline" "HTML") " cannot express " (a :href "https://en.wikipedia.org/wiki/HTTP" :class "text-violet-600 hover:underline" "HTTP") ". HTTP cannot express " (a :href "https://en.wikipedia.org/wiki/Domain_Name_System" :class "text-violet-600 hover:underline" "DNS") ". " (a :href "https://en.wikipedia.org/wiki/CSS" :class "text-violet-600 hover:underline" "CSS") " cannot describe HTML. " (a :href "https://en.wikipedia.org/wiki/JavaScript" :class "text-violet-600 hover:underline" "JavaScript") " cannot describe CSS in any way that CSS itself would recognise. The web is a stack of mutually opaque layers, each defined in some other notation by some other authority. No layer can see the others. No layer can see itself.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(a :href "https://en.wikipedia.org/wiki/HTML" (~tw :tokens "text-violet-600 hover:underline") "HTML") " cannot express " (a :href "https://en.wikipedia.org/wiki/HTTP" (~tw :tokens "text-violet-600 hover:underline") "HTTP") ". HTTP cannot express " (a :href "https://en.wikipedia.org/wiki/Domain_Name_System" (~tw :tokens "text-violet-600 hover:underline") "DNS") ". " (a :href "https://en.wikipedia.org/wiki/CSS" (~tw :tokens "text-violet-600 hover:underline") "CSS") " cannot describe HTML. " (a :href "https://en.wikipedia.org/wiki/JavaScript" (~tw :tokens "text-violet-600 hover:underline") "JavaScript") " cannot describe CSS in any way that CSS itself would recognise. The web is a stack of mutually opaque layers, each defined in some other notation by some other authority. No layer can see the others. No layer can see itself.")
(p (~tw :tokens "text-stone-600")
"This is not a mere inconvenience. It is a structural fact that determines what is and is not possible. A medium that cannot describe itself cannot reason about itself, cannot modify itself, cannot generate itself from itself. It is " (em "inert") " — a carrying wave, not a thinking substance."))
(~docs/section :title "What Lisp solved" :id "what-lisp-solved"
(p :class "text-stone-600"
(a :href "https://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)" :class "text-violet-600 hover:underline" "McCarthy") " solved this for computation in 1960. The " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)#Connection_to_artificial_intelligence" :class "text-violet-600 hover:underline" "metacircular evaluator") " is an evaluator written in the language it evaluates. " (code "eval") " takes a list and returns a value. The definition of " (code "eval") " is itself a list. So " (code "eval") " can evaluate its own definition. The serpent eats its tail.")
(p :class "text-stone-600"
"This is not a party trick. It means the language is " (em "closed under self-description") ". You do not need to step outside Lisp to define Lisp. You do not need a specification document written in English, or a grammar written in " (a :href "https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form" :class "text-violet-600 hover:underline" "BNF") ", or a reference implementation written in " (a :href "https://en.wikipedia.org/wiki/C_(programming_language)" :class "text-violet-600 hover:underline" "C") ". You need only " (a :href "https://en.wikipedia.org/wiki/S-expression" :class "text-violet-600 hover:underline" "s-expressions") " — the same medium the programs are made of.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(a :href "https://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)" (~tw :tokens "text-violet-600 hover:underline") "McCarthy") " solved this for computation in 1960. The " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)#Connection_to_artificial_intelligence" (~tw :tokens "text-violet-600 hover:underline") "metacircular evaluator") " is an evaluator written in the language it evaluates. " (code "eval") " takes a list and returns a value. The definition of " (code "eval") " is itself a list. So " (code "eval") " can evaluate its own definition. The serpent eats its tail.")
(p (~tw :tokens "text-stone-600")
"This is not a party trick. It means the language is " (em "closed under self-description") ". You do not need to step outside Lisp to define Lisp. You do not need a specification document written in English, or a grammar written in " (a :href "https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form" (~tw :tokens "text-violet-600 hover:underline") "BNF") ", or a reference implementation written in " (a :href "https://en.wikipedia.org/wiki/C_(programming_language)" (~tw :tokens "text-violet-600 hover:underline") "C") ". You need only " (a :href "https://en.wikipedia.org/wiki/S-expression" (~tw :tokens "text-violet-600 hover:underline") "s-expressions") " — the same medium the programs are made of.")
(p (~tw :tokens "text-stone-600")
"The consequence was immediate and permanent: Lisp became the only language family where the specification, the implementation, the IDE, and the program are all the same kind of thing. Every other language has a boundary between the language and its meta-description. Lisp has none."))
(~docs/section :title "The web failed the test" :id "web-failed"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The web has never had this property. Consider:")
(ul :class "space-y-2 text-stone-600 mt-2"
(ul (~tw :tokens "space-y-2 text-stone-600 mt-2")
(li (strong "URLs") " are opaque strings. They cannot be decomposed, composed, or reasoned about by the content they point to. A URL is a coordinate in an address space, but the address space has no algebra.")
(li (strong "HTML") " is a tree of tags. It cannot express its own parsing rules, its own rendering semantics, or the meaning of its own elements. The " (code "<html>") " spec is a PDF.")
(li (strong "CSS") " is a cascade of declarations. It cannot express the box model, the cascade algorithm, or its own selector matching semantics. These are defined in a 400-page prose document.")
(li (strong "JavaScript") " is a programming language, but it cannot define its own syntax (try writing a " (code "for") " loop as a function), cannot express its own scoping rules, and requires an external parser (written in C++) to bootstrap itself.")
(li (strong "HTTP") " is a text protocol. It cannot describe its own method semantics, its own caching rules, or its own content negotiation algorithm. These are defined in RFCs."))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Every layer of the web stack requires stepping outside the medium to define the medium. This is ontological heterogeneity: the thing and the description of the thing are made of different stuff. The map is not the territory, and the map cannot even be " (em "drawn") " in the territory."))
(~docs/section :title "Ontological uniformity" :id "ontological-uniformity"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The property we need has a name: " (strong "ontological uniformity") ". Address, verb, query, response, rendering instruction, and specification are all the same kind of thing.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In SX, this is literal:")
(ul :class "space-y-2 text-stone-600 mt-2"
(ul (~tw :tokens "space-y-2 text-stone-600 mt-2")
(li (strong "A URL is an s-expression.") " " (code "/sx/(language.(doc.introduction))") " is not an opaque string — it is a parseable, composable expression. It can be decomposed into parts, transformed by functions, and reasoned about by the same evaluator that renders pages.")
(li (strong "A response is an s-expression.") " What the server sends is " (code "(div :class \"p-4\" (h2 \"Hello\"))") " — the same notation as the component that produced it. The wire format is the language.")
(li (strong "A component is an s-expression.") " " (code "(defcomp ~essays/self-defining-medium/card (&key title) (div (h2 title)))") " is simultaneously a definition, a value, and data that can be inspected and transformed.")
(li (strong "A query is an s-expression.") " The URL " (code "/sx/(language.(spec.core))") " is a function call. The response is the return value. Routing is evaluation.")
(li (strong "The specification is s-expressions.") " The " (a :href "/sx/(language.(spec.core))" :class "text-violet-600 hover:underline" "SX spec") " is written in SX. The evaluator is defined in the language it evaluates. The parser is defined in the language it parses."))
(p :class "text-stone-600"
(li (strong "The specification is s-expressions.") " The " (a :href "/sx/(language.(spec.core))" (~tw :tokens "text-violet-600 hover:underline") "SX spec") " is written in SX. The evaluator is defined in the language it evaluates. The parser is defined in the language it parses."))
(p (~tw :tokens "text-stone-600")
"There is " (em "one") " kind of stuff. Everything is made of it. The address of a thing and the thing itself are the same kind of thing."))
(~docs/section :title "What this makes possible" :id "what-this-enables"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"When the medium is uniform, operations that were impossible become trivial:")
(ul :class "space-y-3 text-stone-600 mt-2"
(ul (~tw :tokens "space-y-3 text-stone-600 mt-2")
(li (strong "URLs compose.") " If " (code "(language (doc introduction))") " and " (code "(language (spec core))") " are both expressions, then " (code "(diff (language (spec signals)) (language (spec eval)))") " is a natural composition. Two queries, side by side. The URL algebra falls out of the expression algebra. You do not need to design it separately — it was always there.")
(li (strong "The site can show its own source.") " " (code "/sx/(source.(~essays/self-defining-medium/essay-self-defining-medium))") " returns the component definition of this essay. Not a screenshot. Not a prettified view. The actual s-expression that, when evaluated, produces what you are reading now. The page and its source code are the same kind of thing, so displaying one as the other is just evaluation.")
(li (strong "The spec is executable documentation.") " The " (a :href "/sx/(language.(bootstrapper.self-hosting))" :class "text-violet-600 hover:underline" "self-hosting bootstrapper") " reads the SX spec (written in SX) and produces a working evaluator. The documentation is the implementation. The implementation is the documentation. There is no drift because there is no gap.")
(li (strong "The spec is executable documentation.") " The " (a :href "/sx/(language.(bootstrapper.self-hosting))" (~tw :tokens "text-violet-600 hover:underline") "self-hosting bootstrapper") " reads the SX spec (written in SX) and produces a working evaluator. The documentation is the implementation. The implementation is the documentation. There is no drift because there is no gap.")
(li (strong "Inspection is free.") " " (code "/sx/(inspect.(language.(doc.primitives)))") " can show the dependency graph, CSS footprint, and render plan of any page — because the page is data, and data can be walked, analysed, and reported on by the same system that renders it.")
(li (strong "AI is a native speaker.") " An AI reading SX reads the same notation as the server, the client, the wire, and the spec. There is no translation layer. The AI does not generate code that must be compiled and deployed — it generates expressions that are evaluated. The medium is shared between human, machine, and network.")))
(~docs/section :title "The metacircular web" :id "metacircular-web"
(p :class "text-stone-600"
"McCarthy's " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)#Connection_to_artificial_intelligence" :class "text-violet-600 hover:underline" "metacircular evaluator") " proved that a computing language can define itself. SX extends this proof to a networked hypermedium:")
(ul :class "space-y-2 text-stone-600 mt-2"
(li "The " (strong "evaluator") " is defined in SX: " (a :href "/sx/(language.(spec.eval))" :class "text-violet-600 hover:underline" "eval.sx") " specifies the evaluation rules for all expression types, and this specification is itself an SX document.")
(li "The " (strong "parser") " is defined in SX: " (a :href "/sx/(language.(spec.parser))" :class "text-violet-600 hover:underline" "parser.sx") " specifies tokenization, grammar, and serialization — written in the language it parses.")
(li "The " (strong "renderer") " is defined in SX: " (a :href "/sx/(language.(spec.render))" :class "text-violet-600 hover:underline" "render.sx") " specifies how s-expressions become HTML, SX wire format, or DOM nodes.")
(li "The " (strong "router") " is an expression: " (code "/sx/(language.(doc.introduction))") " is a function call that resolves to content. " (a :href "/sx/(language.(spec.router))" :class "text-violet-600 hover:underline" "router.sx") " specifies the matching — in SX.")
(p (~tw :tokens "text-stone-600")
"McCarthy's " (a :href "https://en.wikipedia.org/wiki/Lisp_(programming_language)#Connection_to_artificial_intelligence" (~tw :tokens "text-violet-600 hover:underline") "metacircular evaluator") " proved that a computing language can define itself. SX extends this proof to a networked hypermedium:")
(ul (~tw :tokens "space-y-2 text-stone-600 mt-2")
(li "The " (strong "evaluator") " is defined in SX: " (a :href "/sx/(language.(spec.eval))" (~tw :tokens "text-violet-600 hover:underline") "eval.sx") " specifies the evaluation rules for all expression types, and this specification is itself an SX document.")
(li "The " (strong "parser") " is defined in SX: " (a :href "/sx/(language.(spec.parser))" (~tw :tokens "text-violet-600 hover:underline") "parser.sx") " specifies tokenization, grammar, and serialization — written in the language it parses.")
(li "The " (strong "renderer") " is defined in SX: " (a :href "/sx/(language.(spec.render))" (~tw :tokens "text-violet-600 hover:underline") "render.sx") " specifies how s-expressions become HTML, SX wire format, or DOM nodes.")
(li "The " (strong "router") " is an expression: " (code "/sx/(language.(doc.introduction))") " is a function call that resolves to content. " (a :href "/sx/(language.(spec.router))" (~tw :tokens "text-violet-600 hover:underline") "router.sx") " specifies the matching — in SX.")
(li "The " (strong "site itself") " is s-expressions: this essay, the navigation tree, the component registry, the wire protocol — all the way down."))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"At every level, the description and the described are the same kind of thing. The specification is not " (em "about") " the system — it " (em "is") " the system. This is not metaphor. It is the literal architecture."))
(~docs/section :title "Why it matters" :id "why-it-matters"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A hypermedium that cannot define itself with itself is a hypermedium that depends on something else for its definition. It is parasitic on external authority — standards bodies, specification documents, reference implementations in foreign languages. Every layer of indirection is a layer where the medium's identity is borrowed rather than intrinsic.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This dependency has practical consequences. When HTML needs a new element, a committee must convene, a specification must be written (in English, in a PDF), browser vendors must implement it (in C++), and the ecosystem must wait. The medium cannot extend itself. It is extended " (em "by others") ", in " (em "other languages") ", on " (em "other timescales") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A self-defining medium extends itself by evaluating new definitions. " (code "(defcomp ~essays/self-defining-medium/new-element (&key attrs children) ...)") " — this is not a proposal to a standards body. It is an expression that, when evaluated, adds a new element to the medium. The medium grows by the same mechanism it operates: evaluation of expressions.")
(p :class "text-stone-600"
"This is the deepest consequence of ontological uniformity. The medium is not just " (em "described by") " itself — it " (em "grows from") " itself. New components, new routing patterns, new wire formats, new rendering modes — all are expressions evaluated by the evaluator that is itself an expression. The system is " (a :href "https://en.wikipedia.org/wiki/Autopoiesis" :class "text-violet-600 hover:underline" "autopoietic") ": it produces and maintains itself through the same operations it performs."))
(p (~tw :tokens "text-stone-600")
"This is the deepest consequence of ontological uniformity. The medium is not just " (em "described by") " itself — it " (em "grows from") " itself. New components, new routing patterns, new wire formats, new rendering modes — all are expressions evaluated by the evaluator that is itself an expression. The system is " (a :href "https://en.wikipedia.org/wiki/Autopoiesis" (~tw :tokens "text-violet-600 hover:underline") "autopoietic") ": it produces and maintains itself through the same operations it performs."))
(~docs/section :title "The test, revisited" :id "test-revisited"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Can the medium define itself with itself?")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"HTML cannot. CSS cannot. JavaScript cannot. HTTP cannot. The web, as a composite medium, cannot — because its layers are mutually opaque and none can express the others.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX can. The evaluator is SX. The parser is SX. The renderer is SX. The wire format is SX. The URLs are SX. The specification is SX. This essay, which argues that the true hypermedium must define itself with itself, is itself an s-expression — evaluated by an evaluator defined in the language it evaluates, served at a URL that is an expression in the language it describes, rendered by a renderer specified in the language it renders.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The serpent eats its tail. The medium defines itself with itself. That is the test, and that is the point."))))

56
sx/sx/essays/separation-of-concerns.sx
View File

@@ -1,48 +1,48 @@
(defcomp ~essays/separation-of-concerns/essay-separation-of-concerns ()
(~docs/page :title "Separate your Own Concerns"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"The web's canonical separation — HTML, CSS, JavaScript — separates the framework's concerns, not yours. Real separation of concerns is domain-specific and cannot be prescribed by a platform.")
(~docs/section :title "The orthodoxy" :id "orthodoxy"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Web development has an article of faith: separate your concerns. Put structure in HTML. Put presentation in CSS. Put behavior in JavaScript. Three languages, three files, three concerns. This is presented as a universal engineering principle — the web platform's gift to good architecture.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"It is nothing of the sort. It is the " (em "framework's") " separation of concerns, not the " (em "application's") ". The web platform needs an HTML parser, a CSS engine, and a JavaScript runtime. These are implementation boundaries internal to the browser. Elevating them to an architectural principle for application developers is like telling a novelist to keep their nouns in one file, verbs in another, and adjectives in a third — because that's how the compiler organises its grammar."))
(~docs/section :title "What is a concern?" :id "what-is-a-concern"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A concern is a cohesive unit of functionality that can change independently. In a shopping application, concerns might be: the product card, the cart, the checkout flow, the search bar. Each of these has structure, style, and behavior that change together. When you redesign the product card, you change its markup, its CSS, and its click handlers — simultaneously, for the same reason, in response to the same requirement.")
(p :class "text-stone-600"
"The traditional web separation scatters this single concern across three files. The product card's markup is in " (code :class "text-violet-700" "products.html") ", tangled with every other page element. Its styles are in " (code :class "text-violet-700" "styles.css") ", mixed with hundreds of unrelated rules. Its behavior is in " (code :class "text-violet-700" "app.js") ", coupled to every other handler by shared scope. To change the product card, you edit three files, grep for the right selectors, hope nothing else depends on the same class names, and pray.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The traditional web separation scatters this single concern across three files. The product card's markup is in " (code (~tw :tokens "text-violet-700") "products.html") ", tangled with every other page element. Its styles are in " (code (~tw :tokens "text-violet-700") "styles.css") ", mixed with hundreds of unrelated rules. Its behavior is in " (code (~tw :tokens "text-violet-700") "app.js") ", coupled to every other handler by shared scope. To change the product card, you edit three files, grep for the right selectors, hope nothing else depends on the same class names, and pray.")
(p (~tw :tokens "text-stone-600")
"This is not separation of concerns. It is " (strong "commingling") " of concerns, organized by language rather than by meaning."))
(~docs/section :title "The framework's concerns are not yours" :id "framework-concerns"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The browser has good reasons to separate HTML, CSS, and JavaScript. The HTML parser builds a DOM tree. The CSS engine resolves styles and computes layout. The JS runtime manages execution contexts, event loops, and garbage collection. These are distinct subsystems with distinct performance characteristics, security models, and parsing strategies.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But you are not building a browser. You are building an application. Your concerns are: what does a product card look like? What happens when a user clicks 'add to cart'? How does the search filter update the results? These questions cut across markup, style, and behavior. They are not aligned with the browser's internal module boundaries.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"When a framework tells you to separate by technology — HTML here, CSS there, JS over there — it is asking you to organize your application around " (em "its") " architecture, not around your problem domain. You are serving the framework's interests. The framework is not serving yours."))
(~docs/section :title "React understood the problem" :id "react"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"React's most radical insight was not the virtual DOM or one-way data flow. It was the assertion that a component — markup, style, behavior, all co-located — is the right unit of abstraction for UI. JSX was controversial precisely because it violated the orthodoxy. You are putting HTML in your JavaScript! The concerns are not separated!")
(p :class "text-stone-600"
"But the concerns " (em "were") " separated — by component, not by language. A " (code :class "text-violet-700" "<ProductCard>") " contains everything about product cards. A " (code :class "text-violet-700" "<SearchBar>") " contains everything about search bars. Changing one component does not require changes to another. That is separation of concerns — real separation, based on what changes together.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"But the concerns " (em "were") " separated — by component, not by language. A " (code (~tw :tokens "text-violet-700") "<ProductCard>") " contains everything about product cards. A " (code (~tw :tokens "text-violet-700") "<SearchBar>") " contains everything about search bars. Changing one component does not require changes to another. That is separation of concerns — real separation, based on what changes together.")
(p (~tw :tokens "text-stone-600")
"CSS-in-JS libraries followed the same logic. If styles belong to a component, they should live with that component. Not in a global stylesheet where any selector can collide with any other. The backlash — \"you're mixing concerns!\" — betrayed a fundamental confusion between " (em "technologies") " and " (em "concerns") "."))
(~docs/section :title "Separation of concerns is domain-specific" :id "domain-specific"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Here is the key point: " (strong "no framework can tell you what your concerns are") ". Concerns are determined by your domain, your requirements, and your rate of change. A medical records system has different concerns from a social media feed. An e-commerce checkout has different concerns from a real-time dashboard. The boundaries between concerns are discovered through building the application, not prescribed in advance by a platform specification.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A framework that imposes a fixed separation — this file for structure, that file for style — is claiming universal knowledge of every possible application domain. That claim is obviously false. Yet it has shaped twenty-five years of web development tooling, project structures, and hiring practices.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The right question is never \"are your HTML, CSS, and JS in separate files?\" The right question is: \"when a requirement changes, how many files do you touch, and how many of those changes are unrelated to each other?\" If you touch three files and all three changes serve the same requirement, your concerns are not separated — they are scattered."))
(~docs/section :title "What SX does differently" :id "sx-approach"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"An SX component is a single expression that contains its structure, its style (as keyword-resolved CSS classes), and its behavior (event bindings, conditionals, data flow). Nothing is in a separate file unless it genuinely represents a separate concern.")
(~docs/code :src "(defcomp ~essays/separation-of-concerns/product-card (&key product on-add)
(div :class \"rounded-lg border border-stone-200 p-4 hover:shadow-md transition-shadow\"
@@ -59,35 +59,35 @@
:sx-post (str \"/cart/add/\" (get product \"id\"))
:sx-target \"#cart-count\"
\"Add to cart\"))))")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Structure, style, and behavior are co-located because they represent " (em "one concern") ": the product card. The component can be moved, renamed, reused, or deleted as a unit. Changing its appearance does not require editing a global stylesheet. Changing its click behavior does not require searching through a shared script file.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a rejection of separation of concerns. It is separation of concerns taken seriously — by the domain, not by the framework."))
(~docs/section :title "When real separation matters" :id "real-separation"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Genuine separation of concerns still applies, but at the right boundaries:")
(ul :class "space-y-2 text-stone-600"
(ul (~tw :tokens "space-y-2 text-stone-600")
(li (strong "Components from each other") " — a product card should not know about the checkout flow. They interact through props and events, not shared mutable state.")
(li (strong "Data from presentation") " — the product data comes from a service or API, not from hardcoded markup. The component receives data; it does not fetch or own it.")
(li (strong "Platform from application") " — SX's boundary spec separates host primitives from application logic. The evaluator does not know about HTTP. Page helpers do not know about the AST.")
(li (strong "Content from chrome") " — layout components (nav, footer, sidebar) are separate from content components (articles, product listings, forms). They compose, they do not intermingle."))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"These boundaries emerge from the application's actual structure. They happen to cut across HTML, CSS, and JavaScript freely — because those categories were never meaningful to begin with."))
(~docs/section :title "The cost of the wrong separation" :id "cost"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The HTML/CSS/JS separation has real costs that have been absorbed so thoroughly they are invisible:")
(ul :class "space-y-2 text-stone-600"
(ul (~tw :tokens "space-y-2 text-stone-600")
(li (strong "Selector coupling") " — CSS selectors create implicit dependencies between stylesheets and markup. Rename a class in HTML, forget to update the CSS, and styles silently break. No compiler error. No runtime error. Just a broken layout discovered in production.")
(li (strong "Global namespace collision") " — every CSS rule lives in a global namespace. BEM, SMACSS, CSS Modules, scoped styles — these are all workarounds for a problem that only exists because styles were separated from the things they style.")
(li (strong "Shotgun surgery") " — a single feature change requires coordinated edits across HTML, CSS, and JS files. Miss one, and the feature is half-implemented. The change has a blast radius proportional to the number of technology layers, not the number of domain concerns.")
(li (strong "Dead code accumulation") " — CSS rules outlive the markup they were written for. Nobody deletes old styles because nobody can be sure what else depends on them. Stylesheets grow monotonically. Refactoring is archaeology."))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Every one of these problems vanishes when style, structure, and behavior are co-located in a component. Delete the component, and its styles, markup, and handlers are gone. No orphans. No archaeology."))
(~docs/section :title "The principle, stated plainly" :id "principle"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Separation of concerns is a domain-specific design decision. It cannot be imposed by a framework. The web platform's HTML/CSS/JS split is an implementation detail of the browser, not an architectural principle for applications. Treating it as one has cost the industry decades of unnecessary complexity, tooling, and convention.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Separate the things that change for different reasons. Co-locate the things that change together. That is the entire principle. It says nothing about file extensions."))))

156
sx/sx/essays/server-architecture.sx
View File

@@ -1,110 +1,110 @@
(defcomp ~essays/server-architecture/essay-server-architecture ()
(~docs/page :title "Server Architecture"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"How SX enforces the boundary between host language and embedded language, why that boundary matters, and what it looks like across different target languages.")
(~docs/section :title "The island constraint" :id "island"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX is an embedded language. It runs inside a host language — for example Python on the server, JavaScript in the browser. The central architectural constraint is that SX is a " (strong "pure island") ": the evaluator sees values in and values out. No host objects leak into the SX environment. No SX expressions reach into host internals. Every interaction between SX and the host passes through a declared, validated boundary.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a performance optimization or a convenience. It is the property that makes self-hosting possible. If host objects can leak into SX environments, then the spec files depend on host-specific types. If SX expressions can call host functions directly, the evaluator's behavior varies per host. Neither of those is compatible with a single specification that bootstraps to multiple targets.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The constraint: " (strong "nothing crosses the boundary unless it is declared in a spec file and its type is one of the boundary types") "."))
(~docs/section :title "Three tiers" :id "tiers"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Host functions that SX can call are organized into three tiers, each with different trust levels and declaration requirements:")
(div :class "space-y-4"
(div :class "border rounded-lg p-4 border-stone-200"
(h3 :class "font-semibold text-stone-800 mb-2" "Tier 1: Pure primitives")
(p :class "text-stone-600 text-sm"
"Declared in " (code :class "text-violet-700 text-sm" "primitives.sx") ". About 80 functions — arithmetic, string operations, list operations, dict operations, type predicates. All pure: values in, values out, no side effects. These are the only host functions visible to the spec itself. Every bootstrapper must implement all of them."))
(div :class "border rounded-lg p-4 border-stone-200"
(h3 :class "font-semibold text-stone-800 mb-2" "Tier 2: I/O primitives")
(p :class "text-stone-600 text-sm"
"Declared in " (code :class "text-violet-700 text-sm" "boundary.sx") ". Cross-service queries, fragment fetching, request context access, URL generation. Async and side-effectful. They need host context (HTTP request, database connection, config). The SX resolver identifies these in the render tree, gathers them, executes them in parallel, and substitutes results back in."))
(div :class "border rounded-lg p-4 border-stone-200"
(h3 :class "font-semibold text-stone-800 mb-2" "Tier 3: Page helpers")
(p :class "text-stone-600 text-sm"
"Also declared in " (code :class "text-violet-700 text-sm" "boundary.sx") ". Service-scoped Python functions registered via " (code :class "text-violet-700 text-sm" "register_page_helpers()") ". They provide data for specific page types — syntax highlighting, reference table data, bootstrapper output. Each helper is bound to a specific service and available only in that service's page evaluation environment."))))
(div (~tw :tokens "space-y-4")
(div (~tw :tokens "border rounded-lg p-4 border-stone-200")
(h3 (~tw :tokens "font-semibold text-stone-800 mb-2") "Tier 1: Pure primitives")
(p (~tw :tokens "text-stone-600 text-sm")
"Declared in " (code (~tw :tokens "text-violet-700 text-sm") "primitives.sx") ". About 80 functions — arithmetic, string operations, list operations, dict operations, type predicates. All pure: values in, values out, no side effects. These are the only host functions visible to the spec itself. Every bootstrapper must implement all of them."))
(div (~tw :tokens "border rounded-lg p-4 border-stone-200")
(h3 (~tw :tokens "font-semibold text-stone-800 mb-2") "Tier 2: I/O primitives")
(p (~tw :tokens "text-stone-600 text-sm")
"Declared in " (code (~tw :tokens "text-violet-700 text-sm") "boundary.sx") ". Cross-service queries, fragment fetching, request context access, URL generation. Async and side-effectful. They need host context (HTTP request, database connection, config). The SX resolver identifies these in the render tree, gathers them, executes them in parallel, and substitutes results back in."))
(div (~tw :tokens "border rounded-lg p-4 border-stone-200")
(h3 (~tw :tokens "font-semibold text-stone-800 mb-2") "Tier 3: Page helpers")
(p (~tw :tokens "text-stone-600 text-sm")
"Also declared in " (code (~tw :tokens "text-violet-700 text-sm") "boundary.sx") ". Service-scoped Python functions registered via " (code (~tw :tokens "text-violet-700 text-sm") "register_page_helpers()") ". They provide data for specific page types — syntax highlighting, reference table data, bootstrapper output. Each helper is bound to a specific service and available only in that service's page evaluation environment."))))
(~docs/section :title "Boundary types" :id "types"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Only these types may cross the host-SX boundary:")
(~docs/code :src (highlight "(define-boundary-types\n (list \"number\" \"string\" \"boolean\" \"nil\" \"keyword\"\n \"list\" \"dict\" \"sx-source\" \"style-value\"))" "lisp"))
(p :class "text-stone-600"
"No Python " (code :class "text-violet-700 text-sm" "datetime") " objects. No ORM models. No Quart request objects. If a host function returns a " (code :class "text-violet-700 text-sm" "datetime") ", it must convert to an ISO string before crossing. If it returns a database row, it must convert to a plain dict. The boundary validation checks this recursively — lists and dicts have their elements checked too.")
(p :class "text-stone-600"
"The " (code :class "text-violet-700 text-sm" "sx-source") " type is SX source text wrapped in an " (code :class "text-violet-700 text-sm" "SxExpr") " marker. It allows the host to pass pre-rendered SX markup into the tree — but only the host can create it. SX code cannot construct SxExpr values; it can only receive them from the boundary."))
(p (~tw :tokens "text-stone-600")
"No Python " (code (~tw :tokens "text-violet-700 text-sm") "datetime") " objects. No ORM models. No Quart request objects. If a host function returns a " (code (~tw :tokens "text-violet-700 text-sm") "datetime") ", it must convert to an ISO string before crossing. If it returns a database row, it must convert to a plain dict. The boundary validation checks this recursively — lists and dicts have their elements checked too.")
(p (~tw :tokens "text-stone-600")
"The " (code (~tw :tokens "text-violet-700 text-sm") "sx-source") " type is SX source text wrapped in an " (code (~tw :tokens "text-violet-700 text-sm") "SxExpr") " marker. It allows the host to pass pre-rendered SX markup into the tree — but only the host can create it. SX code cannot construct SxExpr values; it can only receive them from the boundary."))
(~docs/section :title "Enforcement" :id "enforcement"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The boundary contract is enforced at three points, each corresponding to a tier:")
(div :class "space-y-3"
(div :class "bg-stone-100 rounded p-4"
(p :class "text-sm text-stone-700"
(strong "Primitive registration. ") "When " (code :class "text-violet-700 text-sm" "@register_primitive") " decorates a function, it calls " (code :class "text-violet-700 text-sm" "validate_primitive(name)") ". If the name is not declared in " (code :class "text-violet-700 text-sm" "primitives.sx") ", the service fails to start."))
(div :class "bg-stone-100 rounded p-4"
(p :class "text-sm text-stone-700"
(strong "I/O handler registration. ") "When " (code :class "text-violet-700 text-sm" "primitives_io.py") " builds the " (code :class "text-violet-700 text-sm" "_IO_HANDLERS") " dict, each name is validated against " (code :class "text-violet-700 text-sm" "boundary.sx") ". Undeclared I/O primitives crash the import."))
(div :class "bg-stone-100 rounded p-4"
(p :class "text-sm text-stone-700"
(strong "Page helper registration. ") "When a service calls " (code :class "text-violet-700 text-sm" "register_page_helpers(service, helpers)") ", each helper name is validated against " (code :class "text-violet-700 text-sm" "boundary.sx") " for that service. Undeclared helpers fail. Return values are wrapped to pass through " (code :class "text-violet-700 text-sm" "validate_boundary_value()") ".")))
(p :class "text-stone-600"
"All three checks are controlled by the " (code :class "text-violet-700 text-sm" "SX_BOUNDARY_STRICT") " environment variable. With " (code :class "text-violet-700 text-sm" "\"1\"") " (the production default), violations crash at startup. Without it, they log warnings. The strict mode is set in both " (code :class "text-violet-700 text-sm" "docker-compose.yml") " and " (code :class "text-violet-700 text-sm" "docker-compose.dev.yml") "."))
(div (~tw :tokens "space-y-3")
(div (~tw :tokens "bg-stone-100 rounded p-4")
(p (~tw :tokens "text-sm text-stone-700")
(strong "Primitive registration. ") "When " (code (~tw :tokens "text-violet-700 text-sm") "@register_primitive") " decorates a function, it calls " (code (~tw :tokens "text-violet-700 text-sm") "validate_primitive(name)") ". If the name is not declared in " (code (~tw :tokens "text-violet-700 text-sm") "primitives.sx") ", the service fails to start."))
(div (~tw :tokens "bg-stone-100 rounded p-4")
(p (~tw :tokens "text-sm text-stone-700")
(strong "I/O handler registration. ") "When " (code (~tw :tokens "text-violet-700 text-sm") "primitives_io.py") " builds the " (code (~tw :tokens "text-violet-700 text-sm") "_IO_HANDLERS") " dict, each name is validated against " (code (~tw :tokens "text-violet-700 text-sm") "boundary.sx") ". Undeclared I/O primitives crash the import."))
(div (~tw :tokens "bg-stone-100 rounded p-4")
(p (~tw :tokens "text-sm text-stone-700")
(strong "Page helper registration. ") "When a service calls " (code (~tw :tokens "text-violet-700 text-sm") "register_page_helpers(service, helpers)") ", each helper name is validated against " (code (~tw :tokens "text-violet-700 text-sm") "boundary.sx") " for that service. Undeclared helpers fail. Return values are wrapped to pass through " (code (~tw :tokens "text-violet-700 text-sm") "validate_boundary_value()") ".")))
(p (~tw :tokens "text-stone-600")
"All three checks are controlled by the " (code (~tw :tokens "text-violet-700 text-sm") "SX_BOUNDARY_STRICT") " environment variable. With " (code (~tw :tokens "text-violet-700 text-sm") "\"1\"") " (the production default), violations crash at startup. Without it, they log warnings. The strict mode is set in both " (code (~tw :tokens "text-violet-700 text-sm") "docker-compose.yml") " and " (code (~tw :tokens "text-violet-700 text-sm") "docker-compose.dev.yml") "."))
(~docs/section :title "The SX-in-Python rule" :id "sx-in-python"
(p :class "text-stone-600"
"One enforcement that is not automated but equally important: " (strong "SX source code must not be constructed as Python strings") ". S-expressions belong in " (code :class "text-violet-700 text-sm" ".sx") " files. Python belongs in " (code :class "text-violet-700 text-sm" ".py") " files. If you see a Python f-string that builds " (code :class "text-violet-700 text-sm" "(div :class ...)") ", that is a boundary violation.")
(p :class "text-stone-600"
"The correct pattern: Python returns " (strong "data") " (dicts, lists, strings). " (code :class "text-violet-700 text-sm" ".sx") " files receive data via keyword args and compose the markup. The only exception is " (code :class "text-violet-700 text-sm" "SxExpr") " wrappers for pre-rendered fragments — and those should be built with " (code :class "text-violet-700 text-sm" "sx_call()") " or " (code :class "text-violet-700 text-sm" "_sx_fragment()") ", never with f-strings.")
(p (~tw :tokens "text-stone-600")
"One enforcement that is not automated but equally important: " (strong "SX source code must not be constructed as Python strings") ". S-expressions belong in " (code (~tw :tokens "text-violet-700 text-sm") ".sx") " files. Python belongs in " (code (~tw :tokens "text-violet-700 text-sm") ".py") " files. If you see a Python f-string that builds " (code (~tw :tokens "text-violet-700 text-sm") "(div :class ...)") ", that is a boundary violation.")
(p (~tw :tokens "text-stone-600")
"The correct pattern: Python returns " (strong "data") " (dicts, lists, strings). " (code (~tw :tokens "text-violet-700 text-sm") ".sx") " files receive data via keyword args and compose the markup. The only exception is " (code (~tw :tokens "text-violet-700 text-sm") "SxExpr") " wrappers for pre-rendered fragments — and those should be built with " (code (~tw :tokens "text-violet-700 text-sm") "sx_call()") " or " (code (~tw :tokens "text-violet-700 text-sm") "_sx_fragment()") ", never with f-strings.")
(~docs/code :src (highlight ";; CORRECT: .sx file composes markup from data\n(defcomp ~essays/server-architecture/my-page (&key items)\n (div :class \"space-y-4\"\n (map (fn (item)\n (div :class \"border rounded p-3\"\n (h3 (get item \"title\"))\n (p (get item \"desc\"))))\n items)))" "lisp"))
(~docs/code :src (highlight "# CORRECT: Python returns data\ndef _my_page_data():\n return {\"items\": [{\"title\": \"A\", \"desc\": \"B\"}]}\n\n# WRONG: Python builds SX source\ndef _my_page_data():\n return SxExpr(f'(div (h3 \"{title}\"))') # NO" "python")))
(~docs/section :title "Why this matters for multiple languages" :id "languages"
(p :class "text-stone-600"
"The boundary contract is target-agnostic. " (code :class "text-violet-700 text-sm" "boundary.sx") " and " (code :class "text-violet-700 text-sm" "primitives.sx") " declare what crosses the boundary. Each bootstrapper reads those declarations and emits the strongest enforcement the target language supports:")
(div :class "overflow-x-auto rounded border border-stone-200 my-4"
(table :class "w-full text-left text-sm"
(thead (tr :class "border-b border-stone-200 bg-stone-100"
(th :class "px-3 py-2 font-medium text-stone-600" "Target")
(th :class "px-3 py-2 font-medium text-stone-600" "Enforcement")
(th :class "px-3 py-2 font-medium text-stone-600" "Mechanism")))
(p (~tw :tokens "text-stone-600")
"The boundary contract is target-agnostic. " (code (~tw :tokens "text-violet-700 text-sm") "boundary.sx") " and " (code (~tw :tokens "text-violet-700 text-sm") "primitives.sx") " declare what crosses the boundary. Each bootstrapper reads those declarations and emits the strongest enforcement the target language supports:")
(div (~tw :tokens "overflow-x-auto rounded border border-stone-200 my-4")
(table (~tw :tokens "w-full text-left text-sm")
(thead (tr (~tw :tokens "border-b border-stone-200 bg-stone-100")
(th (~tw :tokens "px-3 py-2 font-medium text-stone-600") "Target")
(th (~tw :tokens "px-3 py-2 font-medium text-stone-600") "Enforcement")
(th (~tw :tokens "px-3 py-2 font-medium text-stone-600") "Mechanism")))
(tbody
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "Python")
(td :class "px-3 py-2 text-stone-600" "Runtime")
(td :class "px-3 py-2 text-stone-500 text-sm" "Frozen sets + validation at registration"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "JavaScript")
(td :class "px-3 py-2 text-stone-600" "Runtime")
(td :class "px-3 py-2 text-stone-500 text-sm" "Set guards on registerPrimitive()"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "Rust")
(td :class "px-3 py-2 text-stone-600" "Compile-time")
(td :class "px-3 py-2 text-stone-500 text-sm" "SxValue enum, trait bounds on primitive fns"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "Haskell")
(td :class "px-3 py-2 text-stone-600" "Compile-time")
(td :class "px-3 py-2 text-stone-500 text-sm" "ADT + typeclass constraints"))
(tr :class "border-b border-stone-100"
(td :class "px-3 py-2 text-stone-700" "TypeScript")
(td :class "px-3 py-2 text-stone-600" "Compile-time")
(td :class "px-3 py-2 text-stone-500 text-sm" "Discriminated union types")))))
(p :class "text-stone-600"
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "Python")
(td (~tw :tokens "px-3 py-2 text-stone-600") "Runtime")
(td (~tw :tokens "px-3 py-2 text-stone-500 text-sm") "Frozen sets + validation at registration"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "JavaScript")
(td (~tw :tokens "px-3 py-2 text-stone-600") "Runtime")
(td (~tw :tokens "px-3 py-2 text-stone-500 text-sm") "Set guards on registerPrimitive()"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "Rust")
(td (~tw :tokens "px-3 py-2 text-stone-600") "Compile-time")
(td (~tw :tokens "px-3 py-2 text-stone-500 text-sm") "SxValue enum, trait bounds on primitive fns"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "Haskell")
(td (~tw :tokens "px-3 py-2 text-stone-600") "Compile-time")
(td (~tw :tokens "px-3 py-2 text-stone-500 text-sm") "ADT + typeclass constraints"))
(tr (~tw :tokens "border-b border-stone-100")
(td (~tw :tokens "px-3 py-2 text-stone-700") "TypeScript")
(td (~tw :tokens "px-3 py-2 text-stone-600") "Compile-time")
(td (~tw :tokens "px-3 py-2 text-stone-500 text-sm") "Discriminated union types")))))
(p (~tw :tokens "text-stone-600")
"In Python and JavaScript, boundary violations are caught at startup. In Rust, Haskell, or TypeScript, they would be caught at compile time — a function that returns a non-boundary type simply would not type-check. The spec is the same; the enforcement level rises with the type system.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is the payoff of the pure island constraint. Because SX never touches host internals, a bootstrapper for a new target only needs to implement the declared primitives and boundary functions. The evaluator, renderer, parser, and all components work unchanged. One spec, every target, same guarantees."))
(~docs/section :title "The spec as contract" :id "contract"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The boundary enforcement files form a closed contract:")
(ul :class "space-y-2 text-stone-600"
(li (code :class "text-violet-700 text-sm" "primitives.sx") " — declares every pure function SX can call")
(li (code :class "text-violet-700 text-sm" "boundary.sx") " — declares every I/O function and page helper")
(li (code :class "text-violet-700 text-sm" "boundary_parser.py") " — reads both files, extracts declared names")
(li (code :class "text-violet-700 text-sm" "boundary.py") " — runtime validation (validate_primitive, validate_io, validate_helper, validate_boundary_value)"))
(p :class "text-stone-600"
(ul (~tw :tokens "space-y-2 text-stone-600")
(li (code (~tw :tokens "text-violet-700 text-sm") "primitives.sx") " — declares every pure function SX can call")
(li (code (~tw :tokens "text-violet-700 text-sm") "boundary.sx") " — declares every I/O function and page helper")
(li (code (~tw :tokens "text-violet-700 text-sm") "boundary_parser.py") " — reads both files, extracts declared names")
(li (code (~tw :tokens "text-violet-700 text-sm") "boundary.py") " — runtime validation (validate_primitive, validate_io, validate_helper, validate_boundary_value)"))
(p (~tw :tokens "text-stone-600")
"If you add a new host function and forget to declare it, the service will not start. If you return a disallowed type, the validation will catch it. The spec files are not documentation — they are the mechanism. The bootstrappers read them. The validators parse them. The contract is enforced by the same files that describe it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This closes the loop on self-hosting. The SX spec defines the language. The boundary spec defines the edge. The bootstrappers generate implementations from both. And the generated code validates itself against the spec at startup. The spec is the implementation is the contract is the spec."))))

86
sx/sx/essays/sx-and-ai.sx
View File

@@ -1,109 +1,109 @@
(defcomp ~essays/sx-and-ai/essay-sx-and-ai ()
(~docs/page :title "SX and AI"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"Why s-expressions are the most AI-friendly representation for web interfaces — and what that means for how software gets built.")
(~docs/section :title "The syntax tax" :id "syntax-tax"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Every programming language imposes a syntax tax on AI code generation. The model must produce output that satisfies a grammar — matching braces, semicolons in the right places, operator precedence, indentation rules, closing tags that match opening tags. The more complex the grammar, the more tokens the model wastes on syntactic bookkeeping instead of semantic intent.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Consider what an AI must get right to produce a valid React component: JSX tags that open and close correctly, curly braces for JavaScript expressions inside markup, import statements with correct paths, semicolons or ASI rules, TypeScript type annotations, CSS-in-JS string literals with different quoting rules than the surrounding code. Each syntactic concern is a potential failure point. Each failure produces something that does not parse, let alone run.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"S-expressions have one syntactic form: " (code "(head args...)") ". Parentheses open and close. Strings are quoted. That is the entire grammar. There is no operator precedence because there are no operators. There is no indentation sensitivity because whitespace is not significant. There are no closing tags because there are no tags — just lists.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The syntax tax for SX is essentially zero. An AI that can count parentheses can produce syntactically valid SX. This is not a small advantage — it is a categorical one. The model spends its capacity on " (em "what") " to generate, not " (em "how") " to format it."))
(~docs/section :title "One representation for everything" :id "one-representation"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A typical web project requires the AI to context-switch between HTML (angle brackets, void elements, boolean attributes), CSS (selectors, properties, at-rules, a completely different syntax from HTML), JavaScript (statements, expressions, classes, closures, async/await), and whatever templating language glues them together (Jinja delimiters, ERB tags, JSX interpolation). Each is a separate grammar. Each has edge cases. Each interacts with the others in ways that are hard to predict.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In SX, structure, style, logic, and data are all s-expressions:")
(~docs/code :src (highlight ";; Structure\n(div :class \"card\" (h2 title) (p body))\n\n;; Style\n(cssx card-style\n :bg white :rounded-lg :shadow-md :p 6)\n\n;; Logic\n(if (> (length items) 0)\n (map render-item items)\n (p \"No items found.\"))\n\n;; Data\n{:name \"Alice\" :role \"admin\" :active true}\n\n;; Component definition\n(defcomp ~essays/sx-and-ai/user-card (&key user)\n (div :class \"card\"\n (h2 (get user \"name\"))\n (span :class \"badge\" (get user \"role\"))))" "lisp"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The AI learns one syntax and applies it everywhere. The mental model does not fragment across subsystems. A " (code "div") " and an " (code "if") " and a " (code "defcomp") " are all lists. The model that generates one can generate all three, because they are the same thing."))
(~docs/section :title "The spec fits in a context window" :id "spec-fits"
(p :class "text-stone-600"
"The complete SX language specification — evaluator, parser, renderer, primitives — lives in four files totalling roughly 3,000 lines. An AI model with a 200k token context window can hold the " (em "entire language definition") " alongside the user's codebase and still have room to work. Compare this to JavaScript (the " (a :href "https://ecma-international.org/publications-and-standards/standards/ecma-262/" :class "text-violet-600 hover:underline" "ECMAScript specification") " is 900+ pages), or the combined specifications for HTML, CSS, and the DOM.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The complete SX language specification — evaluator, parser, renderer, primitives — lives in four files totalling roughly 3,000 lines. An AI model with a 200k token context window can hold the " (em "entire language definition") " alongside the user's codebase and still have room to work. Compare this to JavaScript (the " (a :href "https://ecma-international.org/publications-and-standards/standards/ecma-262/" (~tw :tokens "text-violet-600 hover:underline") "ECMAScript specification") " is 900+ pages), or the combined specifications for HTML, CSS, and the DOM.")
(p (~tw :tokens "text-stone-600")
"This is not just a convenience — it changes what kind of code the AI produces. When the model has the full spec in context, it does not hallucinate nonexistent features. It does not confuse one version's semantics with another's. It knows exactly which primitives exist, which special forms are available, and how evaluation works — because it is reading the authoritative definition, not interpolating from training data.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The spec is also written in SX. " (code "eval.sx") " defines the evaluator as s-expressions. " (code "parser.sx") " defines the parser as s-expressions. The language the AI is generating is the same language the spec is written in. There is no translation gap between \"understanding the language\" and \"using the language\" — they are the same act of reading s-expressions."))
(~docs/section :title "Structural validation is trivial" :id "structural-validation"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Validating AI output before executing it is a critical safety concern. With conventional languages, validation means running a full parser, type checker, and linter — each with their own error recovery modes and edge cases. With SX, structural validation is: " (em "do the parentheses balance?") " That is it. If they balance, the expression parses. If it parses, it can be evaluated.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This makes it trivial to build AI pipelines that generate SX. Parse the output. If it parses, evaluate it in a sandbox. If it does not parse, the error is always the same kind — unmatched parentheses — and the fix is always mechanical. There is no \"your JSX is invalid because you used " (code "class") " instead of " (code "className") "\" or \"you forgot the semicolon after the type annotation but before the generic constraint.\"")
(p :class "text-stone-600"
"Beyond parsing, the SX " (a :href "/sx/(language.(spec.primitives))" :class "text-violet-600 hover:underline" "boundary system") " provides semantic validation. A pure component cannot call IO primitives — not by convention, but by the evaluator refusing to resolve them. An AI generating a component can produce whatever expressions it wants; the sandbox ensures only permitted operations execute. Validation is not a separate step bolted onto the pipeline. It is the language."))
(p (~tw :tokens "text-stone-600")
"Beyond parsing, the SX " (a :href "/sx/(language.(spec.primitives))" (~tw :tokens "text-violet-600 hover:underline") "boundary system") " provides semantic validation. A pure component cannot call IO primitives — not by convention, but by the evaluator refusing to resolve them. An AI generating a component can produce whatever expressions it wants; the sandbox ensures only permitted operations execute. Validation is not a separate step bolted onto the pipeline. It is the language."))
(~docs/section :title "Components are self-documenting" :id "self-documenting"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A React component's interface is spread across prop types (or TypeScript interfaces), JSDoc comments, Storybook stories, and whatever documentation someone wrote. An AI reading a component must synthesize information from multiple sources to understand what it accepts and what it produces.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"An SX component declares everything in one expression:")
(~docs/code :src (highlight "(defcomp ~essays/sx-and-ai/product-card (&key title price image &rest children)\n (div :class \"rounded border p-4\"\n (img :src image :alt title)\n (h3 :class \"font-bold\" title)\n (span :class \"text-lg\" (format-price price))\n children))" "lisp"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The AI reads this and knows: it takes " (code "title") ", " (code "price") ", and " (code "image") " as keyword arguments, and " (code "children") " as rest arguments. It knows the output structure — a " (code "div") " with an image, heading, price, and slot for children. It knows this because the definition " (em "is") " the documentation. There is no separate spec to consult, no type file to find, no ambiguity about which props are required.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This self-describing property scales across the entire component environment. An AI can " (code "(map ...)") " over every component in the registry, extract all parameter signatures, build a complete map of the UI vocabulary — and generate compositions that use it correctly, because the interface is declared in the same language the AI is generating."))
(~docs/section :title "Token efficiency" :id "token-efficiency"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"LLMs operate on tokens. Every token costs compute, latency, and money. The information density of a representation — how much semantics per token — directly affects how much an AI can see, generate, and reason about within its context window and output budget.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Compare equivalent UI definitions:")
(~docs/code :src (highlight ";; SX: 42 tokens\n(div :class \"card p-4\"\n (h2 :class \"font-bold\" title)\n (p body)\n (when footer\n (div :class \"mt-4 border-t pt-2\" footer)))" "lisp"))
(~docs/code :src (highlight "// React/JSX: ~75 tokens\n<div className=\"card p-4\">\n <h2 className=\"font-bold\">{title}</h2>\n <p>{body}</p>\n {footer && (\n <div className=\"mt-4 border-t pt-2\">{footer}</div>\n )}\n</div>" "python"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The SX version is roughly 40% fewer tokens for equivalent semantics. No closing tags. No curly-brace interpolation. No " (code "className") " vs " (code "class") " distinction. Every token carries meaning. Over an entire application — dozens of components, hundreds of expressions — this compounds into significantly more code visible per context window and significantly less output the model must generate."))
(~docs/section :title "Composability is free" :id "composability"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The hardest thing for AI to get right in conventional frameworks is composition — how pieces fit together. React has rules about hooks. Vue has template vs script vs style sections. Angular has modules, declarations, and dependency injection. Each framework's composition model is a set of conventions the AI must learn and apply correctly.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"S-expressions compose by nesting. A list inside a list is a composition. There are no rules beyond this:")
(~docs/code :src (highlight ";; Compose components by nesting — that's it\n(~page-layout :title \"Dashboard\"\n (~sidebar\n (~nav-menu :items menu-items))\n (~main-content\n (map ~essays/sx-and-ai/user-card users)\n (~pagination :page current-page :total total-pages)))" "lisp"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"No imports to manage. No registration steps. No render props, higher-order components, or composition APIs. The AI generates a nested structure and it works, because nesting is the only composition mechanism. This eliminates an entire class of errors that plague AI-generated code in conventional frameworks — the kind where each piece works in isolation but the assembly is wrong."))
(~docs/section :title "The feedback loop" :id "feedback-loop"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX has no build step. Generated s-expressions can be evaluated immediately — in the browser, on the server, in a test harness. The AI generates an expression, the system evaluates it, the result is visible. If it is wrong, the AI reads the result (also an s-expression), adjusts, and regenerates. The loop is:")
(ol :class "list-decimal pl-5 text-stone-600 space-y-1 mt-2"
(ol (~tw :tokens "list-decimal pl-5 text-stone-600 space-y-1 mt-2")
(li "AI generates SX expression")
(li "System parses (parentheses balance? done)")
(li "Evaluator runs in sandbox (boundary-enforced)")
(li "Result rendered or error returned (as s-expression)")
(li "AI reads result, iterates"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Compare this to the conventional loop: AI generates code → linter runs → TypeScript compiles → bundler builds → browser loads → error appears in DevTools console → human copies error back to AI → AI regenerates. Each step is a different tool with different output formats. Each introduces latency and potential information loss.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The SX loop is also " (em "uniform") ". The input is s-expressions. The output is s-expressions. The error messages are s-expressions. The AI never needs to parse a stack trace format or extract meaning from a webpack error. Everything is the same data structure, all the way down."))
(~docs/section :title "This site is the proof" :id "proof"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not theoretical. Everything you are looking at — every page, every component, every line of this essay — was produced by agentic AI. Not \"AI-assisted\" in the polite sense of autocomplete suggestions. " (em "Produced.") " The SX language specification. The parser. The evaluator. The renderer. The bootstrappers that transpile the spec to JavaScript and Python. The boundary enforcement system. The dependency analyser. The on-demand CSS engine. The client-side router. The component bundler. The syntax highlighter. This documentation site. The Docker deployment. All of it.")
(p :class "text-stone-600"
"The human driving this has never written a line of Lisp. Not Common Lisp. Not Scheme. Not Clojure. Not Emacs Lisp. Has never opened the codebase in VS Code, vi, or any other editor. Every file was created and modified through " (a :href "https://claude.ai/" :class "text-violet-600 hover:underline" "Claude") " running in a terminal — reading files, writing files, running commands, iterating on errors. The development environment is a conversation.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The human driving this has never written a line of Lisp. Not Common Lisp. Not Scheme. Not Clojure. Not Emacs Lisp. Has never opened the codebase in VS Code, vi, or any other editor. Every file was created and modified through " (a :href "https://claude.ai/" (~tw :tokens "text-violet-600 hover:underline") "Claude") " running in a terminal — reading files, writing files, running commands, iterating on errors. The development environment is a conversation.")
(p (~tw :tokens "text-stone-600")
"That this works at all is a testament to s-expressions. The AI generates " (code "(defcomp ~essays/sx-and-ai/card (&key title) (div :class \"p-4\" (h2 title)))") " and it is correct on the first attempt, because there is almost nothing to get wrong. The AI generates a 300-line spec file defining evaluator semantics and every parenthesis balances, because balancing parentheses is the " (em "only") " syntactic constraint. The AI writes a bootstrapper that reads " (code "eval.sx") " and emits JavaScript, and the output runs in the browser, because the source and target are both trees.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Try this with React. Try generating a complete component framework — parser, evaluator, renderer, type system, macro expander, CSS engine, client router — through pure conversation with an AI, never touching an editor. The syntax tax alone would be fatal. JSX irregularities, hook ordering rules, import resolution, TypeScript generics, webpack configuration, CSS module scoping — each is a class of errors that burns tokens and breaks the flow. S-expressions eliminate all of them."))
(~docs/section :title "The development loop" :id "dev-loop"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The workflow looks like this: describe what you want. The AI reads the existing code — because it can, because s-expressions are transparent to any reader. It generates new expressions. It writes them to disk. It runs the server. It checks the output. If something breaks, it reads the error, adjusts, and regenerates. The human steers with intent; the AI handles the syntax, the structure, and the mechanical correctness.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is only possible because the representation is uniform. The AI does not need to switch between \"writing HTML mode\" and \"writing CSS mode\" and \"writing JavaScript mode\" and \"writing deployment config mode.\" It is always writing s-expressions. The cognitive load is constant. The error rate is constant. The speed is constant — regardless of whether it is generating a page layout, a macro expander, or a Docker healthcheck.")
(p :class "text-stone-600"
"The " (a :href "/sx/(etc.(essay.sx-sucks))" :class "text-violet-600 hover:underline" "sx sucks") " essay copped to the AI authorship and framed it as a weakness — microwave dinner on a nice plate. But the framing was wrong. If a language is so well-suited to machine generation that one person with no Lisp experience can build a self-hosting language, a multi-target bootstrapper, a reactive component framework, and a full documentation site through pure agentic AI — that is not a weakness of the language. That is the language working exactly as it should."))
(p (~tw :tokens "text-stone-600")
"The " (a :href "/sx/(etc.(essay.sx-sucks))" (~tw :tokens "text-violet-600 hover:underline") "sx sucks") " essay copped to the AI authorship and framed it as a weakness — microwave dinner on a nice plate. But the framing was wrong. If a language is so well-suited to machine generation that one person with no Lisp experience can build a self-hosting language, a multi-target bootstrapper, a reactive component framework, and a full documentation site through pure agentic AI — that is not a weakness of the language. That is the language working exactly as it should."))
(~docs/section :title "What this changes" :id "what-changes"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The question is not whether AI will generate user interfaces. It already does. The question is what representation makes that generation most reliable, most efficient, and most safe. S-expressions — with their zero-syntax-tax grammar, uniform structure, self-describing components, structural validation, and sandboxed evaluation — are a strong answer.")
(p :class "text-stone-600"
"Not because they were designed for AI. " (a :href "https://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)" :class "text-violet-600 hover:underline" "McCarthy") " invented them in 1958, decades before anyone imagined language models. But the properties that make s-expressions elegant for humans — minimalism, uniformity, composability, homoiconicity — turn out to be exactly the properties that make them tractable for machines. The simplest possible syntax is also the most machine-friendly syntax. This is not a coincidence. It is a consequence of what simplicity means.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Not because they were designed for AI. " (a :href "https://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)" (~tw :tokens "text-violet-600 hover:underline") "McCarthy") " invented them in 1958, decades before anyone imagined language models. But the properties that make s-expressions elegant for humans — minimalism, uniformity, composability, homoiconicity — turn out to be exactly the properties that make them tractable for machines. The simplest possible syntax is also the most machine-friendly syntax. This is not a coincidence. It is a consequence of what simplicity means.")
(p (~tw :tokens "text-stone-600")
"The era of AI-generated software is not coming. It is here. The question is which representations survive contact with it. The ones with the lowest syntax tax, the most uniform structure, and the tightest feedback loops will win — not because they are trendy, but because they are what the machines can actually produce reliably. S-expressions have been waiting sixty-seven years for a generation mechanism worthy of their simplicity. They finally have one."))))

118
sx/sx/essays/sx-and-dennett.sx
View File

@@ -1,112 +1,112 @@
(defcomp ~essays/sx-and-dennett/essay-sx-and-dennett ()
(~docs/page :title "SX and Dennett"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"Real patterns, multiple drafts, and the intentional stance — a philosopher of mind meets a language that thinks about itself.")
(~docs/section :title "I. The intentional stance" :id "intentional-stance"
(p :class "text-stone-600"
"Daniel " (a :href "https://en.wikipedia.org/wiki/Daniel_Dennett" :class "text-violet-600 hover:underline" "Dennett") " spent fifty years arguing that the mind is not what it seems. His central method is the " (a :href "https://en.wikipedia.org/wiki/Intentional_stance" :class "text-violet-600 hover:underline" "intentional stance") " — a strategy for predicting a system's behaviour by treating it " (em "as if") " it has beliefs, desires, and intentions, whether or not it \"really\" does.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Daniel " (a :href "https://en.wikipedia.org/wiki/Daniel_Dennett" (~tw :tokens "text-violet-600 hover:underline") "Dennett") " spent fifty years arguing that the mind is not what it seems. His central method is the " (a :href "https://en.wikipedia.org/wiki/Intentional_stance" (~tw :tokens "text-violet-600 hover:underline") "intentional stance") " — a strategy for predicting a system's behaviour by treating it " (em "as if") " it has beliefs, desires, and intentions, whether or not it \"really\" does.")
(p (~tw :tokens "text-stone-600")
"There are three stances. The " (em "physical stance") " predicts from physics — voltage levels, transistor states, bytes in memory. The " (em "design stance") " predicts from how the thing was built — a thermostat turns on the heating when the temperature drops below the set point, regardless of its internal wiring. The " (em "intentional stance") " predicts from ascribed beliefs and goals — the chess program \"wants\" to protect its king, \"believes\" the centre is important.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Web frameworks enforce a single stance. React's mental model is the design stance: components are functions, props go in, JSX comes out. You reason about the system by reasoning about its design. If you need the physical stance (what is actually in the DOM right now?), you reach for " (code "useRef") ". If you need the intentional stance (what does this component " (em "mean") "?), you read the documentation. Each stance requires a different tool, a different context switch.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX lets you shift stances without shifting languages. The physical stance: " (code "(div :class \"card\" (h2 \"Title\"))") " — this is exactly the DOM structure that will be produced. One list, one element. The design stance: " (code "(defcomp ~essays/sx-and-dennett/card (&key title) (div title))") " — this is how the component is built, its contract. The intentional stance: " (code "(~essays/sx-and-dennett/card :title \"Hello\")") " — this " (em "means") " \"render a card with this title,\" and you can reason about it at that level without knowing the implementation.")
(~docs/code :lang "lisp" :code
";; Physical stance — the literal structure\n(div :class \"card\" (h2 \"Title\"))\n\n;; Design stance — how it's built\n(defcomp ~essays/sx-and-dennett/card (&key title) (div :class \"card\" (h2 title)))\n\n;; Intentional stance — what it means\n(~essays/sx-and-dennett/card :title \"Title\")\n\n;; All three are s-expressions.\n;; All three can be inspected, transformed, quoted.\n;; Shifting stance = changing which expression you look at.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The key insight: all three stances are expressed in the same medium. You do not need a debugger for the physical stance, a type system for the design stance, and documentation for the intentional stance. You need lists. The stances are not different tools — they are different ways of reading the same data."))
(~docs/section :title "II. Real patterns" :id "real-patterns"
(p :class "text-stone-600"
"Dennett's 1991 paper \"" (a :href "https://en.wikipedia.org/wiki/Real_Patterns" :class "text-violet-600 hover:underline" "Real Patterns") "\" makes a deceptively simple argument: a pattern is real if it lets you compress data — if recognising the pattern gives you predictive leverage that you would not have otherwise. Patterns are not " (em "in the mind") " of the observer. They are not " (em "in the object") " independently of any observer. They are real features of the world that exist at a particular level of description.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Dennett's 1991 paper \"" (a :href "https://en.wikipedia.org/wiki/Real_Patterns" (~tw :tokens "text-violet-600 hover:underline") "Real Patterns") "\" makes a deceptively simple argument: a pattern is real if it lets you compress data — if recognising the pattern gives you predictive leverage that you would not have otherwise. Patterns are not " (em "in the mind") " of the observer. They are not " (em "in the object") " independently of any observer. They are real features of the world that exist at a particular level of description.")
(p (~tw :tokens "text-stone-600")
"Consider a bitmap of noise. If you describe it pixel by pixel, the description is as long as the image. No compression. No pattern. Now consider a bitmap of a checkerboard. You can say \"alternating black and white squares, 8x8\" — vastly shorter than the pixel-by-pixel description. The checkerboard pattern is " (em "real") ". It exists in the data. Recognising it gives you compression.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Components are real patterns. " (code "(~essays/sx-and-dennett/card :title \"Hello\")") " compresses " (code "(div :class \"card\" (h2 \"Hello\"))") " — and more importantly, it compresses every instance of card-like structure across the application into a single abstraction. The component is not a convenient fiction. It is a real pattern in the codebase: a regularity that gives you predictive power. When you see " (code "~essays/sx-and-dennett/card") ", you know the structure, the styling, the contract — without expanding the definition.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Macros are real patterns at a higher level. A macro like " (code "defcomp") " captures the pattern of \"name, parameters, body\" that every component shares. It compresses the regularity of component definition itself. The macro is real in exactly Dennett's sense — it captures a genuine pattern, and that pattern gives you leverage.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Now here is where SX makes Dennett's argument concrete. In most languages, the reality of patterns is debatable — are classes real? Are interfaces real? Are design patterns real? You can argue either way because the patterns exist at a different level from the code. In SX, patterns " (em "are") " code. A component is a list. A macro is a function over lists. The pattern and the data it describes are the same kind of thing — s-expressions. There is no level-of-description gap. The pattern is as real as the data it compresses, because they inhabit the same ontological plane.")
(~docs/code :lang "lisp" :code
";; The data (expanded)\n(div :class \"card\"\n (h2 \"Pattern\")\n (p \"A real one.\"))\n\n;; The pattern (compressed)\n(~essays/sx-and-dennett/card :title \"Pattern\" (p \"A real one.\"))\n\n;; The meta-pattern (the definition)\n(defcomp ~essays/sx-and-dennett/card (&key title &rest children)\n (div :class \"card\" (h2 title) children))\n\n;; All three levels: data, pattern, meta-pattern.\n;; All three are lists. All three are real."))
(~docs/section :title "III. Multiple Drafts" :id "multiple-drafts"
(p :class "text-stone-600"
"In " (a :href "https://en.wikipedia.org/wiki/Consciousness_Explained" :class "text-violet-600 hover:underline" "Consciousness Explained") " (1991), Dennett proposed the " (a :href "https://en.wikipedia.org/wiki/Multiple_drafts_model" :class "text-violet-600 hover:underline" "Multiple Drafts model") " of consciousness. There is no " (a :href "https://en.wikipedia.org/wiki/Cartesian_theater" :class "text-violet-600 hover:underline" "Cartesian theater") " — no single place in the brain where \"it all comes together\" for a central observer. Instead, multiple parallel processes generate content simultaneously. Various drafts of narrative are in process at any time, some getting revised, some abandoned, some incorporated into the ongoing story. There is no master draft. There is no final audience. There is just the process of revision itself.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In " (a :href "https://en.wikipedia.org/wiki/Consciousness_Explained" (~tw :tokens "text-violet-600 hover:underline") "Consciousness Explained") " (1991), Dennett proposed the " (a :href "https://en.wikipedia.org/wiki/Multiple_drafts_model" (~tw :tokens "text-violet-600 hover:underline") "Multiple Drafts model") " of consciousness. There is no " (a :href "https://en.wikipedia.org/wiki/Cartesian_theater" (~tw :tokens "text-violet-600 hover:underline") "Cartesian theater") " — no single place in the brain where \"it all comes together\" for a central observer. Instead, multiple parallel processes generate content simultaneously. Various drafts of narrative are in process at any time, some getting revised, some abandoned, some incorporated into the ongoing story. There is no master draft. There is no final audience. There is just the process of revision itself.")
(p (~tw :tokens "text-stone-600")
"React is a Cartesian theater. The virtual DOM is the stage. Reconciliation is the moment where \"it all comes together\" — the single canonical comparison between what was and what should be. One tree diffs against another. One algorithm produces one patch. The entire UI passes through a single bottleneck. There is a master draft, and its name is " (code "ReactDOM.render") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX has no theater. There are multiple drafts, genuinely parallel, with no single canonical render:")
(ul :class "list-disc pl-6 space-y-1 text-stone-600"
(li (span :class "font-semibold" "Server draft") " — Python evaluates components into SX wire format. This is a draft: it contains component calls unexpanded, slots unfilled, decisions deferred.")
(li (span :class "font-semibold" "Wire draft") " — the SX source text transmitted over HTTP. It is a draft in transit — meaningful as text, interpretable by any reader, but not yet rendered.")
(li (span :class "font-semibold" "Client draft") " — JavaScript evaluates the wire format into DOM nodes. Another draft: the browser's layout engine will revise it further (CSS computation, reflow, paint).")
(li (span :class "font-semibold" "Interaction draft") " — the user clicks, the server produces new SX, the client patches the DOM. The revision process continues. No draft is final."))
(p :class "text-stone-600"
(ul (~tw :tokens "list-disc pl-6 space-y-1 text-stone-600")
(li (span (~tw :tokens "font-semibold") "Server draft") " — Python evaluates components into SX wire format. This is a draft: it contains component calls unexpanded, slots unfilled, decisions deferred.")
(li (span (~tw :tokens "font-semibold") "Wire draft") " — the SX source text transmitted over HTTP. It is a draft in transit — meaningful as text, interpretable by any reader, but not yet rendered.")
(li (span (~tw :tokens "font-semibold") "Client draft") " — JavaScript evaluates the wire format into DOM nodes. Another draft: the browser's layout engine will revise it further (CSS computation, reflow, paint).")
(li (span (~tw :tokens "font-semibold") "Interaction draft") " — the user clicks, the server produces new SX, the client patches the DOM. The revision process continues. No draft is final."))
(p (~tw :tokens "text-stone-600")
"Each draft is a complete s-expression. Each is meaningful on its own terms. No single process \"sees\" the whole page — the server doesn't see the DOM, the client doesn't see the Python context, the browser's layout engine doesn't see the s-expressions. The page emerges from the drafting process, not from a central reconciler.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a metaphor stretched over engineering. It is the actual architecture. There is no virtual DOM because there is no need for a Cartesian theater. The multiple drafts model works because each draft is in the same format — s-expressions — so revision is natural. A draft can be inspected, compared, serialised, sent somewhere else, and revised further. Dennett's insight was that consciousness works this way. SX's insight is that rendering can too."))
(~docs/section :title "IV. Heterophenomenology" :id "heterophenomenology"
(p :class "text-stone-600"
(a :href "https://en.wikipedia.org/wiki/Heterophenomenology" :class "text-violet-600 hover:underline" "Heterophenomenology") " is Dennett's method for studying consciousness. Instead of asking \"what is it like to be a bat?\" — a question we cannot answer — we ask the bat to tell us, and then we study " (em "the report") ". We take the subject's testimony seriously, catalogue it rigorously, but we do not take it as infallible. The report is data. We are scientists of the report.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(a :href "https://en.wikipedia.org/wiki/Heterophenomenology" (~tw :tokens "text-violet-600 hover:underline") "Heterophenomenology") " is Dennett's method for studying consciousness. Instead of asking \"what is it like to be a bat?\" — a question we cannot answer — we ask the bat to tell us, and then we study " (em "the report") ". We take the subject's testimony seriously, catalogue it rigorously, but we do not take it as infallible. The report is data. We are scientists of the report.")
(p (~tw :tokens "text-stone-600")
"Most programming languages cannot report on themselves. JavaScript can " (code "toString()") " a function, but the result is a string — opaque, unparseable, implementation-dependent. Python can inspect a function's AST via " (code "ast.parse(inspect.getsource(f))") " — but the AST is a separate data structure, disconnected from the running code. The language's self-report is in a different format from the language itself. Studying it requires tools, transformations, bridges.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX is natively heterophenomenological. The language's self-report " (em "is") " the language. " (code "eval.sx") " is the evaluator reporting on how evaluation works — in the same s-expressions that it evaluates. " (code "parser.sx") " is the parser reporting on how parsing works — in the same syntax it parses. You study the report by reading it. You verify the report by running it. The report and the reality are the same object.")
(~docs/code :lang "lisp" :code
";; The evaluator's self-report (from eval.sx):\n(define eval-expr\n (fn (expr env)\n (cond\n (number? expr) expr\n (string? expr) expr\n (symbol? expr) (env-get env expr)\n (list? expr) (eval-list expr env)\n :else (error \"Unknown expression type\"))))\n\n;; This is simultaneously:\n;; 1. A specification (what eval-expr does)\n;; 2. A program (it runs)\n;; 3. A report (the evaluator describing itself)\n;; Heterophenomenology without the hetero.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Dennett insisted that heterophenomenology is the only honest method. First-person reports are unreliable — introspection gets things wrong. Third-person observation misses the subject's perspective. The middle path is to take the report as data and study it rigorously. SX's self-hosting spec is this middle path enacted in code: neither a first-person account (\"trust me, this is how it works\") nor a third-person observation (English prose describing the implementation), but a structured report that can be verified, compiled, and run."))
(~docs/section :title "V. Where am I?" :id "where-am-i"
(p :class "text-stone-600"
"Dennett's thought experiment \"" (a :href "https://en.wikipedia.org/wiki/Where_Am_I%3F_(Dennett)" :class "text-violet-600 hover:underline" "Where Am I?") "\" imagines his brain removed from his body, connected by radio. His body walks around; his brain sits in a vat. Where is Dennett? Where the brain is? Where the body is? The question has no clean answer because identity is not located in a single place — it is distributed across the system.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Dennett's thought experiment \"" (a :href "https://en.wikipedia.org/wiki/Where_Am_I%3F_(Dennett)" (~tw :tokens "text-violet-600 hover:underline") "Where Am I?") "\" imagines his brain removed from his body, connected by radio. His body walks around; his brain sits in a vat. Where is Dennett? Where the brain is? Where the body is? The question has no clean answer because identity is not located in a single place — it is distributed across the system.")
(p (~tw :tokens "text-stone-600")
"Where is an SX component? On the server, it is a Python object — a closure with a body and bound environment. On the wire, it is text: " (code "(~essays/sx-and-dennett/card :title \"Hello\")") ". In the browser, it is a JavaScript function registered in the component environment. In the DOM, it is a tree of elements. Which one is the \"real\" component? All of them. None of them. The component is not located in one runtime — it is the pattern that persists across all of them.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is Dennett's point about personal identity applied to software identity. The SX component " (code "~essays/sx-and-dennett/card") " is defined in a " (code ".sx") " file, compiled by the Python bootstrapper into the server evaluator, transmitted as SX wire format to the browser, compiled by the JavaScript bootstrapper into the client evaluator, and rendered into DOM. At every stage, it is " (code "~essays/sx-and-dennett/card") ". At no single stage is it " (em "the") " " (code "~essays/sx-and-dennett/card") ". The identity is the pattern, not the substrate.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Most frameworks bind component identity to a substrate. A React component is a JavaScript function. Full stop. It cannot exist outside the JavaScript runtime. Its identity is its implementation. SX components have substrate independence — the same definition runs on any host that implements the SX platform interface. The component's identity is its specification, not its execution."))
(~docs/section :title "VI. Competence without comprehension" :id "competence"
(p :class "text-stone-600"
"Dennett argued in " (a :href "https://en.wikipedia.org/wiki/From_Bacteria_to_Bach_and_Back" :class "text-violet-600 hover:underline" "From Bacteria to Bach and Back") " (2017) that evolution produces " (em "competence without comprehension") ". Termites build elaborate mounds without understanding architecture. Neurons produce consciousness without understanding thought. The competence is real — the mound regulates temperature, the brain solves problems — but there is no comprehension anywhere in the system. No termite has a blueprint. No neuron knows it is thinking.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Dennett argued in " (a :href "https://en.wikipedia.org/wiki/From_Bacteria_to_Bach_and_Back" (~tw :tokens "text-violet-600 hover:underline") "From Bacteria to Bach and Back") " (2017) that evolution produces " (em "competence without comprehension") ". Termites build elaborate mounds without understanding architecture. Neurons produce consciousness without understanding thought. The competence is real — the mound regulates temperature, the brain solves problems — but there is no comprehension anywhere in the system. No termite has a blueprint. No neuron knows it is thinking.")
(p (~tw :tokens "text-stone-600")
"A macro is competence without comprehension. " (code "defcomp") " expands into a component registration — it " (em "does") " the right thing — but it does not \"know\" what a component is. It is a pattern-matching function on lists that produces other lists. The expansion is mechanical, local, uncomprehending. Yet the result is a fully functional component that participates in the rendering pipeline, responds to props, composes with other components. Competence. No comprehension.")
(~docs/code :lang "lisp" :code
";; defcomp is a macro — mechanical list transformation\n(defmacro defcomp (name params &rest body)\n `(define ,name (make-component ,params ,@body)))\n\n;; It does not \"understand\" components.\n;; It rearranges symbols according to a rule.\n;; The resulting component works perfectly.\n;; Competence without comprehension.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The bootstrap compiler is another level of the same phenomenon. " (code "bootstrap_js.py") " reads " (code "eval.sx") " and emits JavaScript. It does not understand SX semantics — it applies mechanical transformation rules to s-expression ASTs. Yet its output is a correct, complete SX evaluator. The compiler is competent (it produces working code) without being comprehending (it has no model of what SX expressions mean).")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Dennett used this insight to deflate the mystery of intelligence: you do not need a homunculus — a little man inside the machine who \"really\" understands — you just need enough competence at each level. SX embodies this architecturally. No part of the system comprehends the whole. The parser does not know about rendering. The evaluator does not know about HTTP. The bootstrap compiler does not know about the DOM. Each part is a competent specialist. The system works because the parts compose, not because any part understands the composition."))
(~docs/section :title "VII. Intuition pumps" :id "intuition-pumps"
(p :class "text-stone-600"
"Dennett called his thought experiments \"" (a :href "https://en.wikipedia.org/wiki/Intuition_pump" :class "text-violet-600 hover:underline" "intuition pumps") "\" — devices for moving your intuitions from one place to another, making the unfamiliar familiar by analogy. Not proofs. Not arguments. Machines for changing how you see.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Dennett called his thought experiments \"" (a :href "https://en.wikipedia.org/wiki/Intuition_pump" (~tw :tokens "text-violet-600 hover:underline") "intuition pumps") "\" — devices for moving your intuitions from one place to another, making the unfamiliar familiar by analogy. Not proofs. Not arguments. Machines for changing how you see.")
(p (~tw :tokens "text-stone-600")
"SX components are intuition pumps. A " (code "defcomp") " definition is not just executable code — it is a device for showing someone what a piece of UI " (em "is") ". Reading " (code "(defcomp ~essays/sx-and-dennett/card (&key title &rest children) (div :class \"card\" (h2 title) children))") " tells you the contract, the structure, and the output in a single expression. It pumps your intuition about what \"card\" means in this application.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Compare this to a React component:")
(~docs/code :lang "lisp" :code
";; React: you must simulate the runtime in your head\nfunction Card({ title, children }) {\n return (\n <div className=\"card\">\n <h2>{title}</h2>\n {children}\n </div>\n );\n}\n\n;; SX: the definition IS the output\n(defcomp ~essays/sx-and-dennett/card (&key title &rest children)\n (div :class \"card\"\n (h2 title)\n children))")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The React version requires you to know that JSX compiles to createElement calls, that className maps to the class attribute, that curly braces switch to JavaScript expressions, and that the function return value becomes the rendered output. You must simulate a compiler in your head. The SX version requires you to know that lists are expressions and keywords are attributes. The gap between the definition and what it produces is smaller. The intuition pump is more efficient — fewer moving parts, less machinery between the reader and the meaning.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Dennett valued intuition pumps because philosophy is full of false intuitions. The Cartesian theater feels right — of course there is a place where consciousness happens. But it is wrong. Intuition pumps help you " (em "see") " that it is wrong by giving you a better picture. SX is an intuition pump for web development: of course you need a build step, of course you need a virtual DOM, of course you need separate languages for structure and style and behaviour. But you don't. The s-expression is the better picture."))
(~docs/section :title "VIII. The Joycean machine" :id "joycean-machine"
(p :class "text-stone-600"
"In Consciousness Explained, Dennett describes the brain as a \"" (a :href "https://en.wikipedia.org/wiki/Consciousness_Explained" :class "text-violet-600 hover:underline" "Joycean machine") "\" — a virtual machine running on the parallel hardware of the brain, producing the serial narrative of conscious experience. Just as a word processor is a virtual machine running on silicon, consciousness is a virtual machine running on neurons. The virtual machine is real — it does real work, produces real effects — even though it is implemented in a substrate that knows nothing about it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In Consciousness Explained, Dennett describes the brain as a \"" (a :href "https://en.wikipedia.org/wiki/Consciousness_Explained" (~tw :tokens "text-violet-600 hover:underline") "Joycean machine") "\" — a virtual machine running on the parallel hardware of the brain, producing the serial narrative of conscious experience. Just as a word processor is a virtual machine running on silicon, consciousness is a virtual machine running on neurons. The virtual machine is real — it does real work, produces real effects — even though it is implemented in a substrate that knows nothing about it.")
(p (~tw :tokens "text-stone-600")
"SX is a Joycean machine running on the web. The web's substrate — TCP/IP, HTTP, the DOM, JavaScript engines — knows nothing about s-expressions, components, or evaluators. Yet the SX virtual machine runs on this substrate, producing real pages, real interactions, real applications. The substrate provides the physical-stance machinery. SX provides the intentional-stance narrative: this is a card, this is a page, this is a layout, this composes with that.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The deeper parallel: Dennett argued that the Joycean machine is " (em "not an illusion") ". The serial narrative of consciousness is not fake — it is the real output of real processing, even though the underlying hardware is parallel and narrativeless. Similarly, SX's component model is not a convenient fiction layered over \"real\" HTML. It is the real structure of the application. The components are the thing. The HTML is the substrate, not the reality.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"And like Dennett's Joycean machine, SX's virtual machine can reflect on itself. It can inspect its own running code, define its own evaluator, test its own semantics. The virtual machine is aware of itself — not in the sense of consciousness, but in the functional sense of self-modelling. The spec models the evaluator. The evaluator runs the spec. The virtual machine contains a description of itself, and that description works."))
(~docs/section :title "IX. Quining" :id "quining"
(p :class "text-stone-600"
"Dennett borrowed the term \"" (a :href "https://en.wikipedia.org/wiki/Qualia#Dennett's_criticism" :class "text-violet-600 hover:underline" "quining") "\" from the logician " (a :href "https://en.wikipedia.org/wiki/Willard_Van_Orman_Quine" :class "text-violet-600 hover:underline" "W. V. O. Quine") " — a philosopher who argued that many seemingly deep concepts dissolve under scrutiny. Dennett \"quined\" qualia — the supposedly irreducible subjective qualities of experience — arguing that they are not what they seem, that the intuition of an inner experiential essence is a philosophical illusion.")
(p :class "text-stone-600"
"The concept of a \"" (a :href "https://en.wikipedia.org/wiki/Quine_(computing)" :class "text-violet-600 hover:underline" "quine") "\" in computing is related: a program that outputs its own source code. The word honours the same Quine, for the same reason — self-reference that collapses the distinction between describer and described.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Dennett borrowed the term \"" (a :href "https://en.wikipedia.org/wiki/Qualia#Dennett's_criticism" (~tw :tokens "text-violet-600 hover:underline") "quining") "\" from the logician " (a :href "https://en.wikipedia.org/wiki/Willard_Van_Orman_Quine" (~tw :tokens "text-violet-600 hover:underline") "W. V. O. Quine") " — a philosopher who argued that many seemingly deep concepts dissolve under scrutiny. Dennett \"quined\" qualia — the supposedly irreducible subjective qualities of experience — arguing that they are not what they seem, that the intuition of an inner experiential essence is a philosophical illusion.")
(p (~tw :tokens "text-stone-600")
"The concept of a \"" (a :href "https://en.wikipedia.org/wiki/Quine_(computing)" (~tw :tokens "text-violet-600 hover:underline") "quine") "\" in computing is related: a program that outputs its own source code. The word honours the same Quine, for the same reason — self-reference that collapses the distinction between describer and described.")
(p (~tw :tokens "text-stone-600")
"SX quines in both senses. In the computing sense: the self-hosting spec is a quine-like structure — " (code "eval.sx") " is an SX program that, when compiled and run, produces an evaluator capable of running " (code "eval.sx") ". It is not a literal quine (it doesn't output itself character-for-character), but it has the essential quine property: the output contains the input.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In Dennett's philosophical sense: SX quines the web's qualia. The supposedly irreducible essences of web development — \"components,\" \"state,\" \"the DOM,\" \"the server-client boundary\" — dissolve under SX's scrutiny into what they always were: data structures. Lists of symbols. Expressions that evaluate to other expressions. The qualia of web development are not irreducible. They are patterns in s-expressions, and once you see that, you cannot unsee it.")
(p :class "text-stone-600"
"Dennett's lifelong project was to show that the mind is not what our intuitions say it is — that consciousness, free will, and the self are real phenomena that do not require the metaphysical foundations we instinctively assign them. They are " (a :href "https://en.wikipedia.org/wiki/Real_Patterns" :class "text-violet-600 hover:underline" "real patterns") " in physical processes, not ghostly essences hovering above matter.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Dennett's lifelong project was to show that the mind is not what our intuitions say it is — that consciousness, free will, and the self are real phenomena that do not require the metaphysical foundations we instinctively assign them. They are " (a :href "https://en.wikipedia.org/wiki/Real_Patterns" (~tw :tokens "text-violet-600 hover:underline") "real patterns") " in physical processes, not ghostly essences hovering above matter.")
(p (~tw :tokens "text-stone-600")
"SX makes the same move for the web. Components are real patterns, not framework essences. The server-client boundary is a draft boundary, not an ontological divide. The build step is a habit, not a necessity. The virtual DOM is a Cartesian theater, not a requirement. Strip away the false intuitions, and what remains is what was always there: expressions, evaluation, and composition. All the way down."))))

96
sx/sx/essays/sx-and-wittgenstein.sx
View File

@@ -1,93 +1,93 @@
(defcomp ~essays/sx-and-wittgenstein/essay-sx-and-wittgenstein ()
(~docs/page :title "SX and Wittgenstein"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"The limits of my language are the limits of my world.")
(~docs/section :title "I. Language games" :id "language-games"
(p :class "text-stone-600"
"In 1953, Ludwig " (a :href "https://en.wikipedia.org/wiki/Ludwig_Wittgenstein" :class "text-violet-600 hover:underline" "Wittgenstein") " published " (a :href "https://en.wikipedia.org/wiki/Philosophical_Investigations" :class "text-violet-600 hover:underline" "Philosophical Investigations") " — a book that dismantled the theory of language he had built in his own earlier work. The " (a :href "https://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus" :class "text-violet-600 hover:underline" "Tractatus") " had argued that language pictures the world: propositions mirror facts, and the structure of a sentence corresponds to the structure of reality. The Investigations abandoned this. Language does not picture anything. Language is " (em "used") ".")
(p :class "text-stone-600"
"Wittgenstein replaced the picture theory with " (a :href "https://en.wikipedia.org/wiki/Language_game_(philosophy)" :class "text-violet-600 hover:underline" "language games") " — activities in which words get their meaning from how they are employed, not from what they refer to. \"Slab!\" on a building site means \"bring me a slab.\" The same word in a dictionary means nothing until it enters a game. Meaning is use.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In 1953, Ludwig " (a :href "https://en.wikipedia.org/wiki/Ludwig_Wittgenstein" (~tw :tokens "text-violet-600 hover:underline") "Wittgenstein") " published " (a :href "https://en.wikipedia.org/wiki/Philosophical_Investigations" (~tw :tokens "text-violet-600 hover:underline") "Philosophical Investigations") " — a book that dismantled the theory of language he had built in his own earlier work. The " (a :href "https://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus" (~tw :tokens "text-violet-600 hover:underline") "Tractatus") " had argued that language pictures the world: propositions mirror facts, and the structure of a sentence corresponds to the structure of reality. The Investigations abandoned this. Language does not picture anything. Language is " (em "used") ".")
(p (~tw :tokens "text-stone-600")
"Wittgenstein replaced the picture theory with " (a :href "https://en.wikipedia.org/wiki/Language_game_(philosophy)" (~tw :tokens "text-violet-600 hover:underline") "language games") " — activities in which words get their meaning from how they are employed, not from what they refer to. \"Slab!\" on a building site means \"bring me a slab.\" The same word in a dictionary means nothing until it enters a game. Meaning is use.")
(p (~tw :tokens "text-stone-600")
"Web development is a proliferation of language games. HTML is one game — a markup game where tags denote structure. CSS is another — a declaration game where selectors denote style. JavaScript is a third — an imperative game where statements denote behaviour. JSX is a fourth game layered on top of the third, pretending to be the first. TypeScript is a fifth game that annotates the third. Each has its own grammar, its own rules, its own way of meaning.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX collapses these into a single game. " (code "(div :class \"p-4\" (h2 title))") " is simultaneously structure (a div containing an h2), style (the class attribute), and behaviour (the symbol " (code "title") " is evaluated). There is one syntax, one set of rules, one way of meaning. Not because the distinctions between structure, style, and behaviour have been erased — they haven't — but because they are all expressed in the same language game."))
(~docs/section :title "II. The limits of my language" :id "limits"
(p :class "text-stone-600"
"\"" (a :href "https://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus" :class "text-violet-600 hover:underline" "Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt") "\" — the limits of my language mean the limits of my world. This is proposition 5.6 of the Tractatus, and it is the most important sentence Wittgenstein ever wrote.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"\"" (a :href "https://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus" (~tw :tokens "text-violet-600 hover:underline") "Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt") "\" — the limits of my language mean the limits of my world. This is proposition 5.6 of the Tractatus, and it is the most important sentence Wittgenstein ever wrote.")
(p (~tw :tokens "text-stone-600")
"If your language is HTML, your world is documents. You can link documents. You can nest elements inside documents. You cannot compose documents from smaller documents without a server-side include, an iframe, or JavaScript. The language does not have composition, so your world does not have composition.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"If your language is React, your world is components that re-render. You can compose components. You can pass props. You cannot inspect a component's structure at runtime without React DevTools. You cannot serialize a component tree to a format another framework can consume. You cannot send a component over HTTP and have it work on the other side without the same React runtime. The language has composition but not portability, so your world has composition but not portability.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"If your language is s-expressions, your world is " (em "expressions") ". An expression can represent a DOM node, a function call, a style declaration, a macro transformation, a component definition, a wire-format payload, or a specification of the evaluator itself. The language has no built-in limits on what can be expressed, because the syntax — the list — can represent anything. The limits of the language are only the limits of what you choose to evaluate.")
(~docs/code :lang "lisp" :code
";; The same syntax expresses everything:\n(div :class \"card\" (h2 \"Title\")) ;; structure\n(css :flex :gap-4 :p-2) ;; style\n(defcomp ~essays/sx-and-wittgenstein/card (&key title) (div title)) ;; abstraction\n(defmacro ~log (x) `(console.log ,x)) ;; metaprogramming\n(quote (div :class \"card\" (h2 \"Title\"))) ;; data about structure")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Wittgenstein's proposition cuts both ways. A language that limits you to documents limits your world to documents. A language that can express anything — because its syntax is the minimal recursive structure — limits your world to " (em "everything") "."))
(~docs/section :title "III. Whereof one cannot speak" :id "silence"
(p :class "text-stone-600"
"The Tractatus ends: \"" (a :href "https://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus#Proposition_7" :class "text-violet-600 hover:underline" "Whereof one cannot speak, thereof one must be silent") ".\" Proposition 7. The things that cannot be said in a language simply do not exist within that language's world.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The Tractatus ends: \"" (a :href "https://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus#Proposition_7" (~tw :tokens "text-violet-600 hover:underline") "Whereof one cannot speak, thereof one must be silent") ".\" Proposition 7. The things that cannot be said in a language simply do not exist within that language's world.")
(p (~tw :tokens "text-stone-600")
"HTML cannot speak of composition. It is silent on components. You cannot define " (code "~essays/sx-and-wittgenstein/card") " in HTML. You can define " (code "<template>") " and " (code "<slot>") " in Web Components, but that requires JavaScript — you have left HTML's language game and entered another.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"CSS cannot speak of conditions. It is silent on logic. You cannot say \"if the user is logged in, use this colour.\" You can use " (code ":has()") " and " (code "@container") " queries, but these are conditions about " (em "the document") ", not conditions about " (em "the application") ". CSS can only speak of what CSS can see.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"JavaScript can speak of almost everything — but it speaks in statements, not expressions. The difference matters. A statement executes and is gone. An expression evaluates to a value. Values compose. Statements require sequencing. React discovered this when it moved from class components (imperative, statement-oriented) to hooks (closer to expressions, but not quite — hence the rules of hooks).")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"S-expressions are pure expression. Every form evaluates to a value. There is nothing that cannot be spoken, because lists can nest arbitrarily and symbols can name anything. There is no proposition 7 for s-expressions — no enforced silence, no boundary where the language gives out. The programmer decides where to draw the line, not the syntax."))
(~docs/section :title "IV. Family resemblance" :id "family-resemblance"
(p :class "text-stone-600"
"Wittgenstein argued that concepts do not have sharp definitions. What is a \"" (a :href "https://en.wikipedia.org/wiki/Family_resemblance" :class "text-violet-600 hover:underline" "game") "\"? Chess, football, solitaire, ring-a-ring-o'-roses — they share no single essential feature. Instead, they form a network of overlapping similarities. A " (a :href "https://en.wikipedia.org/wiki/Family_resemblance" :class "text-violet-600 hover:underline" "family resemblance") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Wittgenstein argued that concepts do not have sharp definitions. What is a \"" (a :href "https://en.wikipedia.org/wiki/Family_resemblance" (~tw :tokens "text-violet-600 hover:underline") "game") "\"? Chess, football, solitaire, ring-a-ring-o'-roses — they share no single essential feature. Instead, they form a network of overlapping similarities. A " (a :href "https://en.wikipedia.org/wiki/Family_resemblance" (~tw :tokens "text-violet-600 hover:underline") "family resemblance") ".")
(p (~tw :tokens "text-stone-600")
"Web frameworks have this property. What is a \"component\"? In React, it is a function that returns JSX. In Vue, it is an object with a template property. In Svelte, it is a " (code ".svelte") " file. In Web Components, it is a class that extends HTMLElement. In Angular, it is a TypeScript class with a decorator. These are not the same thing. They share a family resemblance — they all produce reusable UI — but their definitions are incompatible. A React component cannot be used in Vue. A Svelte component cannot be used in Angular. The family does not communicate.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In SX, a component is a list whose first element is a symbol beginning with " (code "~") ". That is the complete definition. It is not a function, not a class, not a file, not a decorator. It is a " (em "naming convention on a data structure") ". Any system that can process lists can process SX components. Python evaluates them on the server. JavaScript evaluates them in the browser. A future Rust evaluator could evaluate them on an embedded device. The family resemblance sharpens into actual identity: a component is a component is a component, because the representation is the same everywhere.")
(~docs/code :lang "lisp" :code
";; This is a component in every SX evaluator:\n(defcomp ~essays/sx-and-wittgenstein/greeting (&key name)\n (div :class \"p-4\"\n (h2 (str \"Hello, \" name))))\n\n;; The same s-expression is:\n;; - parsed by the same parser\n;; - evaluated by the same eval rules\n;; - rendered by the same render spec\n;; - on every host, in every context"))
(~docs/section :title "V. Private language" :id "private-language"
(p :class "text-stone-600"
"The " (a :href "https://en.wikipedia.org/wiki/Private_language_argument" :class "text-violet-600 hover:underline" "private language argument") " is one of Wittgenstein's most provocative claims: there can be no language whose words refer to the speaker's private sensations and nothing else. Language requires public criteria — shared rules that others can check. A word that means something only to you is not a word at all.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The " (a :href "https://en.wikipedia.org/wiki/Private_language_argument" (~tw :tokens "text-violet-600 hover:underline") "private language argument") " is one of Wittgenstein's most provocative claims: there can be no language whose words refer to the speaker's private sensations and nothing else. Language requires public criteria — shared rules that others can check. A word that means something only to you is not a word at all.")
(p (~tw :tokens "text-stone-600")
"Most web frameworks are private languages. React's JSX is meaningful only to the React runtime. Vue's " (code ".vue") " single-file components are meaningful only to the Vue compiler. Svelte's " (code ".svelte") " files are meaningful only to the Svelte compiler. Each framework speaks a language that no one else can understand. They are private languages in Wittgenstein's sense — their terms have meaning only within their own closed world.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"S-expressions are radically public. The syntax is universal: open paren, atoms, close paren. Any Lisp, any s-expression processor, any JSON-to-sexp converter can read them. The SX evaluator adds meaning — " (code "defcomp") ", " (code "defmacro") ", " (code "if") ", " (code "let") " — but these meanings are specified in s-expressions themselves (" (code "eval.sx") "), readable by anyone. There is no private knowledge. There is no compilation step that transforms the public syntax into a private intermediate form. The source is the artefact.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is why SX can be self-hosting. A private language cannot define itself — it would need a second private language to define the first, and a third to define the second. A public language, one whose rules are expressible in its own terms, can close the loop. " (code "eval.sx") " defines SX in SX. The language defines itself publicly, in a form that any reader can inspect."))
(~docs/section :title "VI. Showing and saying" :id "showing-saying"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The Tractatus makes a crucial distinction between what can be " (em "said") " and what can only be " (em "shown") ". Logic, Wittgenstein argued, cannot be said — it can only be shown by the structure of propositions. You cannot step outside logic to make statements about logic; you can only exhibit logical structure by using it.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Most languages " (em "say") " their semantics — in English-language specifications, in RFC documents, in MDN pages. The semantics are described " (em "about") " the language, in a different medium.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX " (em "shows") " its semantics. The specification is not a description of the language — it is the language operating on itself. " (code "eval.sx") " does not say \"the evaluator dispatches on the type of expression.\" It " (em "is") " an evaluator that dispatches on the type of expression. " (code "parser.sx") " does not say \"strings are delimited by double quotes.\" It " (em "is") " a parser that recognises double-quoted strings.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is exactly the distinction Wittgenstein drew. What can be said (described, documented, specified in English) is limited. What can be shown (exhibited, demonstrated, enacted) goes further. SX's self-hosting spec shows its semantics by " (em "being") " them — the strongest form of specification possible. The spec cannot be wrong, because the spec runs."))
(~docs/section :title "VII. The beetle in the box" :id "beetle"
(p :class "text-stone-600"
"Wittgenstein's " (a :href "https://en.wikipedia.org/wiki/Private_language_argument#The_beetle_in_a_box" :class "text-violet-600 hover:underline" "beetle-in-a-box") " thought experiment: suppose everyone has a box, and everyone calls what's inside their box a \"beetle.\" No one can look in anyone else's box. The word \"beetle\" refers to whatever is in the box — but since no one can check, the contents might be different for each person, or the box might even be empty. The word gets its meaning from the " (em "game") " it plays in public, not from the private contents of the box.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Wittgenstein's " (a :href "https://en.wikipedia.org/wiki/Private_language_argument#The_beetle_in_a_box" (~tw :tokens "text-violet-600 hover:underline") "beetle-in-a-box") " thought experiment: suppose everyone has a box, and everyone calls what's inside their box a \"beetle.\" No one can look in anyone else's box. The word \"beetle\" refers to whatever is in the box — but since no one can check, the contents might be different for each person, or the box might even be empty. The word gets its meaning from the " (em "game") " it plays in public, not from the private contents of the box.")
(p (~tw :tokens "text-stone-600")
"A web component is a beetle in a box. You call it " (code "<my-button>") " but what's inside — Shadow DOM, event listeners, internal state, style encapsulation — is private. Two components with the same tag name might do completely different things. Two frameworks with the same concept of \"component\" might mean completely different things by it. The word \"component\" functions in the language game of developer conversation, but the actual contents are private to each implementation.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"In SX, you can open the box. Components are data. " (code "(defcomp ~essays/sx-and-wittgenstein/card (&key title) (div title))") " — the entire definition is visible, inspectable, serializable. There is no shadow DOM, no hidden state machine, no encapsulated runtime. The component's body is an s-expression. You can quote it, transform it, analyse it, send it over HTTP, evaluate it in a different context. The beetle is on the table."))
(~docs/section :title "VIII. The fly-bottle" :id "fly-bottle"
(p :class "text-stone-600"
"\"What is your aim in philosophy?\" Wittgenstein was asked. \"" (a :href "https://en.wikipedia.org/wiki/Philosophical_Investigations#Meaning_and_definition" :class "text-violet-600 hover:underline" "To show the fly the way out of the fly-bottle") ".\"")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"\"What is your aim in philosophy?\" Wittgenstein was asked. \"" (a :href "https://en.wikipedia.org/wiki/Philosophical_Investigations#Meaning_and_definition" (~tw :tokens "text-violet-600 hover:underline") "To show the fly the way out of the fly-bottle") ".\"")
(p (~tw :tokens "text-stone-600")
"The fly-bottle is the trap of false problems — questions that seem deep but are actually artefacts of confused language. \"What is the virtual DOM?\" is a fly-bottle question. The virtual DOM exists because React needed a way to reconcile its component model with the browser's DOM. If your component model " (em "is") " the DOM — if components evaluate directly to DOM nodes, as they do in SX — the question dissolves. There is no virtual DOM because there is no gap between the component and what it produces.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"\"How do we solve CSS scoping?\" Fly-bottle. CSS scoping is a problem because CSS is a global language applied to a local context. If styles are expressions evaluated in the same scope as the component that uses them — as in SX's CSSX — there is nothing to scope. The problem was created by the language separation, not by the nature of styling.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"\"How do we share state between server and client?\" Fly-bottle. This is hard when the server speaks one language (Python templates) and the client speaks another (JavaScript). When both speak s-expressions, and the wire format IS the source syntax, state transfer is serialisation — which is identity for s-expressions. " (code "aser") " serialises an SX expression as an SX expression. The server and client share state by sharing code.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX does not solve these problems. It dissolves them — by removing the language confusion that created them. Wittgenstein's method, applied to web development: the problems were never real. They were artefacts of speaking in the wrong language."))
(~docs/section :title "IX. Back to rough ground" :id "rough-ground"
(p :class "text-stone-600"
"\"We have got on to slippery ice where there is no friction and so in a certain sense the conditions are ideal, but also, just because of that, we are unable to walk. We want to walk: so we need " (a :href "https://en.wikipedia.org/wiki/Philosophical_Investigations" :class "text-violet-600 hover:underline" "friction") ". Back to the rough ground!\"")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"\"We have got on to slippery ice where there is no friction and so in a certain sense the conditions are ideal, but also, just because of that, we are unable to walk. We want to walk: so we need " (a :href "https://en.wikipedia.org/wiki/Philosophical_Investigations" (~tw :tokens "text-violet-600 hover:underline") "friction") ". Back to the rough ground!\"")
(p (~tw :tokens "text-stone-600")
"The slippery ice is the idealised abstraction — the framework that promises a perfect developer experience, the type system that promises to catch all bugs, the architecture diagram that promises clean separation. These are frictionless surfaces. They look beautiful. You cannot walk on them.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX is rough ground. S-expressions are not pretty. Parentheses are friction. There is no syntax highlighting tuned for this. There is no IDE with SX autocomplete. There is no build system to smooth over rough edges because there is no build system. You write s-expressions. You evaluate them. You see the result. The feedback loop is immediate and unmediated.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is a feature. Friction is how you know you are touching the ground. Friction is where the work happens. The perfectly frictionless framework lets you get started in five minutes and spend six months debugging its abstractions. SX asks you to understand s-expressions — a syntax that has not changed since 1958 — and then gives you the entire web as your world.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Wittgenstein wanted philosophy to stop theorising and start looking at how language actually works. SX wants web development to stop abstracting and start looking at what expressions actually are. Lists. Symbols. Evaluation. Composition. Everything else is a fly-bottle."))))

2
sx/sx/essays/sx-manifesto.sx
View File

File diff suppressed because one or more lines are too long

2
sx/sx/essays/sx-native.sx
View File

File diff suppressed because one or more lines are too long

2
sx/sx/essays/sx-sucks.sx
View File

@@ -1,2 +1,2 @@
(defcomp ~essays/sx-sucks/essay-sx-sucks ()
(~docs/page :title "sx sucks" (~docs/section :title "The parentheses" :id "parens" (p :class "text-stone-600" "S-expressions are parentheses. Lots of parentheses. You thought LISP was dead? No, someone just decided to use it for HTML templates. Your IDE will need a parenthesis counter. Your code reviews will be 40% closing parens. Every merge conflict will be about whether a paren belongs on this line or the next.")) (~docs/section :title "Nobody asked for this" :id "nobody-asked" (p :class "text-stone-600" "The JavaScript ecosystem has React, Vue, Svelte, Solid, Qwik, and approximately 47,000 other frameworks. htmx proved you can skip them all. sx looked at this landscape and said: you know what this needs? A Lisp dialect. For HTML. Over HTTP.") (p :class "text-stone-600" "Nobody was asking for this. The zero GitHub stars confirm it. It is not even on GitHub.")) (~docs/section :title "The author has never written a line of LISP" :id "no-lisp" (p :class "text-stone-600" "The author of sx has never written a single line of actual LISP. Not Common Lisp. Not Scheme. Not Clojure. Not even Emacs Lisp. The entire s-expression evaluator was written by someone whose mental model of LISP comes from reading the first three chapters of SICP and then closing the tab.") (p :class "text-stone-600" "This is like building a sushi restaurant when your only experience with Japanese cuisine is eating supermarket California rolls.")) (~docs/section :title "AI wrote most of it" :id "ai" (p :class "text-stone-600" "A significant portion of sx — the evaluator, the parser, the primitives, the CSS scanner, this very documentation site — was written with AI assistance. The author typed prompts. Claude typed code. This is not artisanal hand-crafted software. This is the software equivalent of a microwave dinner presented on a nice plate.") (p :class "text-stone-600" "He adds features by typing stuff like \"is there rom for macros within sx.js? what benefits m,ight that bring?\", skim-reading the response, and then entering \"crack on then!\" This is not software engineering. This is improv comedy with a compiler.") (p :class "text-stone-600" "Is that bad? Maybe. Is it honest? Yes. Is this paragraph also AI-generated? You will never know.")) (~docs/section :title "No ecosystem" :id "ecosystem" (p :class "text-stone-600" "npm has 2 million packages. PyPI has 500,000. sx has zero packages, zero plugins, zero middleware, zero community, zero Stack Overflow answers, and zero conference talks. If you get stuck, your options are: read the source, or ask the one person who wrote it.") (p :class "text-stone-600" "That person is busy. Good luck.")) (~docs/section :title "Zero jobs" :id "jobs" (p :class "text-stone-600" "Adding sx to your CV will not get you hired. It will get you questioned.") (p :class "text-stone-600" "The interview will end shortly after.")) (~docs/section :title "The creator thinks s-expressions are a personality trait" :id "personality" (p :class "text-stone-600" "Look at this documentation site. It has a violet colour scheme. It has credits to htmx. It has a future possibilities page about hypothetical sx:// protocol schemes. The creator built an entire microservice — with Docker, Redis, and a custom entrypoint script — just to serve documentation about a rendering engine that runs one website.") (p :class "text-stone-600" "This is not engineering. This is a personality disorder expressed in YAML."))))
(~docs/page :title "sx sucks" (~docs/section :title "The parentheses" :id "parens" (p (~tw :tokens "text-stone-600") "S-expressions are parentheses. Lots of parentheses. You thought LISP was dead? No, someone just decided to use it for HTML templates. Your IDE will need a parenthesis counter. Your code reviews will be 40% closing parens. Every merge conflict will be about whether a paren belongs on this line or the next.")) (~docs/section :title "Nobody asked for this" :id "nobody-asked" (p (~tw :tokens "text-stone-600") "The JavaScript ecosystem has React, Vue, Svelte, Solid, Qwik, and approximately 47,000 other frameworks. htmx proved you can skip them all. sx looked at this landscape and said: you know what this needs? A Lisp dialect. For HTML. Over HTTP.") (p (~tw :tokens "text-stone-600") "Nobody was asking for this. The zero GitHub stars confirm it. It is not even on GitHub.")) (~docs/section :title "The author has never written a line of LISP" :id "no-lisp" (p (~tw :tokens "text-stone-600") "The author of sx has never written a single line of actual LISP. Not Common Lisp. Not Scheme. Not Clojure. Not even Emacs Lisp. The entire s-expression evaluator was written by someone whose mental model of LISP comes from reading the first three chapters of SICP and then closing the tab.") (p (~tw :tokens "text-stone-600") "This is like building a sushi restaurant when your only experience with Japanese cuisine is eating supermarket California rolls.")) (~docs/section :title "AI wrote most of it" :id "ai" (p (~tw :tokens "text-stone-600") "A significant portion of sx — the evaluator, the parser, the primitives, the CSS scanner, this very documentation site — was written with AI assistance. The author typed prompts. Claude typed code. This is not artisanal hand-crafted software. This is the software equivalent of a microwave dinner presented on a nice plate.") (p (~tw :tokens "text-stone-600") "He adds features by typing stuff like \"is there rom for macros within sx.js? what benefits m,ight that bring?\", skim-reading the response, and then entering \"crack on then!\" This is not software engineering. This is improv comedy with a compiler.") (p (~tw :tokens "text-stone-600") "Is that bad? Maybe. Is it honest? Yes. Is this paragraph also AI-generated? You will never know.")) (~docs/section :title "No ecosystem" :id "ecosystem" (p (~tw :tokens "text-stone-600") "npm has 2 million packages. PyPI has 500,000. sx has zero packages, zero plugins, zero middleware, zero community, zero Stack Overflow answers, and zero conference talks. If you get stuck, your options are: read the source, or ask the one person who wrote it.") (p (~tw :tokens "text-stone-600") "That person is busy. Good luck.")) (~docs/section :title "Zero jobs" :id "jobs" (p (~tw :tokens "text-stone-600") "Adding sx to your CV will not get you hired. It will get you questioned.") (p (~tw :tokens "text-stone-600") "The interview will end shortly after.")) (~docs/section :title "The creator thinks s-expressions are a personality trait" :id "personality" (p (~tw :tokens "text-stone-600") "Look at this documentation site. It has a violet colour scheme. It has credits to htmx. It has a future possibilities page about hypothetical sx:// protocol schemes. The creator built an entire microservice — with Docker, Redis, and a custom entrypoint script — just to serve documentation about a rendering engine that runs one website.") (p (~tw :tokens "text-stone-600") "This is not engineering. This is a personality disorder expressed in YAML."))))

2
sx/sx/essays/tail-call-optimization.sx
View File

File diff suppressed because one or more lines are too long

54
sx/sx/essays/the-art-chain.sx
View File

@@ -4,70 +4,70 @@
(defcomp ~essays/the-art-chain/essay-the-art-chain ()
(~docs/page :title "The Art Chain"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"On making, self-making, and the chain of artifacts that produces itself.")
(~docs/section :title "I. Ars" :id "ars"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The Latin word " (em "ars") " means something made with skill. Not art as in paintings on gallery walls. Art as in " (em "artifice") ", " (em "artifact") ", " (em "artisan") ". The made thing. The Greek " (em "techne") " is the same word — craft, skill, the knowledge of how to make. There was no distinction between art and engineering because there was no distinction to make.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A bridge is " (em "ars") ". A poem is " (em "ars") ". A proof is " (em "ars") ". What makes something art is not its medium or its audience but the fact that it was " (em "made") " — brought into being by someone who knew how to bring it into being. The maker's knowledge is embedded in the made thing. You can read the knowledge back out by studying what was made.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Software is " (em "ars") ". Obviously. It is the most " (em "ars") " thing we have ever built — pure made-ness, structure conjured from nothing, shaped entirely by the maker's skill and intent. There is no raw material. No marble to chisel, no pigment to mix. Just thought, made concrete in symbols."))
(~docs/section :title "II. The spec at the centre" :id "spec"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX has a peculiar architecture. At its centre sits a specification — a set of s-expression files that define the language. Not a description of the language. Not documentation " (em "about") " the language. The specification " (em "is") " the language. It is simultaneously a formal definition and executable code. You can read it as a document or run it as a program. It does not describe how to build an SX evaluator; it " (em "is") " an SX evaluator, expressed in the language it defines.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is the nucleus. Everything else radiates outward from it.")
(~docs/code :src (highlight ";; The spec defines eval-expr\n;; eval-expr evaluates the spec\n;; The spec is an artifact that makes itself\n\n(define eval-expr\n (fn (expr env)\n (cond\n (number? expr) expr\n (string? expr) expr\n (symbol? expr) (env-get env (symbol-name expr))\n (list? expr) (eval-list expr env)\n :else expr)))" "lisp"))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"From this nucleus, concentric rings unfurl:"))
(~docs/section :title "III. The rings" :id "rings"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The first ring is the " (strong "bootstrapper") ". It reads the spec and emits a native implementation — JavaScript, Python, or any other target. The bootstrapper is a translator: it takes the made thing (the spec) and makes another thing (an implementation) that behaves identically. The spec's knowledge is preserved in the translation. Nothing is added, nothing is lost.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The second ring is the " (strong "platform bridge") ". The spec defines pure logic — evaluation, rendering, parsing. But a running system needs to touch the world: read files, make HTTP requests, manipulate DOM nodes. The platform bridge provides these capabilities. It is the boundary between the made world (the spec) and the found world (the host environment). " (code "boundary.sx") " is literally the membrane — it declares what the host must provide so the spec can function.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The third ring is the " (strong "runtime") " — bootstrapped spec plus platform bridge, assembled into a working system. This is where the spec stops being an idea and starts being a process. It evaluates expressions. It renders pages. It handles requests.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The fourth ring is " (strong "application code") " — components, pages, layouts, written in the language the spec defined. Every " (code "defcomp") " is an artifact made from the tools the spec provided. Every " (code "(div :class \"card\" (p \"hello\"))") " is the spec expressing itself through a developer's intent.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The fifth ring is " (strong "this website") " — which renders the spec's source code using the runtime the spec produced, displayed in components written in the language the spec defines, navigated by an engine the spec specifies. The documentation is the thing documenting itself."))
(~docs/section :title "IV. The chain" :id "chain"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Each ring is an artifact — a made thing. And each artifact is made " (em "by") " the artifact inside it. The spec makes the bootstrapper's output. The runtime makes the application's output. The application makes the page the user sees. It is a chain of making.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This chain has three properties that are individually common but collectively rare:")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(strong "Content addressing.") " Each artifact can be identified by the hash of its content. The spec at a given version has a specific hash. The bootstrapped output from that spec has a deterministic hash. A component definition has a hash. Identity " (em "is") " content. You don't ask " (em "where") " an artifact lives — you ask " (em "what") " it is.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(strong "Deterministic derivation.") " Given the same spec, the bootstrapper produces the same output. Byte for byte. This is not aspirational — it is verified. The self-hosting bootstrapper (py.sx) proves it: G0 (hand-written bootstrapper) and G1 (self-hosted bootstrapper) produce identical output. The derivation is a pure function. Anyone can run it and verify the result.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(strong "Self-verification.") " The spec includes tools that can prove properties about the spec. " (code "prove.sx") " checks primitive semantics. " (code "types.sx") " validates composition. " (code "z3.sx") " translates declarations into verification conditions. These tools are themselves part of the spec, subject to the same verification they perform. The chain can verify itself.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"These three properties together — content addressing, deterministic derivation, self-verification — are what a blockchain provides. But here there is no proof-of-work, no tokens, no artificial scarcity, no consensus mechanism between untrusted parties. The \"mining\" is bootstrapping. The \"consensus\" is mathematical proof. The \"value\" is that anyone can take the spec, derive an implementation, and " (em "know") " it is correct."))
(~docs/section :title "V. Universal analysis" :id "analysis"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Here is the consequence that takes time to absorb: any tool that can analyse the spec can analyse " (em "everything the spec produces") ".")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A type checker written in SX that validates the spec's primitives also validates every call to those primitives in every component in every application. A dependency analyser that walks the spec's AST walks application ASTs identically — because application code is expressed in the same structures the spec defines. A theorem prover that verifies the spec's properties verifies the properties of everything downstream.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is because the rings are not separate systems. They are the " (em "same") " system at different scales. Application code is spec-shaped. Bootstrapped output is spec-derived. Components are spec-evaluated. The analysis surface is uniform from the nucleus to the outermost ring.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"And the analysis tools are " (em "inside") " the chain. They are artifacts too, written in SX, subject to the same analysis they perform. The type checker can type-check itself. The prover can prove properties about itself. This is not a bug or a curiosity — it is the point. A system that cannot reason about itself is a system that must be reasoned about from outside, by tools written in other languages, maintained by other processes, trusted for other reasons. A self-analysing system closes the loop."))
(~docs/section :title "VI. The art in the chain" :id "art"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"So what is the art chain? It is a chain of artifacts — made things — where each link produces the next, the whole chain can verify itself, and the chain's identity is its content.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"It is not a blockchain in the financial sense. It is not a distributed ledger, a currency, a market. It borrows the structural properties — content addressing, determinism, verification — without the economic machinery. What remains when you strip the economics from a blockchain is a " (em "provenance chain") ": a record of how each thing was made from the thing before it, verifiable by anyone, depending on nothing but the mathematics.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The Art DAG has the right name. It is not a system for processing \"art\" in the colloquial sense — images, videos, media. It is a " (em "directed acyclic graph of made things") ". Each node is an artifact. Each edge is a derivation. The graph is content-addressed. Execution is deterministic. The DAG itself is the art.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"And the whole SX system — spec, bootstrappers, runtimes, components, pages, this essay explaining itself — is one continuous act of making. " (em "Ars") " all the way down. Not because it is beautiful (though it sometimes is) or expressive (though it tries to be) but because it is " (em "made") ". Deliberately, skilfully, from nothing, by someone who knew how.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"That is what " (em "techne") " always was. We just forgot."))))

2
sx/sx/essays/why-sexps.sx
View File

@@ -1,2 +1,2 @@
(defcomp ~essays/why-sexps/essay-why-sexps ()
(~docs/page :title "Why S-Expressions Over HTML Attributes" (~docs/section :title "The problem with HTML attributes" :id "problem" (p :class "text-stone-600" "HTML attributes are strings. You can put anything in a string. htmx puts DSLs in strings — trigger modifiers, swap strategies, CSS selectors. This works but it means you're parsing a language within a language within a language.") (p :class "text-stone-600" "S-expressions are already structured. Keywords are keywords. Lists are lists. Nested expressions nest naturally. There's no need to invent a trigger modifier syntax because the expression language already handles composition.")) (~docs/section :title "Components without a build step" :id "components" (p :class "text-stone-600" "React showed that components are the right abstraction for UI. The price: a build step, a bundler, JSX transpilation. With s-expressions, defcomp is just another form in the language. No transpiler needed. The same source runs on server and client.")) (~docs/section :title "When attributes are better" :id "better" (p :class "text-stone-600" "HTML attributes work in any HTML document. S-expressions need a runtime. If you want progressive enhancement that works with JS disabled, htmx is better. If you want to write HTML by hand in static files, htmx is better. sx only makes sense when you're already rendering server-side and want components."))))
(~docs/page :title "Why S-Expressions Over HTML Attributes" (~docs/section :title "The problem with HTML attributes" :id "problem" (p (~tw :tokens "text-stone-600") "HTML attributes are strings. You can put anything in a string. htmx puts DSLs in strings — trigger modifiers, swap strategies, CSS selectors. This works but it means you're parsing a language within a language within a language.") (p (~tw :tokens "text-stone-600") "S-expressions are already structured. Keywords are keywords. Lists are lists. Nested expressions nest naturally. There's no need to invent a trigger modifier syntax because the expression language already handles composition.")) (~docs/section :title "Components without a build step" :id "components" (p (~tw :tokens "text-stone-600") "React showed that components are the right abstraction for UI. The price: a build step, a bundler, JSX transpilation. With s-expressions, defcomp is just another form in the language. No transpiler needed. The same source runs on server and client.")) (~docs/section :title "When attributes are better" :id "better" (p (~tw :tokens "text-stone-600") "HTML attributes work in any HTML document. S-expressions need a runtime. If you want progressive enhancement that works with JS disabled, htmx is better. If you want to write HTML by hand in static files, htmx is better. sx only makes sense when you're already rendering server-side and want components."))))

106
sx/sx/essays/zero-tooling.sx
View File

@@ -1,20 +1,20 @@
(defcomp ~essays/zero-tooling/essay-zero-tooling ()
(~docs/page :title "Tools for Fools"
(p :class "text-stone-500 text-sm italic mb-8"
(p (~tw :tokens "text-stone-500 text-sm italic mb-8")
"SX was built without a code editor. No IDE, no manual source edits, no build tools, no linters, no bundlers. The entire codebase — evaluator, renderer, spec, documentation site, test suite — was produced through conversation with an agentic AI. This is what zero-tooling web development looks like.")
(~docs/section :title "No code editor" :id "no-editor"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This needs to be stated plainly, because it sounds like an exaggeration: " (strong "not a single line of SX source code was written by hand in a code editor") ". Every component definition, every page route, every essay (including this one), every test case, every spec file — all of it was produced through natural-language conversation with Claude Code, an agentic AI that reads, writes, and modifies files on the developer's behalf.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"No VS Code. No Vim. No Emacs. No Sublime Text. No cursor blinking in a source file. The developer describes intent; the AI produces the code, edits the files, runs the tests, and iterates. The code editor — the tool that has defined software development for sixty years — was not used.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a stunt. It is a consequence of two properties converging: a language with trivial syntax that AI can produce flawlessly, and an AI agent capable of understanding and modifying an entire codebase through conversation. Neither property alone would be sufficient. Together, they make the code editor unnecessary."))
(~docs/section :title "The toolchain that wasn't" :id "toolchain"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A modern web application typically requires a stack of tooling before a single feature can be built. Consider what a React project demands:")
(ul :class "space-y-2 text-stone-600"
(ul (~tw :tokens "space-y-2 text-stone-600")
(li (strong "Bundler") " — Webpack, Vite, Rollup, or esbuild to resolve modules, tree-shake dead code, split bundles, and minify output.")
(li (strong "Transpiler") " — Babel or SWC to transform JSX into function calls, strip TypeScript annotations, and downlevel modern syntax for older browsers.")
(li (strong "Package manager") " — npm, yarn, or pnpm to manage hundreds or thousands of transitive dependencies in " (code "node_modules") ".")
@@ -25,112 +25,112 @@
(li (strong "Type checker") " — TypeScript compiler running in parallel to catch type errors that JavaScript's dynamic semantics would defer to runtime.")
(li (strong "Test runner") " — Jest or Vitest with jsdom or happy-dom to simulate a browser environment, plus Cypress or Playwright for integration tests.")
(li (strong "Framework CLI") " — create-react-app, Next.js CLI, or Angular CLI to scaffold project structure, generate boilerplate, and manage framework-specific configuration."))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"That is ten categories of tooling, each with its own configuration format, update cycle, breaking changes, and mental overhead. A fresh " (code "npx create-next-app") " pulls in over 300 packages. The " (code "node_modules") " directory can exceed 200 megabytes. The configuration surface — " (code "webpack.config.js") ", " (code "tsconfig.json") ", " (code ".eslintrc") ", " (code ".prettierrc") ", " (code "postcss.config.js") ", " (code "tailwind.config.js") ", " (code "jest.config.js") ", " (code "next.config.js") " — is itself a specialization.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX uses " (strong "none of them") "."))
(~docs/section :title "Why each tool is unnecessary" :id "why-unnecessary"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Each tool in the conventional stack exists to solve a problem. SX eliminates the problems themselves, not just the tools.")
(h4 :class "font-semibold text-stone-700 mt-6 mb-2" "Bundlers")
(p :class "text-stone-600"
(h4 (~tw :tokens "font-semibold text-stone-700 mt-6 mb-2") "Bundlers")
(p (~tw :tokens "text-stone-600")
"Bundlers exist because JavaScript's module system requires resolution — imports must be traced, dependencies gathered, and the result packaged for the browser. SX components are defined in " (code ".sx") " files, loaded at startup into the evaluator's environment, and served as s-expressions over the wire. The wire format is the source format. There is no compilation step, no module resolution, and no bundle. The " (code "deps.sx") " spec computes per-page component sets at runtime — only the components a page actually uses are sent to the client. This is tree-shaking without the tree-shaker.")
(h4 :class "font-semibold text-stone-700 mt-6 mb-2" "Transpilers")
(p :class "text-stone-600"
(h4 (~tw :tokens "font-semibold text-stone-700 mt-6 mb-2") "Transpilers")
(p (~tw :tokens "text-stone-600")
"Transpilers exist because developers write in one language (JSX, TypeScript, modern ES20XX) and must ship another (browser-compatible JavaScript). SX source runs directly — the evaluator walks the same AST that was authored. There is no JSX-to-createElement transform because s-expressions " (em "are") " the component syntax. There are no type annotations to strip because types are enforced at the boundary, at startup. There is no syntax to downlevel because the grammar has been the same since 1958.")
(h4 :class "font-semibold text-stone-700 mt-6 mb-2" "Package managers")
(p :class "text-stone-600"
(h4 (~tw :tokens "font-semibold text-stone-700 mt-6 mb-2") "Package managers")
(p (~tw :tokens "text-stone-600")
"Package managers exist because the JavaScript ecosystem fragments functionality into thousands of tiny packages with deep transitive dependency trees. SX's runtime is self-contained: approximately eighty primitives built into the spec, an evaluator bootstrapped from " (code ".sx") " files, and a renderer that produces HTML, DOM nodes, or SX wire format. No third-party packages. No dependency resolution. No lock files. No supply-chain attack surface. The planned future — content-addressed components on IPFS — replaces package registries with content verification.")
(h4 :class "font-semibold text-stone-700 mt-6 mb-2" "CSS build tools")
(p :class "text-stone-600"
(h4 (~tw :tokens "font-semibold text-stone-700 mt-6 mb-2") "CSS build tools")
(p (~tw :tokens "text-stone-600")
"CSS preprocessors and build tools exist because CSS has a global namespace, no scoping mechanism, and no way to know which rules a page actually uses. CSSX solves all three: the server scans the rendered component tree, collects the CSS classes actually referenced, and sends only those rules. Styles are co-located in components as keyword arguments. There is no global stylesheet to collide with, no preprocessor to run, no PurgeCSS to configure. The CSS each page needs is computed from the component graph — a runtime operation, not a build step.")
(h4 :class "font-semibold text-stone-700 mt-6 mb-2" "Dev servers and HMR")
(p :class "text-stone-600"
(h4 (~tw :tokens "font-semibold text-stone-700 mt-6 mb-2") "Dev servers and HMR")
(p (~tw :tokens "text-stone-600")
"Dev servers with hot module replacement exist because compilation creates a feedback delay — you change a file, wait for the bundler to rebuild, and watch the browser update via WebSocket. SX has no compilation. " (code ".sx") " files are checked for changes on every request via " (code "reload_if_changed()") ". Edit the file, refresh the browser, see the result. The feedback loop is bounded by disk I/O, not by a build pipeline. There is no dev server because there is nothing to serve differently from production.")
(h4 :class "font-semibold text-stone-700 mt-6 mb-2" "Linters and formatters")
(p :class "text-stone-600"
(h4 (~tw :tokens "font-semibold text-stone-700 mt-6 mb-2") "Linters and formatters")
(p (~tw :tokens "text-stone-600")
"Linters exist because complex grammars permit many ways to write incorrect or inconsistent code. Formatters exist because those same grammars permit many ways to write correct but inconsistently styled code. S-expressions have one syntactic form: " (code "(head args...)") ". Parentheses open and close. Strings are quoted. That is the entire grammar. There are no semicolons to forget, no operator precedence to get wrong, no closing tags to mismatch. Formatting is just indentation of nested lists. There is nothing to lint and nothing to format.")
(h4 :class "font-semibold text-stone-700 mt-6 mb-2" "Type systems")
(p :class "text-stone-600"
(h4 (~tw :tokens "font-semibold text-stone-700 mt-6 mb-2") "Type systems")
(p (~tw :tokens "text-stone-600")
"TypeScript exists because JavaScript's dynamic typing defers errors to runtime, often to production. SX's boundary spec declares the signature of every primitive, every IO function, and every page helper. " (code "SX_BOUNDARY_STRICT=1") " validates all registrations at startup — a type violation crashes the application before it serves a single request. Runtime predicates (" (code "string?") ", " (code "number?") ", " (code "list?") ") handle the rest. The type system is not a separate tool running in parallel — it is the spec, enforced at the edge.")
(h4 :class "font-semibold text-stone-700 mt-6 mb-2" "Framework CLIs and scaffolding")
(p :class "text-stone-600"
(h4 (~tw :tokens "font-semibold text-stone-700 mt-6 mb-2") "Framework CLIs and scaffolding")
(p (~tw :tokens "text-stone-600")
"Framework CLIs exist because modern frameworks have complex setup — configuration files, directory conventions, build chains, routing configurations. SX has two declarative abstractions: " (code "defcomp") " (a component) and " (code "defpage") " (a route). Write a component in a " (code ".sx") " file, reference it from a " (code "defpage") ", and it is live. There is no scaffolding because there is nothing to scaffold."))
(~docs/section :title "The AI replaces the rest" :id "ai-replaces"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Eliminating the build toolchain still leaves the most fundamental tool: the code editor. The text editor is so basic to programming that it is invisible — questioning its necessity sounds absurd. But the traditional editor exists to serve " (em "human") " limitations:")
(ul :class "space-y-2 text-stone-600"
(ul (~tw :tokens "space-y-2 text-stone-600")
(li (strong "Syntax highlighting") " — because humans need visual cues to parse complex grammars. S-expressions are trivially parseable; an AI does not need color-coding to understand them.")
(li (strong "Autocomplete") " — because humans cannot remember every function name, parameter, and type signature. An AI that has read the entire codebase does not need autocomplete; it already knows every symbol in scope.")
(li (strong "Go-to-definition") " — because humans lose track of where things are defined across hundreds of files. An AI navigates by reading, grep, and glob — the same tools the editor uses internally, without the GUI.")
(li (strong "Error squiggles") " — because humans need real-time feedback on mistakes. An AI produces correct code from the spec, and when it does not, it reads the error, understands the cause, and fixes it in the next edit.")
(li (strong "Multi-cursor editing") " — because humans need mechanical assistance to make the same change in multiple places. An AI makes coordinated changes across files atomically — component definition, navigation data, page route — in a single operation.")
(li (strong "Version control integration") " — because humans need visual diffs and staging interfaces. An AI reads " (code "git diff") ", understands the changes, and commits with meaningful messages."))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Every feature of a modern IDE exists to compensate for a human cognitive limitation. When the agent doing the editing has no such limitations — it can hold the full codebase in context, produce valid syntax without visual feedback, trace dependencies without tooling, and make multi-file changes atomically — the editor is not needed.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not hypothetical. It is how SX was built. The developer's interface is a terminal running Claude Code. The conversation goes: describe what you want, review what the AI produces, approve or redirect. The AI reads the existing code, understands the conventions, writes the new code, edits the navigation, updates the page routes, and verifies consistency. The " (em "conversation") " is the development environment."))
(~docs/section :title "Before enlightenment, write code" :id "before-enlightenment"
(p :class "text-stone-600"
"Carson Gross makes an important point in " (a :href "https://htmx.org/essays/yes-and/" :class "text-violet-600 hover:underline" "\"Yes, and...\"") ": you have to have written code in order to effectively read code. The ability to review, critique, and direct is built on the experience of having done the work yourself. You cannot skip the craft and jump straight to the oversight.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Carson Gross makes an important point in " (a :href "https://htmx.org/essays/yes-and/" (~tw :tokens "text-violet-600 hover:underline") "\"Yes, and...\"") ": you have to have written code in order to effectively read code. The ability to review, critique, and direct is built on the experience of having done the work yourself. You cannot skip the craft and jump straight to the oversight.")
(p (~tw :tokens "text-stone-600")
"He is right. " (strong "...and yet."))
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"There is a Zen teaching about the three stages of practice. Before enlightenment: chop wood, carry water. During enlightenment: chop wood, carry water. After enlightenment: chop wood, carry water. The activities look the same from the outside, but the relationship to them has changed completely. The master chops wood without the beginner's anxiety about whether they are chopping correctly, and without the intermediate's self-conscious technique. They just chop.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Software development has its own version. " (em "Before understanding, write code.") " You must have written the bundler configuration to understand why bundlers exist. You must have debugged the CSS cascade to understand why scoping matters. You must have traced a transitive dependency chain to understand why minimal dependencies matter. The craft comes first.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(em "During understanding, read code.") " You review pull requests. You audit architectures. You read more code than you write. You develop the taste that lets you tell good code from bad code, necessary complexity from accidental complexity, real problems from invented ones.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
(em "After understanding, describe intent.") " You have internalized the patterns so deeply that you do not need to type them. You know what a component should look like without writing it character by character. You know what the test should cover without spelling out each assertion. You know what the architecture should be without drawing every box and arrow. You describe; the agent executes. Not because you cannot do the work, but because the work has become transparent to you.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This is not a shortcut. The developer who built SX through conversation with an AI had decades of experience writing code by hand — in Python, VB, C#, JavaScript, C, and others (although he was never that good at it) — but never Lisp. The zero-tooling workflow is not a substitute for that experience. It is what comes " (em "after") " that experience. The wood still gets chopped. The water still gets carried. But the relationship to the chopping and carrying has changed.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"What pushed him to use agentic AI was when several of the keys on his keyboard stopped working. Too much coding! AI LLMs don't mind typos."))
(~docs/section :title "Why this only works with s-expressions" :id "why-sexps"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"This approach would not work with most web technologies. The reason is the " (strong "syntax tax") " — the overhead a language imposes on AI code generation.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Consider what an AI must get right to produce a valid React component: JSX tags that open and close correctly, curly braces for JavaScript expressions inside markup, import statements with correct module paths, semicolons or ASI boundary rules, TypeScript type annotations with angle-bracket generics, CSS-in-JS template literals with different quoting rules from the surrounding code, and hook call ordering constraints that are semantic, not syntactic. Each of these is a failure point. Each failure produces something that does not parse, let alone run.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"S-expressions have one rule: parentheses match. The syntax tax is zero. An AI that can count parentheses can produce syntactically valid SX. This means the AI spends its entire capacity on " (em "what") " to generate — the semantics, the structure, the intent — rather than on formatting, escaping, and syntactic bookkeeping.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The combination is more than additive. SX is deliberately spartan for hand-editing — all those parentheses, no syntax sugar, no operator precedence. Developers who see it for the first time recoil. But AI does not recoil. AI does not care about parentheses. It sees a minimal, regular, unambiguous grammar and produces correct output reliably. Meanwhile, the languages that are comfortable for humans — with their rich syntax, implicit rules, and contextual parsing — are exactly the ones where AI makes the most mistakes.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX is optimized for the agent, not the typist. This turns out to be the right trade-off when the agent is doing the typing."))
(~docs/section :title "What zero-tooling actually means" :id "what-it-means"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Zero-tooling does not mean zero software. The SX evaluator exists. The server exists. The browser runtime exists. These are " (em "the system") ", not tools for building the system. The distinction matters.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"A carpenter's hammer is a tool. The house is not a tool. In web development, this distinction has been lost. The bundler, the transpiler, the linter, the formatter, the type checker, the dev server — these are all tools for building the application. The application itself is the server, the evaluator, the renderer, the browser runtime. Traditional web development has accumulated so many tools-for-building-the-thing that the tools-for-building-the-thing often have more code, more configuration, and more failure modes than the thing itself.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"SX has the thing. It does not have tools for building the thing. You write " (code ".sx") " files. They run. That is the entire workflow.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Add an agentic AI, and you do not even write the " (code ".sx") " files. You describe what you want. The AI writes the files. They run. The workflow is: intent → code → execution, with no intermediate tooling layer and no manual editing step."))
(~docs/section :title "The proof" :id "proof"
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The evidence for zero-tooling development is not a benchmark or a whitepaper. It is this website.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Every page you are reading was produced through conversation with an agentic AI. The SX evaluator — a self-hosting interpreter with tail-call optimization, delimited continuations, macro expansion, and three rendering backends — was developed without opening a code editor. The specification files that define the language were written without an IDE. The bootstrappers that compile the spec to JavaScript and Python were produced without syntax highlighting or autocomplete. The test suite — hundreds of tests across evaluator, parser, renderer, router, dependency analyzer, and engine — was written without a test runner GUI. This documentation site — with its navigation, its code examples, its live demos — was built without a web development framework's CLI.")
(p :class "text-stone-600"
"The developer sat in a terminal. They described what they wanted. The AI produced the code. When something was wrong, they described what was wrong. The AI fixed it. When something needed to change, they described the change. The AI made the change. Across thousands of files, tens of thousands of lines of code, and months of development. Even the jokes — the " (a :href "/sx/(etc.(essay.sx-sucks))" :class "text-violet-600 hover:underline" "self-deprecating essay") " about everything wrong with SX, the deadpan tone of the documentation, the essay you are reading right now — all produced through conversation, not through typing.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"The developer sat in a terminal. They described what they wanted. The AI produced the code. When something was wrong, they described what was wrong. The AI fixed it. When something needed to change, they described the change. The AI made the change. Across thousands of files, tens of thousands of lines of code, and months of development. Even the jokes — the " (a :href "/sx/(etc.(essay.sx-sucks))" (~tw :tokens "text-violet-600 hover:underline") "self-deprecating essay") " about everything wrong with SX, the deadpan tone of the documentation, the essay you are reading right now — all produced through conversation, not through typing.")
(p (~tw :tokens "text-stone-600")
"No build step. No bundler. No transpiler. No package manager. No CSS preprocessor. No dev server. No linter. No formatter. No type checker. No framework CLI. No code editor.")
(p :class "text-stone-600"
(p (~tw :tokens "text-stone-600")
"Zero tools."))))
;; ---------------------------------------------------------------------------