TL;DR: Engineers building language tools can learn how to make translation decisions easier to inspect and improve. Pyash’s history shows one project moving from the goal of a human-speakable programming language to a pipeline that records word meaning, grammatical roles, sentence order, and recoverable work as separate steps. The pattern is useful anywhere software transforms language and people need to understand what happened at each step.

A language idea with a long prehistory

The Pyash story begins well before the repository that holds its current implementation. In the author’s account, work on a human-speakable programming language started during school and continued afterward. The dated record places the earliest clear milestones in 2007: a January entry describes making Lojban into a programming language, and a May entry describes development of a speakable programming language.

Names and experiments changed over the years. HSPL appears in 2013; SPEL and mwak appear in 2015; troclyash and troclyac appear in March 2016; and Pyash appears in June 2016. An October 2016 experiment called SPAL was compiled to OpenCL. These are milestones in the author’s project history. They explain the long-running interest behind Pyash, while the current repository provides its own engineering timeline beginning in November 2025.

That distinction gives readers a useful way to follow the project: first the goal of a language people can speak, then the current codebase’s steps toward making language structure executable and translation inspectable.

Build an executable language foundation

The current repository’s early work joined language structure to a running system. A November 2025 change brought together a unified memory layer and an asynchronous verb dispatcher. Work on compositional cases followed, giving sentence parts a structured way to express their relationships. On November 22, commits added speakable names and verbs and treated “evoke sentences” as the system’s execution ground. The repository history records the runtime foundation, while the speakable-name and verb work and the sentence-centered architecture show how it connected to language forms.

The engineering shift matters because a sentence could now serve as more than text displayed to a person. The runtime could work with structured language elements: names, verbs, cases, and executable actions. A case marks the role or relationship a word has in a sentence, such as an actor, recipient, or instrument. That gave later translation work a stable place to connect language-specific rules to the system’s internal representation.

Add explicit paths between languages

In January 2026, the project organized translation into adapters: modules that handle the rules for a particular language. The repository added translation pairs and examples for English, Russian, French, Chinese, Hindi, and Interlingua. Interlingua also served as a Spanish alias. The adapter refactor and the multilingual pair work mark this move toward language-specific paths that can be maintained and checked separately.

The test inventory gives the work a concrete scope. It includes adapter, translation-pair, template, parser-fallback, and round-trip tests for current examples. The examples cover commands such as writing, reading, and arithmetic; simple text, number, Boolean, date, and vector values; and basic map and ceremony markers. A round-trip test sends a test sentence through translation and back, then checks whether the result matches the expected vector. These checks help pinpoint behavior in a known example; broader translation quality remains a separate measurement question. The project’s translation parity notes list the tested examples and language paths.

For engineers, the transferable idea is to keep each language path explicit. When a test changes, a named adapter or pair gives the team a clear place to inspect the rule and its expected result. The chronology also shows the project moving from the question “How can this language run?” to “How can one sentence pass through several language systems with each transformation visible?”

Separate meaning from grammar and word order

In October 2026, Pyash’s translation architecture gained a shared representation between source language and output language. The project calls this VLIW, short for “Very Long Instruction Word.” In processor design, the term describes a wide instruction that can encode several operations. In Pyash, it names a structured representation that carries language and instruction details through the translation system.

The project also introduced a semantic facade, a kind of intermediate representation. An intermediate representation is a structured form that software can inspect and transform between a person’s input and a final output. The Pyash VLIW record carries markers for phrase, case, verb, mood, and continuation. The VLIW design, semantic facade, and general translation pipeline establish the structure. Later changes separated a word’s gloss—the meaning used inside the system—from the spoken or written surface form, and routed translation through algorithmic lowering into Pyac. That separation lets a developer examine meaning, grammatical role, and target-language ordering as related but distinct decisions.

The documented translation flow can be read as a sequence:

  1. Split the source text into sentences.
  2. Analyze grammar and known vocabulary using deterministic rules.
  3. Use sentence context and WordNet evidence to narrow ambiguous word senses.
  4. Preserve selected meanings and grammatical roles in the translation record.
  5. Apply phrase and target-language ordering rules.
  6. Lower the structured result into Pyac/VLIW output and save the catalog and pack.

This is useful to language-tool builders because it gives each transformation a place to record its inputs and outputs. A changed word choice can be examined separately from a changed word-order rule. The translation specification describes the stages and the artifacts they produce. Its source-to-VLIW refinery separates sentence segmentation, language translation, WordNet refinement, vocabulary review, catalog rendering, and Pyac lowering. The translation catalog preserves the durable source record; the VLIW catalog and binary Pyac pack contain sentences that lower successfully. That gives a developer useful checkpoints for tracing a sentence through the system.

Use context to narrow word meanings

English words often have several meanings. WordNet is a lexical database that groups words by meaning into synonym sets, called “synsets,” and connects those sets through semantic relationships. It also provides definitions and example sentences. Princeton’s WordNet overview explains this structure.

Pyash uses WordNet as read-only evidence for terms that remain ambiguous after existing vocabulary and deterministic grammar checks. The source analyzer first applies grammar surfaces, conservative morphology, existing Pyash words and compounds, and known sentence constructions. For a remaining English word, WordNet supplies part of speech, synset, gloss, and related-word evidence. Context from a nearby sentence window can narrow candidates by comparing neighboring words with a sense’s gloss and lemmas. A unique positive match narrows the candidate set; tied or unmapped cases remain available for review. A bounded reviewer can select only from the supplied inventory, and accepted evidence can be recorded as a sense-specific lexical bridge. The system’s translation specification describes how these steps work together.

This problem appears across machine translation: the right translation of an ambiguous word can depend on information elsewhere in the sentence or document. For example, research on salient document context for word-sense disambiguation in neural machine translation studies how related context can improve lexical choices. Pyash follows its own documented method; the paper supplies broader context for why this engineering problem matters.

A paired language-work exchange from October 26 offers a small, concrete example of the distinction between finding possibilities and choosing one. The session reported 17 candidate WordNet senses for “demonstrate”; the model’s contextual choice still needed a completed test. The author asked for that test before treating the choice as established. That exchange captures a valuable practice for any AI-assisted language tool: record candidate generation, selected answer, and test result as separate evidence.

The same period added phrase-level grammar. A head-final phrase places its main word after its modifiers, a pattern familiar from languages such as Japanese and Turkish. Pyash added phrase-VLIW routing and rules for constructions including existential statements and genitive phrases, which express ownership or relationships. These steps carry grammatical roles into a language’s ordering rules, so a translation can preserve who did what to whom as surface words move into place. Repository commits from October 22–24 record the instruction format, semantic facade, general translation operation, Pyac reverse path, and algorithmic lowering; the following days add contextual sense handling, checkpoints, and phrase rules. That sequence shows an architecture growing in response to the next layer of work: first represent sentence meaning, then make word choice and phrase order explicit.

Make large translation jobs recoverable

Word-sense and compound processing can involve many records, so the project added a source-to-VLIW refinery with durable checkpoints. A checkpoint is a saved intermediate result that lets a long-running task continue from recorded progress. An artifact-first workflow keeps those intermediate files available as the durable record for later stages.

In November, the project added a resumable WordNet sense sweep and an all-atom coverage ledger. A coverage ledger tracks which vocabulary items have been processed, helping developers see the extent of a batch and continue work in manageable steps. The ledger makes the difference between “the machinery exists” and “this particular vocabulary item has a recorded result” visible in the project artifacts. Later changes resumed synset work, guarded canonical-sense retries, rebalanced source languages, and exposed canonical compounds through the kwon interface. The resumable sweep and coverage ledger show how the project made bulk vocabulary work easier to track and resume.

The practical benefit reaches beyond translation. Any large transformation—document conversion, code migration, data cleanup, or media processing—can become easier to recover when each stage saves a meaningful result and records its coverage. A restart can use the saved work as evidence of progress instead of beginning the whole batch again.

A pattern other language tools can borrow

Pyash’s history suggests a practical design for language software. Keep lexical decisions tied to their context and candidate evidence. Preserve grammatical roles before applying target-language word order. Test each adapter with examples that reflect its real scope, and keep round-trip checks tied to specific expected inputs and outputs. Save intermediate artifacts and coverage records when processing can take a long time.

That structure gives engineers useful places to inspect a result: the source sentence, the candidate meanings, the chosen sense, the grammar representation, the ordering rule, and the final output. A language tool becomes easier to improve when those choices remain visible as the system grows. Pyash’s long path—from a speakable-language idea to adapters, contextual vocabulary work, and resumable translation—shows how that structure can accumulate one engineering layer at a time.

Project: Pyash on GitLab

Further reading: Translation specification · Translation parity notes · Princeton WordNet · Context and word-sense disambiguation research