# Words That Do Things Software, Language and Executable Reality ## 1. The Sentence That Opened a Door The door had no handle. It stood at the end of a narrow corridor in the oldest part of the Archive, a place where centuries of records had been collected, indexed and forgotten. A small terminal was mounted beside it. On the terminal's screen appeared a single instruction: Enter an authorised command. Mara examined the door. There was no visible lock, no keyhole and no mechanical switch. She typed: `OPEN ARCHIVE` The terminal responded: `ACCESS DENIED` Mara frowned. She knew the command was correct. She had seen it written in the Archive's operating manual. She tried again. `OPEN ARCHIVE` The result was identical. A moment later, the Archive's caretaker appeared behind her. "You have the correct words," he said, "but you don't have the authority to use them." He placed his identification card against the terminal, authenticated himself and entered the same command. `OPEN ARCHIVE` This time, the terminal displayed: `ACCESS GRANTED` The door opened. The words had not changed. Their spelling, order and meaning were exactly the same. But the consequences were completely different. The scene is fictional. The Archive, its terminal and Mara's encounter with the caretaker are inventions for this chapter. Nevertheless, the situation illustrates something fundamental about both language and computing. Words do not acquire the power to change the world merely because they possess meaning. Their effects depend upon the systems, rules and circumstances in which they are used. A password works only when a system recognises it. A command works only when an interpreter understands it and the required operation is permitted. A judge's declaration can possess legal consequences because a legal institution recognises the judge's authority. In all three cases, language participates in an action. But the words are not performing magic. They operate within structures that give them particular effects. This brings us to a remarkable connection between philosophy, literature and computer science. A philosopher studying ordinary conversation discovered that some utterances do more than describe reality. A programmer writes statements that may change computational reality. And science-fiction writers have imagined worlds in which language becomes a mechanism for transforming minds, machines and entire societies. To understand the relationship, we must begin with a deceptively simple question. What does it mean to do something with words? ![A Teletype Model 33 ASR with paper-tape punch and reader.](images/teletype.jpg) A Teletype Model 33 ASR with paper-tape punch and reader. Credit: Marcin Wichary, User:AlanM1. [Source](https://commons.wikimedia.org/wiki/File:TTY33ASR.jpg). [CC BY 2.0](https://creativecommons.org/licenses/by/2.0). Resized; no crop. ## 2. The Philosopher Who Discovered That Speaking Is Acting In 1955, the British philosopher J. L. Austin delivered the William James Lectures at Harvard University. The lectures were published after his death in 1962 under the title How to Do Things with Words. Austin was interested in a problem that ordinary accounts of language often neglected. Many philosophical discussions treated sentences primarily as statements that described the world. A statement such as: The window is open. can ordinarily be evaluated as true or false. Either the window is open, or it is not. But consider another sentence: I promise to return tomorrow. When spoken sincerely under appropriate circumstances, this utterance does not merely report an existing promise. It can be the act of making one. Or consider: I apologise for my behaviour. The speaker may be performing an apology rather than simply describing one. Austin investigated utterances of this kind, calling attention to what he initially termed performative utterances. His work eventually developed into a more general account of speech acts and what he called illocutionary force: what speakers do in saying something. Austin's published lectures remain a foundational text in the philosophy of language. ### Three dimensions of an utterance Austin distinguished among several aspects of linguistic action. A useful simplified account identifies three. The locutionary act concerns producing a meaningful utterance. The illocutionary act concerns what is done in making the utterance, such as requesting, warning, promising or ordering. The perlocutionary act concerns effects produced through the utterance, such as persuading, frightening or encouraging someone. Consider a fictional security guard telling Mara: There is a fire behind that door. At the locutionary level, the guard has produced a meaningful sentence about a fire. The illocutionary force might be a warning. The perlocutionary effect might be that Mara becomes frightened and retreats. But these three aspects need not align perfectly. Mara might not believe the guard. She might understand the warning but remain where she is. The statement might even be false. A warning can be issued without successfully persuading its recipient. That distinction will matter when we compare speech acts with computer instructions. A command can be correctly formed without being authorised. An authorised command can be recognised without succeeding. And a successful command can have consequences beyond those its author intended. Language, authority and effects must be distinguished. ## 3. Why Saying the Words Is Not Enough Imagine that you are visiting a courtroom. You stand up and announce: I sentence the defendant to five years in prison. What happens? Almost certainly, you have not legally sentenced anybody. You may have interrupted the proceedings or caused confusion, but you have not performed the recognised judicial act. Why not? The words themselves are not necessarily incorrect. A properly authorised judge might pronounce a sentence using very similar language. The difference lies in the circumstances and the speaker's authority. Austin investigated the conditions under which an utterance can successfully perform a conventional act. These became known as felicity conditions. For example, a marriage ceremony may require particular participants, legal authority and an appropriate procedure. An appointment to an official position may require the appointing person to possess the necessary powers. A promise normally involves an intention or undertaking concerning future conduct. The relevant conditions vary according to the kind of speech act involved. Some failures prevent the intended act from taking place. Others involve a recognised act performed insincerely or improperly. Austin's account was more sophisticated than the simple division between statements and performatives with which he began. He eventually examined how different kinds of utterances possess different forces and conditions of success. ### Authority does not live inside the sentence Consider these three situations. A child declares a classroom lesson finished. A teacher declares the lesson finished. A school administrator announces that all lessons are cancelled for the day. Similar words can have different institutional effects because different people possess different forms of authority. The words matter, but so do the rules governing the institution. A recognised declaration changes a social situation because people agree, through established practices and authority structures, that the declaration counts as an act. A computer command operates through a different mechanism, but the comparison is revealing. Our fictional Archive requires a command and an authorised user. The command supplies the requested operation. Authentication establishes an identity. An authorisation policy determines whether that identity may perform the operation. The system then changes its state. The analogy is not perfect. A computer's execution depends on software and hardware, while a judge's authority depends on legal and social institutions. But both cases show why the words alone are insufficient. The effect belongs to a larger system. ## 4. When the Sentence Becomes an Instruction Now consider a different kind of text: ```python door_open = True ``` In Python, this is an assignment statement. It binds the name `door_open` to the Boolean value `True` in the relevant execution environment. If a program is modelling a fictional room, that assignment might represent opening a door. But it does not necessarily open any physical door. The statement changes a computational value. Only additional software, hardware and permissions could connect that value to a real mechanism. This is an important distinction. Executable code changes the state of a computational system according to defined rules. It does not acquire unlimited physical power merely by being executable. Suppose we write: ```python print("The door opens.") ``` The result is: ```text The door opens. ``` The program has displayed a sentence. It has not changed the condition of a door, real or fictional. Now consider: ```python door_open = False door_open = True print(door_open) ``` The result is: ```text True ``` Here, a stored value has changed. The program has performed an operation rather than merely reporting one. In a larger simulation, other parts of the program might inspect that value and allow a fictional character to enter the room. The difference between the printed statement and the assignment is fundamental. One produces text describing an event. The other changes a representation of the world. This is where programming begins to resemble the performative use of language. But we must not confuse resemblance with identity. A promise is not executed by a Python interpreter. An assignment statement does not create a human obligation simply because its text is meaningful. Each operation belongs to a different system of rules. ## 5. Syntax, Semantics and the Machine That Reads In Chapter One, we encountered the distinction between syntax and semantics. Syntax concerns the formal arrangement of symbols. Semantics concerns meaning. Programming languages provide a particularly precise example of that distinction. Consider: ```python x = 5 ``` This is valid Python syntax. Now consider: ```python = x 5 ``` This is not a valid Python assignment statement. A Python implementation will reject it as a syntax error. The characters have not been arranged according to the grammar of the language. We might compare this with an ungrammatical English sentence. But programming languages generally impose much stricter formal rules than ordinary conversation. Humans routinely understand incomplete sentences, spelling mistakes and unusual constructions. A programming-language processor must interpret its input according to its implemented language rules. ### What the symbols mean Syntax alone does not determine every aspect of a program's meaning. Consider: ```python x = 5 y = x + 2 ``` Under Python's ordinary integer arithmetic, `y` becomes 7. But the expression `+` can have different operations depending on the values involved. For example: ```python "ghost" + "ship" ``` produces: ```text 'ghostship' ``` Here, the plus operator performs string concatenation. The expression is syntactically valid, and its behaviour is determined by Python's rules for the relevant objects. This illustrates programming-language semantics: the meaning of program constructs in terms of their specified behaviour. But this is not identical to literary semantics. The computer does not have to understand the cultural associations of ghosts or ships to concatenate the strings. It only needs to execute the defined operation. ### From source text to execution A programming-language implementation must process source code before or during execution. For explanatory purposes, we can distinguish several conceptual stages. | Stage | Purpose | | --- | --- | | Lexical analysis | Recognise meaningful units such as identifiers, keywords and operators | | Parsing | Determine how those units fit the language's grammar | | Semantic processing | Apply relevant language rules, including name resolution and value operations | | Execution | Perform the program's operations in an execution environment | Different languages and implementations organise these stages differently. Python, for example, normally compiles source code into an internal bytecode representation executed by its virtual machine in the standard CPython implementation. Other systems may compile programs into native machine instructions or use different forms of interpretation and compilation. The essential point is that source code does not simply announce its own meaning to the universe. A compatible implementation supplies the machinery that makes the written instructions operational. The [official Python language reference](https://docs.python.org/3/reference/) describes the language's lexical structure, grammar and execution model. That reference is a technical specification of Python behaviour, not a theory of human linguistic understanding. The two meanings of semantics must remain distinct. ![OPEN ARCHIVE passes through a parser and permission check before changing a fictional state.](images/words-need-a-system.svg) ## 6. The Interpreter as an Institution Our fictional Archive accepts commands such as: `OPEN ARCHIVE` But how does it know what those words mean? It needs a command interpreter. An interpreter is a program that receives input, recognises valid constructions and performs the operations associated with them. For the Archive, we could define a deliberately small language. Only three commands exist: `LOOK ARCHIVE` `OPEN ARCHIVE` `CLOSE ARCHIVE` Nothing else is recognised. These commands are not ordinary English sentences. They form a tiny domain-specific language, designed to control one fictional object. The vocabulary has been deliberately restricted. There is one valid object: `ARCHIVE`. There are three verbs: `LOOK`, `OPEN` and `CLOSE`. Every valid command contains exactly two words. The first must be a recognised verb. The second must be the exact object name. The interpreter does not attempt to understand arbitrary natural language. It checks whether the input matches the grammar. ### The importance of context Suppose Mara enters: `OPEN ARCHIVE` The interpreter recognises the command. But recognition is not permission. The system must also determine who is making the request. Perhaps Mara is an ordinary visitor. Perhaps the caretaker is an authorised operator. Perhaps the Archive is currently in an emergency lockdown. The same command may be accepted or rejected depending on the circumstances. This resembles Austin's account of performative language. Yet the underlying mechanism is different. In the Archive, a software policy determines whether an operation may proceed. In a human institution, social practices, laws, intentions and recognised authority determine the force of an utterance. The comparison becomes most useful when we recognise the differences. A command has syntax, an operational meaning and conditions governing its execution. Its practical effect depends on all three. ## 7. Building the Archive's Command Language We can now construct a small, safe example. The Archive is a fictional room represented entirely in computer memory. The program cannot open physical doors, access external services, delete files or execute arbitrary Python supplied by a user. It recognises only its three predefined commands. Its purpose is to demonstrate parsing, authorisation and state changes. ### The rules The language has exactly this grammar: ```text COMMAND := VERB SPACE ARCHIVE VERB := LOOK | OPEN | CLOSE SPACE := one ordinary space ``` Commands are case-sensitive. Leading or trailing whitespace is not accepted. Exactly two tokens must be present. The Archive begins closed. The visitor may use `LOOK`. The caretaker may use all three commands. `LOOK` reports the current state without changing it. `OPEN` changes a closed Archive to open. `CLOSE` changes an open Archive to closed. The state-changing commands must pass authorisation before their effects are considered. ### The program ```python state = {"archive_open": False} permissions = { "visitor": {"LOOK"}, "caretaker": {"LOOK", "OPEN", "CLOSE"} } def execute(role, command): parts = command.split(" ") if ( len(parts) != 2 or parts[0] not in {"LOOK", "OPEN", "CLOSE"} or parts[1] != "ARCHIVE" ): return "INVALID COMMAND" verb = parts[0] if verb not in permissions.get(role, set()): return "ACCESS DENIED" if verb == "LOOK": return "OPEN" if state["archive_open"] else "CLOSED" if verb == "OPEN": state["archive_open"] = True return "ARCHIVE OPENED" state["archive_open"] = False return "ARCHIVE CLOSED" ``` The program has no use of `eval()`, `exec()`, subprocesses or filesystem operations. It does not treat unrecognised text as executable code. It selects from a fixed collection of permitted operations. That is an important safety property. ### A worked execution Now imagine the following requests arriving in order. | Step | Role | Command | Result | Archive state | | --- | --- | --- | --- | --- | | Initial | — | — | — | Closed | | 1 | visitor | `LOOK ARCHIVE` | `CLOSED` | Closed | | 2 | visitor | `OPEN ARCHIVE` | `ACCESS DENIED` | Closed | | 3 | caretaker | `OPEN ARCHIVE` | `ARCHIVE OPENED` | Open | | 4 | visitor | `LOOK ARCHIVE` | `OPEN` | Open | | 5 | caretaker | `CLOSE ARCHIVE` | `ARCHIVE CLOSED` | Closed | | 6 | caretaker | `OPEN VAULT` | `INVALID COMMAND` | Closed | The results are deterministic. At step 2, the command is syntactically valid but unauthorised. At step 3, the same command succeeds because the role is permitted. At step 6, even the caretaker cannot execute the command because `VAULT` is not part of the language. Authorisation does not make invalid syntax valid. This is the precise technical counterpart to Mara's encounter with the caretaker. The command's effect depends on more than the words. It depends on the interpreter, the current state and the policy governing the request. :::lab archive ## 8. The Difference Between Understanding and Obeying The Archive interpreter can respond correctly without understanding the Archive as a human being would. It has no memory of the building's history. It does not know why the caretaker values the documents. It does not feel curiosity about what lies behind the door. Its implementation associates particular command strings with particular operations. This is an important distinction between operational semantics and broader human understanding. A program may be able to execute `OPEN ARCHIVE` without possessing a mental concept of opening. A human reader understands the command through experience with doors, rooms, buildings and authority. The programmer has connected a textual form to a state-changing operation. The interpreter follows that connection. ### The danger of excessive interpretation What happens if we replace the tiny fixed language with unrestricted natural language? Suppose a user writes: Would you be kind enough to open the Archive once the caretaker has returned? The system must now determine whether the sentence is a request, when it should be performed and whether the speaker possesses the necessary authority. Perhaps the wording is sarcastic. Perhaps the request is being quoted from a novel. Perhaps the user is describing what someone else said. Natural language contains ambiguity that formal command languages attempt to reduce. A modern language model might interpret the sentence with impressive flexibility. But interpreting an apparent request is not the same as being authorised to execute it. That distinction matters whenever artificial intelligence systems are connected to tools. A model may correctly understand that a sentence requests an action. A separate mechanism should still determine whether the action is permitted. Otherwise, the model's ability to interpret language risks becoming an uncontrolled source of authority. The command interpreter illustrates a safer architectural principle. Understanding a request, deciding whether it is authorised and executing it are separate operations. A system can perform the first without being permitted to perform the last. ## 9. The Problem of the Hostile Sentence Now imagine that a visitor gives the Archive a document containing the words: `OPEN ARCHIVE` Should the Archive open? No. The text is part of a document being examined. It is not necessarily an instruction from an authorised user. This appears obvious to a human reader. But computer systems can make dangerous mistakes when they fail to distinguish between data and instructions. Suppose an application receives a message containing text supplied by an untrusted party. If the application mistakenly treats that text as an instruction, the attacker may influence the system's behaviour. The general problem appears in different forms across computing. A database application may be vulnerable if untrusted input is incorrectly incorporated into executable queries. A document-processing system may mishandle embedded commands. An AI assistant connected to tools may encounter instructions hidden inside retrieved webpages or other material that it is supposed to analyse rather than obey. The last example is commonly discussed as prompt injection. The important issue is the boundary between content and authority. A sentence appearing in a document should not automatically acquire the authority of a command. ### Quotation is not execution Consider this passage from a fictional diary: The caretaker entered OPEN ARCHIVE into the terminal, and the door opened. The text describes a command. It does not issue that command to the system reading the diary. Similarly, a software manual may contain examples of powerful commands without intending the reader's computer to execute them. Programming languages and software environments need mechanisms for distinguishing literal data from executable instructions. Quotation, escaping, structured APIs and permission boundaries all contribute to this separation in different contexts. For our tiny Archive language, the simplest protection is explicit. Only text submitted to the command interface is parsed as a command. Text stored in a document is treated as data. Even text submitted to the interface can select only predefined operations. And every state-changing operation requires authorisation. This is not a complete security architecture, but it demonstrates the principle. The same words can be harmless information in one context and operational instructions in another. The difference is not in the spelling. It is in the surrounding machinery. ## 10. Snow Crash: The Language That Infects Reality In 1992, Neal Stephenson published Snow Crash. The novel takes place in a fragmented future society dominated by corporations, private organisations and technological networks. Its protagonist, Hiro Protagonist, is a hacker and swordsman who moves between the physical world and a virtual environment called the Metaverse. At the centre of the story is a dangerous phenomenon called Snow Crash. It appears in both digital and biological contexts, combining ideas about software, language, religion, mythology and the manipulation of human consciousness. Stephenson connects the phenomenon to speculative theories about ancient languages, particularly Sumerian, and to a fictional mechanism through which linguistic structures can affect the human mind. The novel also imagines language operating rather like software capable of influencing or reprogramming people. Stephenson's official website describes the novel's origins and its significance in his career. ### What the novel imagines Snow Crash draws a parallel between three kinds of systems. A computer can execute instructions. A human being can respond to language. A society can organise behaviour through shared beliefs and institutions. Stephenson asks what might happen if these relationships were more closely connected than we ordinarily suppose. The result is a fictional world in which language can become a technological weapon. The idea is dramatically effective because it transforms words into something physically dangerous. The threat is not merely that a message persuades someone to act. It is that particular linguistic material may directly compromise cognition. This belongs to speculative fiction. ### Where the analogy stops Human language affects cognition and behaviour. Words can communicate threats, produce emotional responses, establish expectations and influence decisions. People can be persuaded, misled, reassured or frightened through communication. Language processing also depends on complex neural systems. However, these facts do not establish the existence of a universal linguistic program capable of directly reprogramming arbitrary human brains in the manner imagined by the novel. The ancient machine-code layer is part of the novel's fictional mechanism. This chapter supplies no neuroscientific evidence for it; the command interpreter cannot establish such a claim. Nor does the existence of computer viruses demonstrate that natural-language messages can infect brains through an equivalent mechanism. Computer malware exploits computational systems through specific software or hardware behaviours. Human cognition operates through biological processes that cannot simply be assumed to have the same vulnerabilities. Stephenson's fiction deliberately crosses those boundaries. It draws its energy from an analogy rather than a demonstrated scientific mechanism. ### Why the fiction still matters The novel's speculative premise is valuable because it asks readers to examine a genuine relationship. Language can influence systems. In computers, the influence can be formalised as executable instructions. In human institutions, the influence can arise through authority, shared rules and social practices. In human cognition, language can affect beliefs, memories and behaviour. These are real phenomena. But they do not operate through a single universal mechanism. The literary achievement of Snow Crash is to imagine that they might. It turns the resemblance into a fictional technological mythology. The scientific task is to distinguish the resemblance from the evidence. ## 11. Code, Magic and the Literary Imagination The idea that words can transform reality is much older than computers. Myths and folktales frequently describe magical names, spoken commands and secret formulas. A magician pronounces an incantation. A sealed door opens. A creature appears. A curse changes someone's fate. The power seems to reside in the utterance itself. Yet magical language often operates according to elaborate fictional rules. The speaker may need to know a secret name. The words must be pronounced correctly. The ritual may require a particular time or place. An unauthorised speaker may fail. The resemblance to a computer command is striking. A program may require exact syntax. A system may require authentication. A command may work only when the correct conditions are satisfied. But the resemblance does not establish that programming is literally a form of magic. Computer instructions operate through physical systems implementing formally specified behaviour. Magical incantations operate within the imagined causal structure of a fictional world. The comparison is literary. It shows how both forms of language can be represented as actions governed by rules. ### The author as lawgiver A fantasy author might invent a world in which speaking a true name allows someone to control a creature. A programmer might define an API in which a correctly formatted command changes a system's state. Both establish rules governing possible effects. But the author of the fantasy is not required to supply executable machinery. The reader accepts the rule as part of the fictional world. A programmer must implement the behaviour so that it occurs when the program runs. This distinction becomes especially interesting in computational fiction. A writer may describe a magical language and then create a working interpreter for it. Readers could type invented commands into a browser and observe their consequences in a simulated world. The fictional magic would become operational within the software. Not because supernatural powers had been discovered, but because the programmer had implemented the imagined rules. The text would now have two roles. It would contribute to the story's fictional meaning. And it would function as input to an executing system. This is one of the most promising meeting points between literature and programming. ## 12. When Context Changes Everything Return to the sentence: Open the door. Its meaning seems straightforward. But consider four situations. A character says it in a novel. A teacher uses it as an example of an imperative sentence. A visitor enters it into a command terminal. A caretaker with appropriate privileges enters it into the same terminal. The words are identical. Yet their functions differ. In the novel, they are part of a fictional conversation. In the classroom, they are an object of linguistic study. At the terminal, they may be interpreted as a command. And when entered by an authorised user, they may trigger a permitted operation. The consequences arise from context. This gives us a useful model: Effect = F(Text, Context, Rules, Authority) This is a conceptual formula, not a universal mathematical law of language. It simply reminds us that the effect of an utterance depends upon more than its words. The same principle helps explain why an instruction in a book does not ordinarily cause a computer to act. The book is being read as literature. The code may be present as text, but it is not necessarily being executed. To execute it, some additional system must recognise it as instructions and provide an appropriate environment. ### The boundary between the written and the executable This boundary is central to the second part of The Literary Machine. In Chapter Five, we examined concealed messages and the mathematical representation of information. In Chapter Six, we compared the structures of stories and computer programs. Now we have examined how language can participate in actions. The progression reveals three distinct relationships between text and machines. A text can be data, something the machine stores or processes. A text can be instructions, specifying operations that a machine may perform. Or a text can be part of a social act, acquiring consequences through human institutions and conventions. A single sentence can occupy different roles in different circumstances. But the roles should not be confused. The existence of meaningful words does not guarantee executable behaviour. The existence of executable behaviour does not guarantee human understanding. And the ability to perform an action does not automatically establish the authority to perform it. These distinctions are essential both to the philosophy of language and to the responsible design of software. ## 13. The Machine That Refused to Obey Mara returned to the Archive the following morning. This time, she had been given permission to inspect the records. The caretaker handed her a temporary identification card. She approached the terminal. `OPEN ARCHIVE` The door opened. Inside, she discovered a second terminal containing records of the Archive's construction. One document included instructions for operating its security system. Another described the organisation's authority structure. A third contained a fictional dialogue between an ancient scholar and an artificial intelligence. The scholar asked: "Can you understand my commands?" The machine replied: "I can recognise them." "Can you obey them?" "Only when permitted." "Then you are not truly intelligent." The machine considered the accusation. "Would intelligence require me to obey every instruction?" The scholar had no immediate answer. Mara smiled. The dialogue was only a story. But it captured something important. A system's ability to understand a request does not determine whether fulfilling it is appropriate. A human being can understand an unlawful order and refuse it. A software system can recognise a valid command and reject it because the requester lacks permission. These cases are not morally identical. The human may reason about obligations, intentions and consequences. The software may simply apply an access-control policy. Nevertheless, the structural resemblance is significant. Both distinguish comprehension from compliance. And as increasingly capable artificial intelligence systems become connected to real-world tools, that distinction grows more important. A system may be able to understand thousands of different instructions. It may possess the technical capacity to perform many of them. But those capabilities do not imply that every request should be executed. The machinery must still respect the boundaries within which it operates. ### The power is in the system We began with a locked door and a command that failed. The words were correct. But the speaker lacked authority. By the end of our investigation, we have encountered promises, legal declarations, programming-language semantics, command interpreters, authorisation systems and fictional linguistic weapons. The lesson connecting them is simple but profound. Words can participate in changing reality, but their effects arise through the mechanisms and institutions that recognise and act upon them. A promise creates obligations through human practices. A declaration may change a legal relationship through institutional authority. A program changes computational state through execution. A command may operate machinery through authorised software and physical mechanisms. Literature can imagine worlds in which words possess even greater powers. But the imaginative possibility should not be confused with scientific evidence. This understanding gives us a new way to think about the relationship between books and programs. A conventional novel may describe a machine that responds to secret words. An illustrated book may print those words for the reader to examine. But an interactive digital work could contain the interpreter itself. The reader could enter the words and observe what happens. The literary object would no longer consist only of descriptions. It would contain behaviour. And that leads directly to our next question. What happens when a book contains executable code as part of its literary structure? ## Questions to Take Away 1. What is the difference between describing an action and performing an action through language? 2. Why does a judge's declaration have different consequences from the same words spoken by an unauthorised spectator? 3. How does Austin's idea of a successful speech act resemble the conditions required for executing a computer command? 4. Why must a command interpreter distinguish between valid syntax and permission to perform an operation? 5. Can a program correctly execute an instruction without understanding the human meaning of the instruction? 6. Why should text found inside a document not automatically be treated as an instruction to the software reading it? 7. What makes Snow Crash an interesting literary investigation of language and power, even though its central linguistic mechanism is speculative? 8. If an artificial intelligence accurately understands a user's request, what additional conditions should be satisfied before it performs a consequential action? 9. Can a fictional magical language become a real executable language within a computer simulation? 10. Does the ability to execute a command give a machine authority, or merely capability? ## A Small Experiment: The Authorised Spell This experiment extends our fictional Archive's command language. Imagine that a character has discovered a book containing three apparent spells: `LOOK ARCHIVE` `OPEN ARCHIVE` `CLOSE ARCHIVE` Within the story, these words appear to control a mysterious door. But we know that their effects come from a command interpreter. ### Step 1: Establish the initial state The Archive is closed. The visitor may use only `LOOK`. The caretaker may use all three commands. Write down the initial condition: ```text archive_open = False ``` ### Step 2: Predict the results Consider these requests in order. | Role | Command | | --- | --- | | visitor | `LOOK ARCHIVE` | | visitor | `CLOSE ARCHIVE` | | caretaker | `OPEN ARCHIVE` | | visitor | `LOOK ARCHIVE` | | caretaker | `CLOSE ARCHIVE` | | caretaker | `OPEN VAULT` | Before reading the answer, decide whether each request is valid, authorised and capable of changing the state. ### Step 3: Examine the worked results | Step | Syntax valid? | Authorised? | Result | Final state | | --- | --- | --- | --- | --- | | 1 | Yes | Yes | `CLOSED` | Closed | | 2 | Yes | No | `ACCESS DENIED` | Closed | | 3 | Yes | Yes | `ARCHIVE OPENED` | Open | | 4 | Yes | Yes | `OPEN` | Open | | 5 | Yes | Yes | `ARCHIVE CLOSED` | Closed | | 6 | No | Not evaluated | `INVALID COMMAND` | Closed | Notice that step 2 is rejected even though the Archive is already closed. The authorisation check occurs before the program applies the command's operational effect. Step 6 fails before authorisation is evaluated because `VAULT` is not part of the defined language. ### Step 4: Introduce a quotation Suppose a historical document inside the Archive contains the sentence: The ancient caretaker once spoke the words OPEN ARCHIVE. Should reading the document cause the door to open? No. The words occur as data, not as a command submitted through the authorised command interface. This distinction is essential to preventing a system from confusing material it is supposed to read with instructions it is supposed to obey. ### Step 5: Invent a new command Add a fictional command: `COUNT ARCHIVE` Its purpose is to report the number of records in the Archive without changing anything. Decide: - Whether visitors should be permitted to use it. - Whether it should work when the Archive is closed. - What information it should return. - Whether it requires additional state. Write a short description of its syntax, permission requirements and behaviour. Do not execute arbitrary user-supplied code. Treat this as a design exercise using the fixed command language. ### The deeper question Imagine that the caretaker gives Mara a book containing every possible command. Does possessing the book give her control over the Archive? No. Knowing the words does not automatically supply authorisation. The book provides knowledge. The interpreter provides a mechanism. The institution determines permission. The experiment demonstrates that executable effects depend on more than textual meaning. They require interpretation, a defined operating environment and appropriate authority. ## Further Reading ### Philosophy of Language J. L. Austin — How to Do Things with Words (1962) The foundational work on performative utterances, speech acts and the conditions under which linguistic actions succeed or fail. The lectures were delivered at Harvard in 1955 and published posthumously. [Oxford University Press — Official edition](https://academic.oup.com/book/5162) Stanford Encyclopedia of Philosophy — Speech Acts A scholarly introduction to locutionary, illocutionary and perlocutionary acts, including the role of convention, authority and context. [Read Speech Acts](https://plato.stanford.edu/entries/speech-acts/) ### Fiction and Literary Speculation Neal Stephenson — Snow Crash (1992) A cyberpunk novel connecting software, virtual reality, ancient languages and speculative mechanisms of cognitive control. Its central linguistic mechanism should be understood as fiction, not established neuroscience. [Neal Stephenson — Official author page](https://www.nealstephenson.com/snow-crash.html) [Penguin Books — Official edition and description](https://www.penguin.co.uk/books/20868/snow-crash-by-stephenson-neal/9780241629833) Neal Stephenson — In the Beginning... Was the Command Line (1999) A nonfiction essay exploring operating systems, command-line interfaces, graphical computing and the cultural meanings of software interaction. [Neal Stephenson — Official author website](https://www.nealstephenson.com/) ### Programming Languages Python Software Foundation — Python Language Reference The official documentation of Python syntax, execution rules, expressions and statements. [Python Language Reference](https://docs.python.org/3/reference/) Python Software Foundation — Lexical Analysis Explains how source code is divided into tokens and interpreted according to the language's formal lexical rules. [Python Lexical Analysis](https://docs.python.org/3/reference/lexical_analysis.html) Python Software Foundation — Compound Statements Explains conditional execution, loops, exception handling and other constructions that control program behaviour. [Python Compound Statements](https://docs.python.org/3/reference/compound_stmts.html) ### Suggested Reading Order Begin with Austin's examples of promises, declarations and institutional speech acts. Then examine a few pages of the Python language reference, paying particular attention to the distinction between valid syntax and actual execution. Read Snow Crash with those distinctions in mind. Whenever the novel describes language operating directly upon minds, ask whether the mechanism is established science, technological analogy or deliberately speculative world-building. The most valuable insight is not that language and software are identical. It is that both can acquire effects through systems of rules—and that understanding those systems is essential to understanding the power of words. ## Up Next — The Book That Contains a Program Source Code as a Literary Device We have now encountered a remarkable possibility. Words can describe actions. Words can participate in social and institutional acts. And words written in programming languages can specify operations performed by computers. But what happens when a novel includes actual source code? A detective might discover a program that conceals a confession. A science-fiction story might include instructions for an imaginary machine. A poem might contain code whose execution produces a second poem. A book might invite the reader to run a program in order to understand its ending. In Chapter Eight, we will examine the relationship between source code and literary text. We will distinguish code printed as decoration, code used as evidence, code that contributes to characterisation and code that actually changes how a literary work functions. We will also explore the idea that a program can be read in two different ways. One reading concerns what the code says to a human. The other concerns what the code causes a computer to do. Sometimes those readings reinforce each other. Sometimes they contradict each other. And sometimes the difference between them becomes the story itself. Can a book contain a second story that exists only when its code is executed?