Sign

What Sign is trying to be

The README describes Sign as a language for expressing the integrity of data evaluation in a generic way. It is designed for uses such as data validation, integrity checks, and what the README calls functional effects. The project presents itself as a notation first, with a manifesto, examples, a language reference, and a specification, each available in English and Japanese. The concept view in the README uses two Mermaid diagrams to show the shape of the language: one graphs a Lambda world of identity and void against an Object world of numbers, letters and lists, with Apply and Partial as the two outcomes, and another graphs the duality between syntax and semantics, list and lambda, stack and stream, literal and operator, compilation and interpretation. These diagrams are the README main attempt to explain the model. The text is short and somewhat abstract, so a reader gets the outline of a typed notation for integrity rather than a finished product, and the README points to separate documents for the real detail instead of spelling everything out inline. The framing suggests a formal system where data correctness is expressed as a first class construct rather than as scattered checks. The pitch is that integrity becomes a first class construct in the notation instead of a set of checks scattered through application code.

Documents and reference material

The repository is organized around linked documents rather than a single long explanation. The README lists a manifesto in English and Japanese, a language example in both languages, a language reference in both languages, and a specification folder in both languages. There is also a license document for the language itself, again in English and Japanese. This bilingual layout suggests the author expects an international audience and wants the notation to be readable without translation tools. The reference and specification files are where the concrete syntax and semantics would live, since the README only sketches the ideas. The presence of a formal specification folder indicates the project aims to be precise and checkable, not just a loose idea. A reader who wants to know exactly how a rule is written or how evaluation proceeds must open those documents, because the README intentionally stays at the level of pointers and diagrams rather than exhaustive definitions. That structure is common for language designs where the specification is the source of truth and the README is only an invitation to read it. A reader who wants precise syntax must open the specification, because the README is only an invitation to read the fuller documents.

The playground and interpreter

The README points to a playground living in the alpha/javascript folder, described as the interpreter currently under development. The pipeline runs from a lexer through Pass1, Pass1b, Pass2 and Pass3 into an interpreter, and the README says this is the place to try the language as it behaves today. Setup instructions cover Windows users with an install script that can auto install Node.js, and other users with npm scripts or shell scripts for macOS, Linux and Git Bash. Running the playground starts a local server at http://localhost:5183 and opens the default web browser. The README warns that if you edit the official grammar file, you must rebuild the parser with a specific npm command or the change will not appear in the playground. This detail shows the project is real code, not only documents, even though it is early and the interpreter is explicitly labeled as under development in the alpha stage. The build steps also reveal that the grammar is written in a pegjs file, which is the formal source the parser generator consumes. The build steps show the grammar is written in a pegjs file, which is the formal source the parser generator consumes before the interpreter runs.

Maturity and what to expect

Sign is an early stage project. The README frames the language as a way to express integrity generically, but the prose is thin and the real content lives in external spec and reference files that the README only links to. The interpreter exists in an alpha folder and is described as under development, with a lexer and several passes already named. A newcomer should expect to read the specification and reference documents to understand the notation, then use the playground to experiment. The bilingual manifesto and examples suggest the author cares about clarity and reach. There is no claim of stability, versioning, or a finished toolchain, and the license for the language is presented as its own document rather than a standard single license file. For someone evaluating the project, the honest summary is that Sign is a notation design with a working draft interpreter and a set of supporting documents, useful to study but not yet a mature validation library. The playground is the fastest way to see the language run, while the specification remains the authority on meaning. The project is hosted at github.com/johnny-shaman/Sign and its most recent commit was on 2026-08-26. For evaluation purposes the project is best seen as a language design with a draft interpreter and a set of supporting papers rather than a finished library.

Editorial conclusion

The Sign project is a language for expressing data integrity checks, and it is hosted at github.com/johnny-shaman/Sign with its most recent commit on 2026-08-26.