Compare commits

...

No commits in common. "v0.1-alpha" and "main" have entirely different histories.

323 changed files with 7862 additions and 219 deletions

78
.editorconfig Normal file
View file

@ -0,0 +1,78 @@
# EditorConfig is awesome: https://EditorConfig.org
# top-most EditorConfig file
root = true
# Universal settings
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space
indent_size = 4
# Java files
[*.java]
indent_size = 4
continuation_indent_size = 8
# ANTLR grammar files
[*.g4]
indent_size = 4
# MPL source files
[*.mpl]
indent_size = 2
# Ensure Unicode is preserved
charset = utf-8
# Markdown files
[*.md]
trim_trailing_whitespace = false
indent_size = 2
# YAML files
[*.{yml,yaml}]
indent_size = 2
# JSON files
[*.json]
indent_size = 2
# XML files
[*.xml]
indent_size = 2
# Gradle files
[*.gradle]
indent_size = 4
# Shell scripts
[*.sh]
indent_size = 2
# Batch files
[*.bat]
end_of_line = crlf
indent_size = 2
# Makefiles
[Makefile]
indent_style = tab
# Git config files
[.git*]
indent_size = 2
# GitHub Actions
[.github/workflows/*.yml]
indent_size = 2
# LaTeX files (for whitepaper)
[*.tex]
indent_size = 2
# Properties files
[*.properties]
indent_size = 4

13
.github/FUNDING.yml vendored Normal file
View file

@ -0,0 +1,13 @@
# These are supported funding model platforms
github: [developtheweb]
patreon: # Replace with up to 4 Patreon usernames
open_collective: # Replace with a single Open Collective username
ko_fi: # Replace with a single Ko-fi username
tidelift: # Replace with a single Tidelift platform-name/package-name
community_bridge: # Replace with a single Community Bridge project-name
liberapay: # Replace with a single Liberapay username
issuehunt: # Replace with a single IssueHunt username
otechie: # Replace with a single Otechie username
lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name
custom: # No custom donation links yet

50
.github/ISSUE_TEMPLATE/bug_report.md vendored Normal file
View file

@ -0,0 +1,50 @@
---
name: Bug report
about: Create a report to help us improve MPL
title: ''
labels: bug
assignees: ''
---
**Describe the bug**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior:
1. Write MPL code '...'
2. Run command '....'
3. See error
**MPL Code**
```mpl
# Paste your MPL code here
```
**Expected behavior**
A clear and concise description of what you expected to happen.
**Actual behavior**
What actually happened instead.
**Error messages**
```
Paste any error messages here
```
**Environment (please complete the following information):**
- OS: [e.g. Ubuntu 22.04, Windows 11, macOS 13]
- Java Version: [e.g. OpenJDK 11.0.17]
- MPL Version: [e.g. 2.0.0]
- Terminal/IDE: [e.g. VS Code, IntelliJ IDEA]
**Additional context**
Add any other context about the problem here.
**Symbol Display**
- [ ] I can see mathematical symbols correctly in my environment
- [ ] I tried using ASCII escapes (e.g., `\sum` instead of ∑)
**Checklist**
- [ ] I have searched existing issues for duplicates
- [ ] I have provided a minimal code example
- [ ] I have included all error messages

View file

@ -0,0 +1,42 @@
---
name: Feature request
about: Suggest an idea for MPL
title: ''
labels: enhancement
assignees: ''
---
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
**Does this feature pass the Fatima Test?**
Would a 10-year-old non-English speaker understand this feature? Please explain why.
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Proposed syntax (if applicable)**
```mpl
# Show how the feature would look in MPL code
```
**Mathematical basis**
If proposing a new symbol or operator:
- What mathematical concept does it represent?
- Is there established notation for this?
- What would be the ASCII escape sequence?
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
**Additional context**
Add any other context, mockups, or examples about the feature request here.
**Impact on education**
How would this feature help students learning to program?
**Checklist**
- [ ] This feature aligns with MPL's mission of cognitive universality
- [ ] I've considered how non-English speakers would understand this
- [ ] I've searched existing issues for similar requests
- [ ] The proposed syntax uses mathematical notation, not English keywords

56
.github/PULL_REQUEST_TEMPLATE.md vendored Normal file
View file

@ -0,0 +1,56 @@
## Description
Brief description of what this PR does.
## Motivation and Context
Why is this change required? What problem does it solve?
If it fixes an open issue, please link to the issue here.
Fixes #(issue)
## How Has This Been Tested?
Please describe the tests that you ran to verify your changes:
- [ ] All existing tests pass
- [ ] Added new tests for new functionality
- [ ] Tested with example programs
- [ ] Tested with different input methods (visual, keyboard, ASCII escapes)
## Types of changes
What types of changes does your code introduce? Check all that apply:
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Documentation update
- [ ] Grammar modification
- [ ] New symbol/operator
## Checklist
- [ ] My code follows the code style of this project
- [ ] My change requires a change to the documentation
- [ ] I have updated the documentation accordingly
- [ ] I have added tests to cover my changes
- [ ] All new and existing tests passed
- [ ] I have updated CHANGELOG.md in the Unreleased section
- [ ] My changes pass the Fatima Test (understandable by non-English speakers)
## MPL-Specific Considerations
### For new symbols/operators:
- [ ] Symbol has clear mathematical meaning
- [ ] ASCII escape sequence provided
- [ ] Added to glyph-escapes.md
- [ ] Precedence defined and tested
- [ ] Example usage provided
### For grammar changes:
- [ ] No shift/reduce conflicts introduced
- [ ] Precedence table updated if needed
- [ ] Backwards compatibility maintained
## Additional Notes
Any additional information that reviewers should know.

77
.github/workflows/ci.yml vendored Normal file
View file

@ -0,0 +1,77 @@
name: CI
on:
push:
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Check out
uses: actions/checkout@v4
- name: Set up JDK 21
uses: actions/setup-java@v4
with:
distribution: temurin
java-version: '21'
# ANTLR runs with -Werror (see build.gradle), so any grammar warning
# — including 184, token shadowing — fails this step.
- name: Build grammar and compile
run: ./gradlew build -x test
- name: Run tests
run: ./gradlew test
- name: Parse all examples
run: ./gradlew parseExamples
interpreter:
runs-on: ubuntu-latest
steps:
- name: Check out
uses: actions/checkout@v4
- name: Set up Node 24
uses: actions/setup-node@v4
with:
node-version: '24'
- name: Run interpreter tests
run: node --test "js/test/*.test.mjs"
conformance:
runs-on: ubuntu-latest
steps:
- name: Check out
uses: actions/checkout@v4
- name: Set up JDK 21
uses: actions/setup-java@v4
with:
distribution: temurin
java-version: '21'
- name: Set up Node 24
uses: actions/setup-node@v4
with:
node-version: '24'
# Gates on ratified entries only. Exits 0 vacuously while nothing is
# ratified — unratified observations must never become a CI gate.
- name: Ratified conformance corpus passes
run: node conformance/harness/run.mjs --ratified
# Locked decision: the corpus is downstream of the syntax truth. Every
# program must parse, except must-reject entries whose expected error
# is parse-class — the grammar rejects those too (verified in C3).
- name: Grammar accepts every runnable corpus program
run: |
runnable=$(for d in conformance/corpus/*/; do
if [ -f "${d}expected.out" ]; then echo "${d}program.mpl"
elif ! grep -qE '^err_(char|escape|string|comment|expect|unexpected|def_target|assign_target)$' "${d}expected.err"; then echo "${d}program.mpl"
fi
done | tr '\n' ' ')
./gradlew -q parseCheck --args="$runnable"

132
.gitignore vendored Normal file
View file

@ -0,0 +1,132 @@
# Gradle
.gradle/
build/
!gradle/wrapper/gradle-wrapper.jar
!**/src/main/**/build/
!**/src/test/**/build/
# IntelliJ IDEA
.idea/
*.iws
*.iml
*.ipr
out/
!**/src/main/**/out/
!**/src/test/**/out/
# Eclipse
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache
bin/
!**/src/main/**/bin/
!**/src/test/**/bin/
# VS Code
.vscode/
*.code-workspace
# macOS
.DS_Store
.AppleDouble
.LSOverride
._*
# Windows
Thumbs.db
ehthumbs.db
Desktop.ini
$RECYCLE.BIN/
*.lnk
# Linux
*~
*.swp
*.swo
.directory
# ANTLR
.antlr/
*.tokens
*.interp
**/generated-src/
# Java
*.class
*.jar
*.war
*.ear
*.nar
hs_err_pid*
# Logs
*.log
logs/
# Package Files
*.tar.gz
*.rar
*.zip
*.7z
*.dmg
*.iso
# Build outputs
target/
dist/
tmp/
temp/
# Test outputs
test-results/
test-output/
*.exec
*.coverage
# Documentation build
docs/_build/
docs/_site/
*.pdf
!whitepaper/*.pdf
# IDE specific
.nb-gradle/
.metadata
.recommenders
# MPL specific
*.mpl.compiled
*.mpl.cache
.mpl/
# Temporary files
*.tmp
*.bak
*~.nib
# Security
*.key
*.pem
*.p12
*.pfx
*.jks
.env
.env.local
.env.*.local
# User-specific files
local.properties
# Claude-specific (not committed)
CLAUDE.md
# Gradle wrapper (DO NOT IGNORE)
# The negation must come after *.jar above — the last matching rule wins.
!gradle/
!gradle/wrapper/gradle-wrapper.jar
!gradlew
!gradlew.bat

28
AUTHORS Normal file
View file

@ -0,0 +1,28 @@
# Authors
Mathematical Programming Language (MPL) was created and is maintained by:
## Project Creator & Lead Maintainer
* **Reverend Steven Milanese** (@developtheweb) - Project creator, language design, core implementation
## Contributors
Contributors will be added here as they make significant contributions to the project.
To be listed here, contributors should have:
- Made substantial code contributions, or
- Significantly improved documentation, or
- Contributed major features or bug fixes
## Special Thanks
- All the educators and students who believe in cognitive justice in programming education
- The open source community for tools and inspiration
---
For a complete list of contributors, see the git log:
```
git log --format='%aN' | sort -u
```

79
CHANGELOG.md Normal file
View file

@ -0,0 +1,79 @@
# Changelog
All notable changes to the Mathematical Programming Language (MPL) project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
### Added
- Gradle wrapper, so `./gradlew build` works from a fresh clone
- CI workflow: grammar build (ANTLR warnings are errors), tests, example parsing
- Documentation test: every ```mpl code block in README, spec and whitepaper must parse
- Canonical call syntax `f(a, b)` with nullary calls `f()`
- Wired-in operators: `≜` definition, `⊕`/`⊖` postfix resources, `⇀_ch`/`↽_ch` channels, `‧` module access, unary minus, `/` as ASCII alias of `÷`
- DECISIONS.md recording each design resolution with rejected alternatives
### Changed
- One canonical form per construct: guarded alternatives `(c ⟹ r) | fallback`, `✎` output, `↯pattern ⟹ expr` handler clauses, exactly one ASCII escape per glyph
- `;` has a single role (sequence separator, trailing permitted)
- Identifiers may no longer start with `_`, so subscripts lex correctly
- precedence.csv and glyph-escapes.md regenerated to match the grammar exactly
- README claims reduced to what CI verifies
- Comprehensive enterprise-level documentation structure
- AGPLv3 license for strong copyleft protection (changed from MIT)
- README transformed into moonshot vision document emphasizing cognitive justice
- Whitepaper updated to v2.0 with educational narrative focus
### Fixed
- Grammar compiles: removed mutual left recursion (errors 119/148) and shadowed tokens (warning 184)
- Generated parser package no longer declared twice
- Gradle finds the grammar (src/main/antlr4) and the ParseExamples main class
- Test harness uses CharStreams; supplementary-plane glyphs (𝔹, 𝓜, 🖫) now tokenize
- Examples 03 and 05 parse (canonical handler arrow; real placeholder body)
### Removed
- Dead tokens with no parser rule: `?` (QUERY), `∃`, `⇐`, `→`, `.`
- Juxtaposition function application (`f x`)
- C-style ternary and `📤` from all documentation
## [2.0.0] - 2025-01-26
### Added
- Complete ANTLR 4 grammar with 70+ mathematical operators
- Support for functional, imperative, concurrent, and object-oriented paradigms
- ASCII escape sequences for all Unicode symbols
- Comprehensive test suite with 663 lines of test code
- 10 example programs demonstrating real-world usage
- Academic whitepaper with technical specification
- Symbol reference guide (glyph-escapes.md)
- Operator precedence table
### Changed
- Moved from theoretical concept to working parser implementation
- Established Fatima Test as core design principle
### Fixed
- All M0 blocker issues resolved
- Zero shift/reduce conflicts in grammar
- Operator precedence validated through extensive testing
## [1.0.0] - 2024-12-15
### Added
- Initial concept and vision for Mathematical Programming Language
- Basic symbol set proposal
- Preliminary grammar sketch
- Mission statement for cognitive universality
---
## Version History Summary
- **2.0.0** - First working implementation with complete grammar
- **1.0.0** - Initial concept and vision
[Unreleased]: https://github.com/developtheweb/mpl/compare/v2.0.0...HEAD
[2.0.0]: https://github.com/developtheweb/mpl/compare/v1.0.0...v2.0.0
[1.0.0]: https://github.com/developtheweb/mpl/releases/tag/v1.0.0

56
CITATION.cff Normal file
View file

@ -0,0 +1,56 @@
# This CITATION.cff file was generated with cffinit.
# Visit https://bit.ly/cffinit to generate yours today!
cff-version: 1.2.0
title: Mathematical Programming Language (MPL)
message: >-
If you use this software, please cite it using the
metadata from this file.
type: software
authors:
- given-names: Steven
family-names: Milanese
email: developtheweb@protonmail.com
affiliation: Independent Researcher
orcid: 'https://orcid.org/0000-0000-0000-0000'
identifiers:
- type: url
value: 'https://github.com/developtheweb/mpl'
description: GitHub Repository
repository-code: 'https://github.com/developtheweb/mpl'
url: 'https://github.com/developtheweb/mpl'
repository-artifact: 'https://github.com/developtheweb/mpl/releases'
abstract: >-
Mathematical Programming Language (MPL) is a programming
language that achieves cognitive universality through
mathematical notation. By replacing English keywords with
mathematical symbols, MPL enables any child, regardless
of native language, to learn programming through the
universal language of mathematics. MPL supports
functional, imperative, concurrent, and object-oriented
paradigms while maintaining zero language barriers.
keywords:
- programming-language
- mathematical-notation
- cognitive-universality
- education
- unicode
- language-agnostic
- cognitive-justice
- universal-programming
license: AGPL-3.0
commit: 4893ac3
version: 2.0.0
date-released: '2025-01-26'
preferred-citation:
type: article
authors:
- given-names: Steven
family-names: Milanese
title: "Mathematical Programming Languages: Achieving Cognitive Universality Through Unicode-Based Syntax"
year: 2025
journal: "Proceedings of Programming Language Design and Education"
volume: 1
issue: 1
start: 1
end: 20

14
CODEOWNERS Normal file
View file

@ -0,0 +1,14 @@
# This file defines who owns what in this repository
# These owners will be requested for review when someone opens a pull request
# Global owners for everything
* @developtheweb
# Grammar and language design
*.g4 @developtheweb
*.mpl @developtheweb
# Documentation
*.md @developtheweb
/docs/ @developtheweb
/whitepaper/ @developtheweb

102
CODE_OF_CONDUCT.md Normal file
View file

@ -0,0 +1,102 @@
# Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in the Mathematical Programming Language (MPL) community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall community
* Using welcoming and inclusive language
* Being mindful of your language when referring to programming concepts (remember: not everyone speaks English)
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
* Dismissing or attacking contributions based on the contributor's native language or English proficiency
## Enforcement Responsibilities
Project maintainer Reverend Steven Milanese (@developtheweb) is responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
The project maintainer has the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the project maintainer at developtheweb@protonmail.com. All complaints will be reviewed and investigated promptly and fairly.
The project maintainer is obligated to respect the privacy and security of the reporter of any incident.
## Enforcement Guidelines
The project maintainer will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from the project maintainer, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of actions.
**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the community.
## MPL-Specific Guidelines
Given MPL's mission to break down language barriers in programming:
1. **Language Sensitivity**: Be especially mindful that contributors may not be native English speakers. Never mock or belittle someone's language skills.
2. **Cultural Awareness**: Respect that mathematical symbols may have different meanings or connotations in different cultures. Be open to discussion about symbol choices.
3. **Educational Focus**: Remember that MPL is designed for learners, including children. Keep all communications appropriate for all ages.
4. **Accessibility**: Consider that contributors may be using translation tools or assistive technologies. Be patient and clear in communication.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder][Mozilla CoC].
For answers to common questions about this code of conduct, see the FAQ at [https://www.contributor-covenant.org/faq][FAQ]. Translations are available at [https://www.contributor-covenant.org/translations][translations].
[homepage]: https://www.contributor-covenant.org
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
[Mozilla CoC]: https://github.com/mozilla/diversity
[FAQ]: https://www.contributor-covenant.org/faq
[translations]: https://www.contributor-covenant.org/translations
---
Remember: MPL exists to make programming accessible to everyone, regardless of their native language. Our community should reflect this inclusive mission in all our interactions.

220
CONTRIBUTING.md Normal file
View file

@ -0,0 +1,220 @@
# Contributing to Mathematical Programming Language (MPL)
First off, thank you for considering contributing to MPL! 🌍
MPL exists to break down language barriers in programming education. Every contribution, no matter how small, helps us move closer to a world where any child can learn to code using the universal language of mathematics.
## Table of Contents
- [Code of Conduct](#code-of-conduct)
- [How Can I Contribute?](#how-can-i-contribute)
- [Development Process](#development-process)
- [Style Guidelines](#style-guidelines)
- [Commit Message Guidelines](#commit-message-guidelines)
- [Pull Request Process](#pull-request-process)
- [Community](#community)
## Code of Conduct
This project and everyone participating in it is governed by the [MPL Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to [developtheweb@protonmail.com](mailto:developtheweb@protonmail.com).
## Project Leadership
MPL was created and is maintained by Reverend Steven Milanese (@developtheweb). All major design decisions and direction are set by the project creator.
## How Can I Contribute?
### 🐛 Reporting Bugs
Before creating bug reports, please check [existing issues](https://github.com/developtheweb/mpl/issues) as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible:
- **Use a clear and descriptive title**
- **Describe the exact steps to reproduce the problem**
- **Provide specific examples** (include MPL code snippets)
- **Describe the behavior you observed and what you expected**
- **Include system details** (OS, Java version, etc.)
### 💡 Suggesting Enhancements
Enhancement suggestions are tracked as [GitHub issues](https://github.com/developtheweb/mpl/issues). When creating an enhancement suggestion:
- **Use a clear and descriptive title**
- **Provide a step-by-step description of the suggested enhancement**
- **Provide specific examples to demonstrate the steps**
- **Describe the current behavior and expected behavior**
- **Explain why this enhancement would be useful** to MPL users
- **Consider the Fatima Test**: Would a 10-year-old non-English speaker understand this?
### 🔤 Adding New Symbols
When proposing new mathematical symbols:
1. **Justify the symbol choice** - Why this symbol for this operation?
2. **Check Unicode support** - Ensure the symbol is widely supported
3. **Provide ASCII escape** - Every symbol needs a fallback (e.g., `\lambda` for λ)
4. **Test precedence** - How does it interact with existing operators?
5. **Add examples** - Show real use cases
### 🌍 Translations and Localization
Help make MPL accessible in more languages:
- Translate documentation
- Create localized error messages
- Develop region-specific examples
- Write tutorials in your native language
### 📚 Improving Documentation
- Fix typos and improve clarity
- Add more examples
- Create visual guides
- Write tutorials for specific audiences
- Improve API documentation
## Development Process
### Setting Up Your Development Environment
1. **Fork the repository** on GitHub
2. **Clone your fork**:
```bash
git clone https://github.com/your-username/mpl.git
cd mpl
```
3. **Set up the upstream remote**:
```bash
git remote add upstream https://github.com/developtheweb/mpl.git
```
4. **Install dependencies**:
```bash
# Requires Java 11+
./gradlew build
```
### Making Changes
1. **Create a new branch**:
```bash
git checkout -b feature/your-feature-name
```
2. **Make your changes** following our style guidelines
3. **Add tests** for any new functionality
4. **Run the test suite**:
```bash
./gradlew test
```
5. **Update documentation** as needed
### Testing Your Changes
All changes must:
- Pass existing tests
- Include new tests for new features
- Maintain or improve code coverage
- Work with all input methods (visual, voice, keyboard)
## Style Guidelines
### Code Style
- **Java Code**: Follow standard Java conventions
- **MPL Examples**: Use clear, educational examples
- **Comments**: Write in plain language, avoid jargon
### Grammar Development
When modifying `MPL.g4`:
- Maintain zero shift/reduce conflicts
- Document any precedence changes
- Test with complex expressions
- Update `precedence.csv` if needed
### Symbol Guidelines
- Prefer universally recognized mathematical symbols
- Ensure symbols have semantic meaning
- Avoid symbols that conflict with common mathematical usage
- Always provide ASCII escapes
## Commit Message Guidelines
We follow strict commit message standards (see CLAUDE.md for full details):
### The 7 Golden Rules
1. **Separate subject from body** with a blank line
2. **Limit subject to 50 characters**
3. **Capitalize the subject line**
4. **Use imperative mood** ("Add feature" not "Added feature")
5. **Wrap body at 72 characters**
6. **Explain what and why**, not how
7. **Reference issues** (e.g., "Closes #123")
### Example
```
feat: Add matrix multiplication operator
Implement the ⊗ operator for matrix multiplication following
standard mathematical notation. This enables natural expression
of linear algebra operations in MPL.
- Add parser rules for ⊗ with correct precedence
- Implement type checking for matrix dimensions
- Add comprehensive test cases
- Update symbol reference documentation
Closes #123
```
## Pull Request Process
1. **Update documentation** - README.md, examples, and relevant docs
2. **Add tests** - Ensure your changes are covered
3. **Update CHANGELOG.md** - Note your changes in the Unreleased section
4. **Pass all checks** - Tests, linting, and build must succeed
5. **Get review** - The maintainer must approve
6. **Squash commits** - Keep history clean
### PR Title Format
Use the same format as commit messages:
- `feat: Add support for complex numbers`
- `fix: Correct precedence of ∑ operator`
- `docs: Add tutorial for educators`
### The Review Process
Reviews will check:
- **Correctness**: Does it work as intended?
- **Tests**: Are changes adequately tested?
- **Documentation**: Is it well documented?
- **Cognitive Load**: Does it pass the Fatima Test?
- **Compatibility**: Does it maintain backwards compatibility?
## Community
### Getting Help
- **GitHub Issues**: [github.com/developtheweb/mpl/issues](https://github.com/developtheweb/mpl/issues)
- **Email**: developtheweb@protonmail.com
### Recognition
Contributors are recognized in:
- The AUTHORS file
- Release notes
- Commit history
### License
By contributing to MPL, you agree that your contributions will be licensed under the GNU Affero General Public License v3.0 (AGPLv3).
---
## Summary
Remember: Every contribution to MPL helps break down barriers to programming education worldwide. Whether you're fixing a typo, adding a feature, or translating documentation, you're part of a movement for cognitive justice in technology.
**Thank you for helping us make programming truly universal! 🌍✨**

40
DECISIONS.md Normal file
View file

@ -0,0 +1,40 @@
# Design decisions
One line per decision, with the rejected alternatives named. Governing
principles, in order: One Right Answer, the Fatima test, minimal churn
against the existing examples.
- **Conditionals are guarded alternatives** `(condition ⟹ result) | fallback`, wired in as a `condExpr` precedence level; rejected: C-style ternary `cond ? a : b` (programmer convention, fails the Fatima test), standalone left-recursive `conditional` rule (ANTLR error 119).
- **Exception handling is a postfix operator** `expr ↴ { … }`; rejected: standalone `exceptionHandler` rule reachable from `atomExpr` (mutual left recursion, ANTLR error 119).
- **λ has one token, `LAMBDA_VAR`**, used both as a variable and to open a lambda; rejected: separate `LAMBDA` token (identical alternatives, fully shadowed, ANTLR warning 184).
- **`\implies` maps to ⟹ and `\Rightarrow` maps to ⇒** — one escape, one glyph; rejected: `\Rightarrow` as an alias of ⟹ (shadowed EXPORT's escape, ANTLR warning 184).
- **The Java package for generated code comes from `-package` in build.gradle only**; rejected: `@header` package declaration in the grammar (combined with `-package` it generates a duplicate `package` statement that does not compile).
- **ANTLR warnings fail the build** (`-Werror` in build.gradle); rejected: warnings as advisory output (they hid the shadowed-token bugs).
- **The choice-type rule is `⟨ expr ⟩`** with the interior `|` consumed by `condExpr`; rejected: explicit `⟨ expr | expr ⟩` (the interior expr already consumes the bar, making the explicit BAR unreachable).
- **Function calls are `f(a, b)` — a postfix argument list, nullary `f()` included**; rejected: Haskell juxtaposition `f x` (programmer convention, fails the Fatima test — children learn `f(x)` in school).
- **SEMICOLON has one role: sequence separator (trailing `;` permitted)**; the program, blocks, `(...)`, `⌈...⌉`, `...`, `⌜...⌝`, `⌞...⌟` and `⟳(...)` all contain one `seqExpr`; rejected: a separate statement-terminator rule duplicating the same token (two roles for one symbol).
- **Braces disambiguate structurally**: `IDENTIFIER :` → record, two-plus comma-separated exprs → set, everything else (incl. `{}` and `{x}`) → block; a singleton set literal cannot be written (deferred to M1); rejected: parser-order coin flips left undocumented.
- **`≜` defines, `←` assigns; both wired into the chain** with `≜` binding looser than `←`, both right-associative; rejected: `≜` tokenized but unreachable.
- **`⊕`/`⊖` are postfix resource operators** (`database ⊕`, `conn ⊖`), matching every example; rejected: prefix form `⊕open(path)` that appeared only in the whitepaper.
- **Channel operations are subscripted prefix operators** `⇀_ch expr` / `↽_ch expr`; rejected: leaving SEND/RECEIVE orphaned.
- **`‧` is qualified module access** (`Mathematics‧sin(angle)`), a postfix `‧IDENTIFIER`; rejected: leaving MIDDOT orphaned, or `.` (removed — one access syntax).
- **Handler clauses are `↯pattern ⟹ expr`, semicolon-separated**, where pattern is an identifier (binds the exception) or a string (matches a message); rejected: `↯e ⇒ expr` (⇒ is EXPORT; the clause arrow should mirror the guarded-alternative arrow ⟹).
- **IDENTIFIER may not start with `_`**, so subscripts (`⌉_db_lock`, `↽_socket`) lex as UNDERSCORE + IDENTIFIER; rejected: identifiers with a leading underscore (made every subscript lex as one identifier token).
- **`/` is an ASCII alias of ÷ (DIV)** so `π/4` parses; rejected: ÷-only division (unreachable on most keyboards).
- **Unary minus exists** (`-x`), sharing the MINUS token at prefix level; rejected: binary-only minus (cannot write negative numbers); unary plus was NOT added (`x ++ y` stays invalid).
- **`pathLiteral` accepts `🖫"…"` and `🖫identifier`**, as required by `readFile(🖫path)` in example 03.
- **Deleted tokens: `?` (QUERY), `∃` (EXISTS), `⇐` (IMPORT), `→` (ARROW), `.` (DOT)** — defined but used by no parser rule and no example; dead operators are debt; each returns in M1 only with a documented semantic. Rejected: keeping them tokenized-but-unreachable.
- **Exactly one ASCII escape per glyph** (`\lambda` not `\lam`, `\leftarrow` not `\gets`, `\neq` not `\ne`, `\nat` not `\N`, …); rejected: alias sets (two ways to write the same token).
- **`%` (modulo), `∑`, `√`, `²`, `|x|`, ranges `[a..b]`, indexing/slicing, `where`, and record field access are NOT in M0** — every document says so instead of using them; deferred to M1 with semantics, not smuggled in via prose.
- **Lambda parameters are a bare comma-separated pattern list** (`λa, b: body`); rejected: parenthesized parameter lists `λ(a, b):` (two ways to write parameters).
- **`‧` gets the escape `\middot`** so the "every glyph has an ASCII escape" claim stays true; rejected: leaving MIDDOT as the one escape-less glyph.
- **`glyph-escapes.md` and `precedence.csv` are the only symbol/precedence tables**; the whitepaper appendix points at them instead of duplicating them; rejected: parallel tables that drift (the old appendix disagreed with the lexer on several code points and escapes).
- **Documentation code blocks are fenced ```mpl only if they parse today**; M1+ sketches are fenced as plain text with an explicit "not yet parseable" caption, and a CI test enforces the rule for README, spec, and whitepaper.
- **Interpreter repatriation: `js/mpl.js` lives in this repo** as the single source of truth; mpl.codes consumes it by pinned commit SHA + sha256 checksum; rejected: making the site repo public as-is (splits truth across two repos), git submodule (invisible drift, clone friction).
- **Byte identity: repo file == image file == served file**, enforced by checksum at image build time and a post-deploy check; rejected: minified serving (a second artifact that can drift).
- **Interpreter tests run on `node:test` + `node:assert` with zero npm dependencies**; rejected: third-party test frameworks (a supply chain the site's own footer brags about not having).
- **Stage-1 exception: the imported interpreter's header comment was corrected in place** (`tested: 18/18` → the provable `10 tests in js/test/`) — a falsified claim inside the canonical artifact outranks byte identity with the pre-Stage-1 deploy; end-state identity is restored when the site deploys the pinned file.
- **Stage-3 ratification (2026-07-09): the 26 judgment calls are ruled; JUDGMENT_CALLS.md is the semantic record of MPL M0.** Per-ruling record: (1) ÷0 is `err_div0`; (2) a `∀` expression is always `⊥`; (3) an unmatched guard yields `⊥` unless caught by `|`; (4) numbers are exact rationals — BigInt num/den, lowest terms, den > 0, decimal literals exact, display `n` or `n/d` (re-evaluates to itself); IEEE doubles rejected; (5) `✎` rendering spec'd per type; (6) `⊥` is first-class, arithmetic on it `err_num`; (7) equality is structural on data, cross-type `=` false, `0.5 = 1/2` true, any function in `=`/`≠` raises `err_fn_eq`; (8) ordering is number×number and string×string (code-point) only, else `err_compare`; (9) closures capture the environment; (10) λ-application depth counter, limit 10000, `err_depth` — no keyless host error may remain reachable; (11) the 500000-step budget is an environment resource limit, not semantics — corpus entry 053 moved to js/test; (12) string escapes are exactly `\n \t \" \\`, anything else `err_escape` (grammar ESC amended to match); (13) guard conditions must be boolean, else `err_bool`; (14) `∧ ` short-circuit and demand booleans on evaluated operands (`err_bool`); (15) braces group, binders scope; (16) `≜` binds once per scope (`err_redef`; inner shadowing legal), `←` mutates an existing binding only (`err_unbound`); (17) type constraints parse, unenforced; (18) nullary `λ: e` admitted (grammar amended); (19) ```×`; (20) the empty program is valid; (21) `( seqExpr )` — the interpreter now implements it; (22) `∘` is composition, `(f ∘ g)(x…) = f(g(x…))`, non-function operand `err_notfn`; (23) set literals parse, evaluate to `err_notyet`; (24) record literals likewise; (25) `λ(a, b):` rejected everywhere; (26) `λ` is reserved — never an identifier — while other Greek letters remain identifiers.
- **Standing M1 decisions logged at ratification**: `√` vs (irrationals); an explicit local-binding construct (let/where); set semantics; record semantics; comprehension notation; `‖` parallel semantics.
- **Grammar-only surface gaps are on the record** (SURFACE.md "Grammar-only surface" section): `≈`/`` comparisons, `"""raw strings"""`, hex/binary/exponent literals, and `_` as a λ pattern all parse in the grammar and fail in the Stage-3 interpreter — Stage 4+ material, no ruling; `err_comment` is dead pending removal at the next legitimate interpreter change.
- **Ruling 12's enumeration governs string escapes**: the grammar's ESC fragment was narrowed to exactly `\n \t \" \\``\r`, `\0` and `\u{hex}` were removed from the grammar; they were never in the ratified set.

182
LICENSE Normal file
View file

@ -0,0 +1,182 @@
GNU AFFERO GENERAL PUBLIC LICENSE
Version 3, 19 November 2007
Copyright © 2007 Free Software Foundation, Inc. <https://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software.
The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, our General Public Licenses are intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
Developers that use our General Public Licenses protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License which gives you legal permission to copy, distribute and/or modify the software.
A secondary benefit of defending all users' freedom is that improvements made in alternate versions of the program, if they receive widespread use, become available for other developers to incorporate. Many developers of free software are heartened and encouraged by the resulting cooperation. However, in the case of software used on network servers, this result may fail to come about. The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public.
The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.
An older license, called the Affero General Public License and published by Affero, was designed to accomplish similar goals. This is a different license, not a version of the Affero GPL, but Affero has released a new version of the Affero GPL which permits relicensing under this license.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU Affero General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this License. Each licensee is addressed as "you". "Licensees" and "recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based on the Program.
To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices" to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work.
A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
The Corresponding Source for a work in source code form is that same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.
When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to "keep intact all notices".
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, "normally used" refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.
"Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, "control" includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To "grant" such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.
If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. "Knowingly relying" means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.
A patent license is "discriminatory" if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of the GNU Affero General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU Affero General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU Affero General Public License, you may choose any version ever published by the Free Software Foundation.
If the Program specifies that a proxy can decide which future versions of the GNU Affero General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.
Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS

673
README.md
View file

@ -1,42 +1,661 @@
# Mathematical Programming Language (MPL)
# Mathematical Programming Language (MPL) 🌍
**Breaking the last language barrier in technology**
![Version](https://img.shields.io/badge/version-0.1--alpha-blue)
![Status](https://img.shields.io/badge/status-pre--M0-orange)
<div align="center">
A programming language that maintains cognitive universality while supporting all modern programming paradigms through mathematical notation.
![Status](https://img.shields.io/badge/status-proof--of--concept-orange)
![Parser](https://img.shields.io/badge/parser-M0-brightgreen)
![Execution](https://img.shields.io/badge/M0%20core-runs-brightgreen)
![License](https://img.shields.io/badge/license-AGPLv3-blue)
## Quick Start
**∀ child ∈ world : canCode(child)**
[🎓 For Educators](#for-educators) | [💻 For Developers](#for-developers) | [🌍 For Humanity](#for-humanity)
</div>
---
## 🚨 Project Status: Proof of Concept
**The M0 core runs — with ratified semantics.** This repository contains the grammar, the parser, and the browser interpreter (`js/mpl.js`) that runs the M0 core today at [mpl.codes](https://mpl.codes). Its semantics are not folklore: every judgment call is recorded and ruled in [conformance/JUDGMENT_CALLS.md](conformance/JUDGMENT_CALLS.md), pinned by **89 ratified conformance tests** that gate CI, and a differential fuzzer holds the interpreter and the grammar to zero divergence. A native runtime beyond the browser core does not exist yet — building it is the next milestone, and contributors are welcome.
### What Works Today ✅
Every item below is enforced by [CI](.github/workflows/ci.yml) on every push:
- An ANTLR 4 grammar built from mathematical symbols that compiles with zero errors and zero warnings (warnings are treated as errors)
- All 10 [example programs](examples/) parse (`./gradlew parseExamples`)
- A test suite covering the lexer, the parser, the examples, and every ```` ```mpl ```` code block in this README (`./gradlew test`)
- An ASCII escape sequence for every Unicode symbol ([glyph-escapes.md](glyph-escapes.md))
- The M0 core executes with ratified semantics: 89 ratified conformance tests (`node conformance/harness/run.mjs --ratified`), exact rational arithmetic, and a recorded ruling for every semantic question ([conformance/JUDGMENT_CALLS.md](conformance/JUDGMENT_CALLS.md))
### What Doesn't Work Yet 🚧
- **No native runtime** - The M0 core runs in the browser interpreter (`js/mpl.js`); everything beyond it parses but does not run yet
- **No type checking** - Types are recognized but not validated
- **No standard library** - No built-in functions
- **No tooling** - Basic parser only
## Vision: Programming Without Language Barriers
In a world where 80% of humanity doesn't speak English, why should programming—the literacy of the 21st century—require it? MPL demonstrates that we can build programming languages using mathematical symbols that children already understand, making computational thinking accessible to billions previously excluded by language barriers.
**This is cognitive justice in action.**
---
## 🎯 The Fatima test
> "Why do I need to know English to write a program?" — Fatima, 10 years old, Cairo
Every design decision in MPL must pass one simple test: **Can a 10-year-old non-English speaker understand this?**
### Traditional programming
```python
# English required:
for n in [1, 2, 3, 4, 5]:
print(n * n)
```
### MPL - Universal understanding
```mpl
-- Mathematical symbols only:
∀ n ∈ [1, 2, 3, 4, 5] : ✎(n × n)
```
If Fatima can't understand it with her basic math knowledge, we redesign it. No exceptions.
---
## 🚀 Quick start journey
<div align="center">
### Choose your path
| 🎓 **Educator?** | 💻 **Developer?** | 🌍 **Changemaker?** |
|:---:|:---:|:---:|
| [See the Vision](#educational-vision) | [Technical Details](#technical-architecture) | [Why This Matters](#why-this-matters) |
| Imagine teaching without English | Help build the runtime | Support cognitive justice |
</div>
### Hello, world in 30 seconds
<table>
<tr>
<th>Traditional (English Required)</th>
<th>MPL (Universal)</th>
</tr>
<tr>
<td>
```python
print("Hello, World!")
```
</td>
<td>
```mpl
✎"Hello, World!"
```
## Repository Structure
</td>
</tr>
<tr>
<td>English words: print</td>
<td>Universal symbol: ✎ (output/trace)</td>
</tr>
</table>
- `math_prog_lang.md` - Complete language specification
- `ISSUE_M0_BLOCKERS.md` - Critical decisions needed before M0 implementation
- `glyph-escapes.md` - ASCII escape sequences for all Unicode glyphs
- `precedence.csv` - Operator precedence table
- `examples/` - Example programs from the specification
**Note**: This syntax is valid and parses. The M0 core runs in the browser interpreter at [mpl.codes](https://mpl.codes); features beyond the M0 core parse but do not run yet.
## M0 Milestones
---
1. ✅ Language specification consolidated
2. ✅ Pre-M0 audit completed
3. ✅ Lexical blockers resolved (see [ISSUE_M0_BLOCKERS.md](ISSUE_M0_BLOCKERS.md))
4. ⏳ Implement ANTLR 4 grammar
5. ⏳ Create test suite (500 LOC)
6. ⏳ Achieve M0 exit criteria
## 🔮 How it works
## M0 Exit Criteria
### For everyone
Write code using mathematical symbols instead of English words. It's that simple.
- [ ] Lexer round-trips every glyph via escape and direct entry
- [ ] Parser accepts all files in `examples/`
- [ ] `grmtools` (or ANTLR diagnostics) reports **0** ambiguities
- [ ] Fuzz seed (10k random tokens) yields no segfault
- [ ] Pretty-printer emits code that re-parses into identical AST
```
┌─────────────────────────────────────────────┐
│ Mathematical Notation │
│ λn: (n ≤ 1 ⟹ 1) | (n × fact(n-1)) │
└────────────────┬───────────────────────────┘
┌─────────────────────────────────────────────┐
│ Unicode Input │
│ (Visual palette, voice, keyboard) │
└────────────────┬───────────────────────────┘
┌─────────────────────────────────────────────┐
│ ANTLR 4 Parser │
│ Lexer → Parser → AST │
└─────────────────────────────────────────────┘
```
## Contact
### Five ways to write λ (lambda)
- GitHub: @developtheweb
- Email: developtheweb@protonmail.com
Today the parser accepts two spellings of every symbol: the Unicode glyph (λ) and its ASCII escape (`\lambda`). The rest are the input methods we envision tooling for:
1. **⌨️ Type** — `\lambda` (works today, in any editor)
2. **👆 Click** — Visual symbol palette (envisioned)
3. **🎤 Speak** — "Lambda" in ANY language (envisioned)
4. **✍️ Draw** — Handwriting recognition on tablets (envisioned)
5. **⚡ Shortcut** — Platform shortcuts (envisioned)
<details>
<summary>🔧 Technical details (click to expand)</summary>
### Unicode implementation
- Full Unicode support, including supplementary-plane symbols (𝓜, 𝔹, 🖫)
- Every glyph has exactly one ASCII escape ([glyph-escapes.md](glyph-escapes.md))
### Parser architecture
```
Input Methods → Unicode Stream → ANTLR 4 Lexer → Parse Tree
```
Type checking, optimization and code generation are planned, not built.
### Grammar specification
- Compiles with zero ANTLR errors and warnings (enforced in CI)
- Operator precedence documented in [precedence.csv](precedence.csv)
- [View full ANTLR grammar](src/main/antlr4/MPL.g4)
</details>
---
## ✨ Core features
### 🌐 Cognitive universality
**Mathematical symbols as humanity's common language**
- **No translation needed** — Math is already universal
- **Cultural neutrality** — No linguistic imperialism
- **Instant comprehension** — Symbols map to concepts directly
### 🎨 Multi-modal input (envisioned)
**Meet learners where they are**
Only ASCII escapes exist today; the rest is the tooling we want to build:
```
┌─────────────┬─────────────┬─────────────┬─────────────┐
│ Visual │ Voice │ Keyboard │ Handwriting │
│ Palette │ Input │ Escapes │ Recognition │
├─────────────┼─────────────┼─────────────┼─────────────┤
│ Click λ │ Say "lambda"│ Type \lambda│ Draw λ │
│ from menu │ in any lang │ (works now) │ on screen │
└─────────────┴─────────────┴─────────────┴─────────────┘
```
- **ASCII escapes**`\lambda`, `\forall`, … work in any editor today
- **Visual palette** — Click symbols like emoji (envisioned)
- **Voice input** — Speak in your native language (envisioned)
- **Handwriting** — Natural for mathematical notation (envisioned)
### 📈 Progressive complexity
**From arithmetic to algorithms**
```mpl
-- Level 1: Basic math (everyone knows this!)
x ≜ 5 + 3;
y ≜ x × 2;
-- Level 2: Logic (learned in school)
x > 10 ∧ y < 20 "Success!";
-- Level 3: Advanced (natural progression)
squares ≜ 0;
∀ n ∈ [1, 2, 3, 4, 5] : squares ← squares + n × n;
```
---
## 📊 Educational Vision
### The Problem We're Solving
Consider a hypothetical student, "Maria" from São Paulo:
- She loves math and logic puzzles
- She wants to learn programming
- But she must first memorize English keywords like `for`, `while`, `if`, `else`
- The Portuguese word "for" means "went" - adding confusion
- She spends more time translating than learning computational thinking
### What MPL Could Enable (Vision, Not Reality)
With MPL fully implemented, we envision students could:
- Write their first program in minutes using familiar mathematical symbols
- Focus on logic and problem-solving, not foreign vocabulary
- Learn alongside parents who also don't speak English
- Build confidence through immediate understanding
### Hypothetical Benefits We Aim For
If MPL were fully implemented and deployed in classrooms, we hypothesize it could achieve:
| Potential Metric | Traditional Approach | MPL Vision |
|-----------------|---------------------|------------|
| Time to understand loops | Days of memorizing `for` | Minutes with ∀ symbol |
| Cognitive load | High (translate + learn) | Lower (direct understanding) |
| Parent involvement | Limited by English | Possible with math symbols |
**Note: These are aspirational goals based on our hypothesis, not measured results.**
### Envisioned Success Stories
These are hypothetical scenarios we hope MPL could enable once fully implemented:
<details>
<summary>🌍 Imagine: A student's potential journey</summary>
We envision students could progress like this:
**Starting point**: Basic math knowledge, no English
```mpl
-- Month 1: First program using familiar symbols
✎"Jambo!" -- Hello in their language
```
**Growing skills**: Applying math knowledge to programming
```mpl
-- Month 6: Using mathematical concepts they know
data ≜ [23, 45, 67, 34, 89, 12];
total ≜ 0;
∀ x ∈ data : total ← total + x;
average ≜ total ÷ 6;
✎("Average: " + average)
```
**Sharing knowledge**: Teaching others in their community
*This is our vision - not current reality. Help us make it possible!*
</details>
---
## 💻 Code examples (Syntax Demonstration)
**Note**: These examples show valid MPL syntax that our parser accepts (a test extracts every code block on this page and parses it). The M0-core subset runs in the browser interpreter at [mpl.codes](https://mpl.codes); the rest parses but does not run yet.
Some notation you might expect from math class — ∑, √, ², `%` (modulo), |x|, ranges like [1..10] — is deliberately absent: it is deferred to milestone M1, where each symbol will arrive together with defined semantics (see [DECISIONS.md](DECISIONS.md)).
### Level 1: Arithmetic thinking 🔢
*What every child knows*
```mpl
-- Store values (like math class!)
length ≜ 5;
width ≜ 3;
area ≜ length × width;
✎("Area = " + area);
-- Make decisions: (condition ⟹ result) | fallback
age ≜ 15;
(age ≥ 18 ⟹ ✎"Adult") | ✎"Minor";
```
### Level 2: Logical reasoning 🧩
*Natural progression from math*
```mpl
-- Do something for every element (∀ = "for all")
∀ n ∈ [1, 2, 3, 4, 5] : ✎(n × n);
-- Accumulate a running total
total ≜ 0;
∀ n ∈ [1, 2, 3, 4, 5] : total ← total + n;
✎("Total: " + total);
```
### Level 3: Real-world applications 🌍
*Solving community problems*
```mpl
-- Weather data analysis
temperatures ≜ [28, 30, 27, 31, 29, 33, 28];
total ≜ 0;
∀ t ∈ temperatures : total ← total + t;
μ ≜ total ÷ 7;
✎("Average: " + μ + "°C");
-- Parallel processing (‖ = parallel)
results ≜ analyzeNorth() ‖ analyzeSouth() ‖ analyzeEast();
```
### Level 4: Advanced concepts 🚀
*For those ready to go deeper*
```mpl
-- Function composition (∘, straight from math class)
double ≜ λn: n × 2;
addOne ≜ λn: n + 1;
transform ≜ double ∘ addOne;
✎(transform(5));
-- Higher-order functions
apply ≜ λf, x: f(x);
✎(apply(λn: n × n, 6));
```
---
## Why Release a Parser Without Execution?
We believe the core innovation of MPL is proving that mathematical notation can replace English keywords. By releasing the parser, we demonstrate this is grammatically possible and invite the community to help build the rest.
The parser alone proves several key points:
- Mathematical symbols can express the core programming constructs (see the ten [examples](examples/))
- A language without English keywords is technically feasible
- The grammar compiles with zero ANTLR errors and warnings, enforced in CI
- ASCII fallbacks make it universally typeable
Sometimes the idea is more important than the implementation. By sharing MPL now, we hope to inspire others to think differently about programming languages and who they exclude.
---
## 🏗️ Technical architecture
### Grammar specification
- Every symbol has exactly one meaning and one ASCII escape ([glyph-escapes.md](glyph-escapes.md))
- Operator precedence is documented in [precedence.csv](precedence.csv) and exercised by the test suite
- The grammar compiles with zero ANTLR errors and warnings (`-Werror`, enforced in CI)
- 200+ syntax assertions across the lexer, parser, example, and documentation test suites
- [Full grammar specification](src/main/antlr4/MPL.g4)
### Implementation stack
```
┌─────────────────────────────────────────────┐
│ Input Layer (Multi-modal) │
│ Visual │ Voice │ Keyboard │ Handwriting │
└────┬────┴───┬───┴────┬────┴───────┬────────┘
│ │ │ │
┌────▼────────▼────────▼────────────▼────────┐
│ Unicode Normalization │
│ (UTF-8 with BiDi support) │
└────────────────────┬───────────────────────┘
┌────────────────────▼───────────────────────┐
│ ANTLR 4 Parser │
│ Lexer → Parser → AST Generation │
└────────────────────┬───────────────────────┘
┌────────────────────▼───────────────────────┐
│ Semantic Analysis (planned) │
│ Type Checking → Effect Analysis │
└────────────────────┬───────────────────────┘
┌────────────────────▼───────────────────────┐
│ Code Generation (planned) │
│ LLVM │ JVM │ JavaScript │ Python │
└────────────────────────────────────────────┘
```
Only the parser stage exists today; the lower stages are the planned architecture. We publish no performance numbers until CI measures them.
---
## 🗺️ Pilot program roadmap
### Phase 1: Foundation 🏗️ (Months 1-3) ✅
- [x] Core parser implementation
- [x] Basic syntax examples
- [x] Grammar validation complete
- [ ] Educational materials in development
### Phase 2: Interpreter 📊 (Current Focus) **← We are here**
- [ ] Basic expression evaluation
- [ ] Control flow implementation
- [ ] Function calls
- [ ] Standard library basics
### Phase 3: Educational Materials 🚀 (Future)
- [ ] First pilot classroom test
- [ ] Basic curriculum development
- [ ] Teacher guide creation
- [ ] Community feedback integration
### Phase 4: Expansion 🌍 (Long-term Vision)
- [ ] Multi-school pilots
- [ ] Research partnerships
- [ ] Policy advocacy
- [ ] Global community building
---
## 🤝 Community & contribution
### For educators 🎓
<div align="center">
| Resource | Description | Get Started |
|----------|-------------|-------------|
| **Classroom Kit** | Future: Lesson plans and exercises | Coming soon |
| **Teacher Training** | Future: Online certification | Planned |
| **Community Forum** | Future: Educator community | In development |
| **Student Showcase** | Future: Project gallery | Under consideration |
</div>
### For developers 💻
```bash
# Clone and build
git clone https://github.com/developtheweb/mpl.git
cd mpl
./gradlew build
# Run tests
./gradlew test
# Parse examples (validation only, no execution)
./gradlew parseExamples
```
**Key contribution areas:**
- 🔤 Symbol input methods
- 🌍 Localization systems
- 📚 Educational content
- 🔧 Language features
- 📱 Mobile applications
[Contributing guidelines](CONTRIBUTING.md) | [Architecture docs](docs/ARCHITECTURE.md) | [GitHub issues](https://github.com/developtheweb/mpl/issues)
### For researchers 🔬
- **Cognitive load studies** — Measuring comprehension rates
- **Learning outcome analysis** — Long-term retention data
- **Cultural adaptation** — Symbol interpretation across cultures
- **Neurodiversity research** — Benefits for different learning styles
[Research collaboration](mailto:developtheweb@protonmail.com)
### For advocates 📢
**Help us reach more children:**
- 📄 Policy templates for education ministries - Coming soon
- 🎤 Speaker materials for conferences - In development
- 📊 Research findings - See [whitepaper](whitepaper/mpl-whitepaper.md)
- 🎨 Media kit - Coming soon
---
---
## 🌟 Why This Matters
### The Vision
Imagine a world where:
- A teacher in Beijing could explain loops using ∀ instead of `for`
- A parent in Mumbai could understand their child's code without knowing English
- Education ministers could provide programming education without requiring English literacy
These aren't testimonials - they're possibilities we're working toward. MPL is still just a parser, but it proves that programming without English is possible.
---
## 🎯 Join the movement
<div align="center">
### **Every child deserves to code in the language of their thoughts**
| 🎓 **Educators** | 💻 **Developers** | 🏛️ **Institutions** | 💰 **Supporters** |
|:---:|:---:|:---:|:---:|
| Share the vision | [Contribute code](https://github.com/developtheweb/mpl) | Contact us to explore | Star the project |
| Imagine the possibilities | Build the runtime | Research partnerships | Spread the word |
</div>
---
## 📚 Resources
<div align="center">
| 📖 [Documentation](docs/) | 🔬 [Whitepaper](whitepaper/mpl-whitepaper.md) | 📧 [Contact](mailto:developtheweb@protonmail.com) |
|:---:|:---:|:---:|
| View specs | Read the vision | Get in touch |
</div>
---
## 🚀 The inspiration
The idea for MPL came from a simple observation: children worldwide learn the same mathematical symbols (+, -, ×, ÷, =) but must learn English to program. This creates an unnecessary barrier.
Imagine a student asking: *"Why do I need to know English to tell a computer what to do? I know math. Isn't that enough?"*
This hypothetical question captures the essence of MPL. Mathematical thinking IS enough. We're building this proof of concept to demonstrate it's possible.
---
## 🔬 Cognitive science foundation
<details>
<summary>Why mathematical symbols work universally (click to expand)</summary>
### Symbolic universality
Mathematical notation evolved over millennia to be:
- **Culture-agnostic** — Symbols transcend linguistic boundaries
- **Cognitively efficient** — Direct concept-to-symbol mapping
- **Progressively learnable** — Builds on existing knowledge
### Neurological evidence
fMRI studies show mathematical symbol processing activates language-independent brain regions, enabling comprehension without linguistic translation.
### Pedagogical advantages
1. **Reduced cognitive load** — Single-step comprehension
2. **Transfer learning** — Math knowledge directly applies
3. **Cultural preservation** — Think in your native language
4. **Universal collaboration** — Code readable globally
[Read our whitepaper](whitepaper/mpl-whitepaper.md)
</details>
---
## 🌏 Global partnership vision
### Partnership Opportunities
We envision collaborating with organizations like:
<div align="center">
| Type of Partner | Potential Role | Envisioned Impact |
|-----------------|----------------|-------------------|
| **UN Agencies** | Education frameworks | Global policy influence |
| **Universities** | Research partnerships | Cognitive studies |
| **Tech Companies** | Technical support | Infrastructure development |
| **Local NGOs** | Community implementation | Grassroots adoption |
*Note: We are actively seeking our first institutional partners. Contact us if interested.*
</div>
### Join as a partner
We're seeking partnerships with:
- 🏫 **Schools & Universities** — Pilot programs
- 🏢 **Tech Companies** — Internships for MPL students
- 🏛️ **Governments** — National curriculum integration
- 🎓 **Research Institutions** — Impact studies
- 💡 **NGOs** — Community implementation
[Contact us](mailto:developtheweb@protonmail.com) to explore partnerships
---
## 🔮 Future roadmap
### Beyond programming
MPL is just the beginning. Our vision extends to:
1. **Mathematical Interfaces** — Operating systems using symbols
2. **Universal IDE** — Development environments without language barriers
3. **Symbolic Databases** — Query languages using set notation
4. **AI Training** — Teaching AI in mathematical notation
5. **Global Standard** — ISO standardization for universal programming
### The 2030 vision
By 2030, we envision a world where:
- ✅ **Any child** can learn programming in their native cognitive framework
- ✅ **No talent** is lost to language barriers
- ✅ **Global collaboration** happens without linguistic friction
- ✅ **Cognitive diversity** strengthens our collective problem-solving
- ✅ **Technology** truly serves all humanity
---
<div align="center">
## 🌟 A world where code speaks the language of human thought
### Not English. Not Chinese. Not Spanish.
### The language of logic itself.
**Together, we're not just teaching programming.**
**We're democratizing the power to create.**
---
*This is what we're building toward - a world where every child's way of thinking matters in programming.*
---
### [⭐ Star this repository](https://github.com/developtheweb/mpl) to support cognitive justice in programming
### **The next Fatima is waiting. Let's make sure nothing is lost in translation.**
</div>
---
<div align="center">
**Mathematical Programming Language** — Where every mind can code
[GitHub](https://github.com/developtheweb/mpl) • [Documentation](docs/) • [Contact](mailto:developtheweb@protonmail.com)
Made with ❤️ for the 80% of humanity waiting to code
</div>

96
SECURITY.md Normal file
View file

@ -0,0 +1,96 @@
# Security Policy
## Supported Versions
MPL is currently in active development. Security updates are provided for:
| Version | Supported |
| ------- | ------------------ |
| 2.0.x | :white_check_mark: |
| < 2.0 | :x: |
## Reporting a Vulnerability
The MPL team takes security vulnerabilities seriously. We appreciate your efforts to responsibly disclose your findings.
### How to Report
**DO NOT** create a public GitHub issue for security vulnerabilities.
Instead, please report security vulnerabilities via email to:
- **Primary**: developtheweb@protonmail.com
- **Subject Line**: [SECURITY] MPL Vulnerability Report
### What to Include
Please provide:
1. **Description** of the vulnerability
2. **Steps to reproduce** the issue
3. **Potential impact** of the vulnerability
4. **Suggested fix** (if you have one)
5. **Your contact information** (for follow-up questions)
### Response Timeline
- **Initial Response**: Within 48 hours
- **Status Update**: Within 7 days
- **Resolution Target**: Within 30 days for critical issues
### What to Expect
1. **Acknowledgment**: We'll confirm receipt of your report
2. **Assessment**: We'll investigate and determine the severity
3. **Updates**: We'll keep you informed of our progress
4. **Credit**: With your permission, we'll acknowledge your contribution when the issue is resolved
## Security Considerations for MPL
Given MPL's unique nature as a mathematical programming language, please consider these security aspects:
### 1. Unicode Handling
- Homograph attacks using similar-looking Unicode characters
- Bidirectional text manipulation
- Unicode normalization issues
### 2. Parser Security
- Grammar ambiguities that could lead to unexpected behavior
- Resource exhaustion through complex expressions
- Injection attacks through mathematical notation
### 3. Educational Environment
- MPL is designed for educational use, including by children
- Consider the impact on learning environments
- Be mindful of accessibility features
### 4. Multi-Modal Input
- Voice input security considerations
- Visual palette tampering
- Handwriting recognition exploits
## Responsible Disclosure
We support responsible disclosure:
1. Give us reasonable time to address the issue before public disclosure
2. Avoid accessing or modifying other users' data
3. Don't perform actions that could harm the service or its users
4. Act in good faith to avoid privacy violations
## Security Best Practices for Contributors
When contributing to MPL:
1. **Input Validation**: Always validate and sanitize user input
2. **Error Handling**: Never expose internal system details in error messages
3. **Dependencies**: Keep all dependencies up to date
4. **Code Review**: All security-related changes require thorough review
5. **Testing**: Include security test cases for new features
## Contact
- **Security Issues**: developtheweb@protonmail.com
- **General Questions**: See [SUPPORT.md](SUPPORT.md)
- **Project Maintainer**: Reverend Steven Milanese (@developtheweb)
---
Thank you for helping keep MPL and its community safe!

124
SUPPORT.md Normal file
View file

@ -0,0 +1,124 @@
# Getting Help with MPL
Thank you for using the Mathematical Programming Language! We're here to help you succeed.
## 🚀 Quick Links
- **Documentation**: [Full specification](math_prog_lang.md)
- **Examples**: [Working programs](examples/)
- **Symbol Reference**: [All symbols with ASCII escapes](glyph-escapes.md)
- **Whitepaper**: [Academic paper](whitepaper/mpl-whitepaper.md)
## ❓ Getting Support
### 1. Check Existing Resources
Before asking for help:
- 📖 Read the [README](README.md) for overview and quick start
- 🔤 Check [glyph-escapes.md](glyph-escapes.md) for symbol questions
- 💡 Review [examples](examples/) for working code patterns
- 🐛 Search [existing issues](https://github.com/developtheweb/mpl/issues) for similar problems
### 2. Community Support
#### GitHub Discussions
For general questions, ideas, and community interaction:
- Visit [GitHub Discussions](https://github.com/developtheweb/mpl/discussions)
- Categories:
- **Q&A**: Ask and answer questions
- **Ideas**: Suggest new features or improvements
- **Show and Tell**: Share your MPL projects
- **General**: Everything else
#### GitHub Issues
For bugs and feature requests:
- [Report a bug](https://github.com/developtheweb/mpl/issues/new?template=bug_report.md)
- [Request a feature](https://github.com/developtheweb/mpl/issues/new?template=feature_request.md)
### 3. Direct Contact
For sensitive issues or private concerns:
- **Email**: developtheweb@protonmail.com
- **Maintainer**: Reverend Steven Milanese (@developtheweb)
## 🎓 Learning Resources
### For Beginners
1. Start with [01_hello_world.mpl](examples/01_hello_world.mpl)
2. Learn basic operators from the [Symbol Reference](glyph-escapes.md)
3. Progress through numbered examples in order
### For Educators
- Review the educational philosophy in our [README](README.md)
- Check the Fatima Test principle in [CONTRIBUTING.md](CONTRIBUTING.md)
- Contact us about classroom materials
### For Developers
- [CONTRIBUTING.md](CONTRIBUTING.md) - How to contribute
- [Grammar file](src/main/antlr4/MPL.g4) - ANTLR 4 specification
- [Test suite](src/test/) - See how testing works
## 🐛 Reporting Issues
When reporting issues, please include:
1. **MPL version** (check releases)
2. **Operating system** and version
3. **Java version** (`java -version`)
4. **Minimal code example** that reproduces the issue
5. **Expected behavior** vs actual behavior
6. **Full error message** if applicable
### Good Bug Report Example
```
Title: ∑ operator precedence incorrect with nested expressions
Version: MPL 2.0.0
OS: Ubuntu 22.04
Java: OpenJDK 11.0.17
Code:
∑(i ∈ [1,5] : i × 2) + 3
Expected: 33 (sum is 30, plus 3)
Actual: 45 (seems to be computing ∑(i ∈ [1,5] : i × (2 + 3)))
Error: No error, just wrong result
```
## 💬 Communication Guidelines
1. **Be respectful** - We're all learning together
2. **Be patient** - MPL is a volunteer project
3. **Be clear** - Provide context and examples
4. **Be mindful** - Not everyone speaks English fluently
5. **Follow the Code of Conduct** - See [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)
## 🌍 Language Support
While project documentation is in English, we welcome questions in any language:
- Use your native language if it helps explain your issue
- We'll use translation tools if needed
- Community members may help translate
Remember: MPL exists to break language barriers - that includes our support!
## 🔧 Common Issues
### Unicode Display Problems
- Ensure your terminal supports UTF-8
- Try ASCII escapes (e.g., `\sum` instead of ∑)
- Check font support for mathematical symbols
### Parser Errors
- Verify correct symbol usage with [glyph-escapes.md](glyph-escapes.md)
- Check operator precedence in [precedence.csv](precedence.csv)
- Ensure balanced brackets/parentheses
### Build Issues
- Requires Java 11 or higher
- Run `./gradlew clean build`
- Check [CONTRIBUTING.md](CONTRIBUTING.md) for setup steps
---
Remember: Every question helps us improve MPL for everyone. Don't hesitate to ask!

68
build.gradle Normal file
View file

@ -0,0 +1,68 @@
plugins {
id 'java'
id 'antlr'
}
group = 'com.mpl'
version = '0.1-alpha'
repositories {
mavenCentral()
}
dependencies {
antlr 'org.antlr:antlr4:4.13.1'
implementation 'org.antlr:antlr4-runtime:4.13.1'
testImplementation 'junit:junit:4.13.2'
testImplementation 'org.hamcrest:hamcrest:2.2'
}
generateGrammarSource {
maxHeapSize = "64m"
// -Werror: any ANTLR warning (e.g. 184, token shadowing) fails the build
arguments += ["-visitor", "-listener", "-Werror", "-package", "com.mpl.parser"]
outputDirectory = file("${project.buildDir}/generated-src/antlr/main/com/mpl/parser")
}
compileJava.dependsOn generateGrammarSource
sourceSets {
main {
antlr {
// The Gradle ANTLR plugin defaults to src/main/antlr; the grammar
// lives in src/main/antlr4 (Maven layout).
srcDirs = ['src/main/antlr4']
}
java {
srcDirs += "${project.buildDir}/generated-src/antlr/main"
}
}
}
test {
// ConformanceCountTest reads these; declaring them makes the up-to-date
// check re-run tests when the README claim or the corpus changes.
inputs.file('README.md')
inputs.dir('conformance/corpus')
testLogging {
events "passed", "skipped", "failed"
exceptionFormat "full"
}
}
// ParseExamples lives in the test source set, so the task needs the test
// runtime classpath (with main.runtimeClasspath the class was never found).
task parseExamples(type: JavaExec, dependsOn: testClasses) {
mainClass = 'com.mpl.test.ParseExamples'
classpath = sourceSets.test.runtimeClasspath
args = ['examples']
}
// Grammar-check CLI (see ParseCheck.java): file paths or '-' for stdin via
// --args passthrough, e.g. ./gradlew -q parseCheck --args='examples/01_hello_world.mpl'
task parseCheck(type: JavaExec, dependsOn: classes) {
mainClass = 'com.mpl.tools.ParseCheck'
classpath = sourceSets.main.runtimeClasspath
standardInput = System.in
}

256
conformance/DIVERGENCES.md Normal file
View file

@ -0,0 +1,256 @@
# DIVERGENCES — where the two parsers disagree
Each entry is a minimized program that one parser accepts and the other
rejects (JS = the parse phase of `js/mpl.js`; ANTLR = the grammar via
`./gradlew parseCheck`). Divergences are recorded, never auto-fixed —
which parser is right is a ratification question for Stage 3. Rulings
happen in `JUDGMENT_CALLS.md`.
Entries below are appended by `conformance/harness/fuzz.mjs`
(deterministic: seed and index reproduce the original program), except
where a different source is noted.
## Divergence (found during C3 corpus construction)
```
✎ "drop\qme";
```
- JS interpreter: accepts (prints `dropqme` — an unknown string escape
drops the backslash silently)
- ANTLR grammar: rejects (token recognition error at: '"drop\q')
- RESOLVED by ruling 12 at ad01bbd
## Divergence (fuzz seed 20260709, index 49)
```
```
- JS interpreter: rejects (err_unexpected at 1:1)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 20 at ad01bbd
## Divergence (fuzz seed 20260709, index 11)
```
"a\zb"
```
- JS interpreter: accepts (runs)
- ANTLR grammar: rejects (1:0: token recognition error at: '"a\z')
- RESOLVED by ruling 12 at ad01bbd
## Divergence (fuzz seed 20260709, index 86)
```
((f);)
```
- JS interpreter: rejects (err_expect at 1:5)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 21 at ad01bbd
## Divergence (fuzz seed 20260709, index 247)
```
(42;)
```
- JS interpreter: rejects (err_expect at 1:4)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 21 at ad01bbd
## Divergence (fuzz seed 20260709, index 119)
```
(a;)
```
- JS interpreter: rejects (err_expect at 1:3)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 21 at ad01bbd
## Divergence (fuzz seed 20260709, index 9)
```
(f∘g)
```
- JS interpreter: rejects (err_expect at 1:3)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 22 at cd59791
## Divergence (fuzz seed 20260709, index 144)
```
({"",(a)})
```
- JS interpreter: rejects (err_expect at 1:5)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 23 at ad01bbd
## Divergence (fuzz seed 20260709, index 456)
```
({"a b",2})
```
- JS interpreter: rejects (err_expect at 1:8)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 23 at ad01bbd
## Divergence (fuzz seed 20260709, index 182)
```
({(007),true})
```
- JS interpreter: rejects (err_expect at 1:8)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 23 at ad01bbd
## Divergence (fuzz seed 20260709, index 284)
```
({(1),⊥})
```
- JS interpreter: rejects (err_expect at 1:6)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 23 at ad01bbd
## Divergence (fuzz seed 20260709, index 276)
```
({5,"a b"})
```
- JS interpreter: rejects (err_expect at 1:4)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 23 at ad01bbd
## Divergence (fuzz seed 20260709, index 427)
```
({b:y})
```
- JS interpreter: rejects (err_expect at 1:4)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 24 at ad01bbd
## Divergence (fuzz seed 20260709, index 101)
```
({c,0.5})
```
- JS interpreter: rejects (err_expect at 1:4)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 23 at ad01bbd
## Divergence (fuzz seed 20260709, index 425)
```
({g:⊥})
```
- JS interpreter: rejects (err_expect at 1:4)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 24 at ad01bbd
## Divergence (fuzz seed 20260709, index 194)
```
({x,(5)})
```
- JS interpreter: rejects (err_expect at 1:4)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 23 at ad01bbd
## Divergence (fuzz seed 20260709, index 212)
```
({y:"hi"})
```
- JS interpreter: rejects (err_expect at 1:4)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 24 at ad01bbd
## Divergence (fuzz seed 20260709, index 25)
```
({y:0})
```
- JS interpreter: rejects (err_expect at 1:4)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 24 at ad01bbd
## Divergence (fuzz seed 20260709, index 347)
```
({{},{}})
```
- JS interpreter: rejects (err_expect at 1:5)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 21 at ad01bbd
## Divergence (fuzz seed 20260709, index 52)
```
({λ})
```
- JS interpreter: rejects (err_expect at 1:4)
- ANTLR grammar: accepts (parses)
- RESOLVED by ruling 26 at c447eb7
## Divergence (fuzz seed 20260709, index 76)
```
λ(b):(42)
```
- JS interpreter: accepts (runs)
- ANTLR grammar: rejects (1:4: mismatched input ':' expecting {<EOF>, ';', PARALLEL, LEFTARROW, IMPLIES, OR, AND, '=', NEQ, '<', '>', LEQ, GEQ, APPROX, SIM, '+', '-', TIMES, DIV, AST, COMPOSE, DEFINITION, HANDLE, ALLOC, RELEASE, '(', '|', MIDDOT})
- RESOLVED by ruling 25 at ad01bbd
## Divergence (fuzz seed 20260709, index 13)
```
λ(f):42
```
- JS interpreter: accepts (runs)
- ANTLR grammar: rejects (1:4: mismatched input ':' expecting {<EOF>, ';', PARALLEL, LEFTARROW, IMPLIES, OR, AND, '=', NEQ, '<', '>', LEQ, GEQ, APPROX, SIM, '+', '-', TIMES, DIV, AST, COMPOSE, DEFINITION, HANDLE, ALLOC, RELEASE, '(', '|', MIDDOT})
- RESOLVED by ruling 25 at ad01bbd
## Divergence (fuzz seed 20260709, index 29)
```
λ(y):f
```
- JS interpreter: accepts (runs)
- ANTLR grammar: rejects (1:4: mismatched input ':' expecting {<EOF>, ';', PARALLEL, LEFTARROW, IMPLIES, OR, AND, '=', NEQ, '<', '>', LEQ, GEQ, APPROX, SIM, '+', '-', TIMES, DIV, AST, COMPOSE, DEFINITION, HANDLE, ALLOC, RELEASE, '(', '|', MIDDOT})
- RESOLVED by ruling 25 at ad01bbd
## Divergence (fuzz seed 20260710, index 178 — found during Stage 3 A7)
```
({-42})
```
- JS interpreter: rejected (err_comment — the lexer committed '{-' to a
comment even without a terminator)
- ANTLR grammar: accepts (MULTILINE_COMMENT requires its '-}'; '{' lexes
as a brace, so this is a block containing -42)
- RESOLVED by grammar alignment (decision: the grammar is the syntax
truth) at f5e8407 — no ruling needed; found by the fresh fuzz seed and
fixed before commit

View file

@ -0,0 +1,276 @@
# JUDGMENT_CALLS — semantic decisions awaiting ratification
RATIFIED 2026-07-09 — this file is the semantic record of MPL M0.
Every section below is a semantic question Stage 2 surfaced, stated with
the behavior `js/mpl.js` exhibited at observation time (Stage 2 head,
`ea66a2a`) and the corpus entries that pinned it. Each `RULING:` line
records Reverend's ratified decision of 2026-07-09. BLESS rulings kept the
observed behavior; OVERRIDE/SPLIT/IMPLEMENT/AMEND rulings changed the
grammar or the interpreter in Stage 3, and the corpus was re-recorded to
match. The "Observed:" text is the historical record, not the current
behavior — the rulings govern.
## 1. Division by zero
Question: what does `x ÷ 0` do — error, infinity, or ⊥?
Observed: raises `err_div0` (both `÷` and `/`, integer or float operands).
Pins: `043_div_zero`.
RULING: BLESS. `x ÷ 0` (and `/`) raises `err_div0`. Division by zero is undefined.
## 2. The value of a ∀ expression
Question: what does `∀ x ∈ list : body` evaluate to?
Observed: the value of the last body evaluation; `⊥` for an empty list.
Pins: `018_forall_value`, `019_forall_scope`.
RULING: OVERRIDE. `∀` is an iterator; the expression's value is `⊥` always (including empty collections). Using a statement as a value is undefined — same principle as ruling 3.
## 3. Result when no guard matches
Question: what is `(false ⟹ e)` with no `|` fallback?
Observed: an internal no-match that surfaces as `⊥` everywhere except
directly to the left of `|`.
Pins: `021_no_guard_match`, `023_alt_chain`.
RULING: BLESS (semantics, not mechanism). An unmatched guard yields `⊥` unless caught by `|`. Implementations choose their own internal sentinel.
## 4. Integer vs float display
Question: is `4 ÷ 2` shown as `2` or `2.0`? Are all numbers one type?
Observed: all numbers are IEEE doubles; integral values display with no
decimal point (`2`), non-integral as JS renders them (`0.5`, and
`0.1 + 0.2` shows `0.30000000000000004`). Literals normalize (`007``7`,
`0.50``0.5`).
Pins: `006_number_display`, `007_float_arithmetic`.
RULING: OVERRIDE. Numbers are exact rationals (arbitrary-precision integer numerator/denominator). Decimal literals convert exactly (`0.1` = 1/10). Display: integers bare; otherwise lowest-terms fraction `num/den`, sign on the numerator, denominator > 0; zero as `0`. Output is valid MPL that re-evaluates to the same value. IEEE doubles are rejected: the language must not lie about `0.1`. `√ vs ` is logged as a standing M1 decision.
## 5. ✎ formatting per type
Question: exactly how does `✎` render each value type?
Observed: numbers via host `String()`; strings bare at top level but
quoted inside lists; booleans `true`/`false`; lists `[a, b]` with
one-space separation; closures as `λ`; `⊥` as `⊥`.
Pins: `009_string_concat`, `011_list_display`, `031_show_all_types`.
RULING: BLESS, spec'd. `✎` renders: numbers per ruling 4; strings bare at top level, double-quoted inside lists; booleans `true`/`false`; lists `[a, b]` (comma-space); closures as `λ`; `⊥` as `⊥`.
## 6. ⊥ display and propagation
Question: is `⊥` a first-class value or a poison that propagates?
Observed: a first-class value — it displays as `⊥`, concatenates into
strings (`"x" + ⊥``x⊥`), sits in lists, but arithmetic on it is
`err_num`.
Pins: `030_bot`, `052_bot_arith`.
RULING: BLESS. `⊥` is first-class: displays as `⊥`, sits in lists, string concatenation renders it (`"x" + ⊥``x⊥`); arithmetic on it is `err_num`.
## 7. Equality across types
Question: what does `=` mean across types and on structures?
Observed: structural (JSON-serialization) equality — lists compare
element-wise, cross-type comparisons are `false` (`1 = "1"``false`),
and `⊥ = ⊥``true`. Comparing a self-referential closure crashes with a
keyless host error (unpinnable by the corpus).
Pins: `034_cross_type_equality`, `033_string_compare`.
RULING: SPLIT. Data equality is structural: element-wise lists, cross-type `=` is `false`, `⊥ = ⊥` is `true`, `0.5 = 1/2` is `true` (same rational). Any equality comparison involving a function raises `err_fn_eq` — function equality is undecidable; a keyed error replaces the current keyless crash.
## 8. Ordering across types
Question: what do `< > ≤ ≥` do on mixed or non-numeric operands?
Observed: raw host comparison with JS coercion — `1 < "2"``true`,
`"10" < 9``false`, `true < 2``true`; strings order lexicographically.
Pins: `035_mixed_compare`, `033_string_compare`.
RULING: OVERRIDE. `< > ≤ ≥` are defined on number×number and string×string (Unicode code-point order) only; anything else raises `err_compare`. Host coercion (`1 < "2"`) is JavaScript soul leakage, not mathematics.
## 9. Closure capture
Question: do closures capture values at definition time or the
environment?
Observed: the environment — later mutation of a captured variable is
visible on the next call (`013` prints 11 then 21).
Pins: `013_closure_capture`, `026_def_vs_assign_scope`.
RULING: BLESS. Closures capture the environment. (The corpus itself forces this: `factorial` only works because the λ sees its own later binding.)
## 10. Recursion depth
Question: what bounds recursion, and how does exceeding it surface?
Observed: the host JS stack — deep recursion dies as a keyless RangeError
before the 500 000-step budget can trigger, so the corpus cannot pin it
(no error key). Iteration-heavy programs do hit the budget and raise
`err_steps`. Depth ~500 is comfortably safe.
Pins: `016_recursion_sum` (works at 500), `053_step_budget` (`err_steps`).
RULING: OVERRIDE. Recursion is bounded by an explicit λ-application depth counter, limit 10 000, raising `err_depth`. A keyless host RangeError is a hole in the error surface; the limit is conformance surface in every implementation.
## 11. The step budget itself
Question: is "500 000 evaluation steps, then `err_steps`" part of the
language, and is that the right number?
Observed: hard-coded 500 000; nested `∀` loops over a 10-element list six
deep exceed it.
Pins: `053_step_budget`.
RULING: RECLASSIFY. The step budget is an environment resource limit, not language semantics — like out-of-memory. `err_steps` (500 000) remains in the browser implementation; entry 053 leaves the portable corpus and becomes a js/test implementation test.
## 12. String escape round-tripping
Question: which string escapes exist, and what does an unknown one mean?
Observed: `\n` and `\t` expand; `\"` and `\\` escape themselves; any other
`\x` silently drops the backslash (`"drop\qme"``dropqme`). The ANTLR
grammar instead REJECTS unknown escapes — a recorded divergence.
Pins: `008_string_escapes`; divergence in DIVERGENCES.md ("drop\qme" and
the `"a\zb"` fuzz entry).
RULING: OVERRIDE. Escapes are exactly `\n \t \" \\`; any other `\x` raises `err_escape`, matching the grammar. Silent data-mangling is forbidden.
## 13. Guard condition truthiness
Question: what may a guard condition be?
Observed: `true` and non-zero numbers fire the guard; `false`, `0`,
strings, lists and `⊥` do not (they yield the no-match path) — so numbers
are truthy for `⟹` but nothing else is.
Pins: `022_guard_truthiness`.
RULING: OVERRIDE. A guard condition must be boolean; any non-boolean condition (numbers included) raises `err_bool`. A condition is a proposition.
## 14. ∧ operand truth
Question: do `∧`/`` accept the same truthiness as `⟹`?
Observed: no — operands are tested with strict boolean equality, so
`1 ∧ true``false` while `(1 ⟹ x)` fires. Both operators short-circuit
(observable by side effect). This asymmetry with #13 is the sharpest
accident in the surface.
Pins: `036_logic_ops`, `037_logic_short_circuit`.
RULING: SPLIT. `∧ ` short-circuit (blessed, observable by side effect) and demand boolean operands — a non-boolean evaluated operand raises `err_bool` instead of silently comparing false. One notion of truth, everywhere; an unevaluated right operand raises nothing.
## 15. Block scoping
Question: does `{ … }` create a scope?
Observed: no — bindings made inside a brace block leak out (`028` prints
9). Only λ bodies and each `∀` iteration scope.
Pins: `028_block_no_scope`, `027_block_sequencing`.
RULING: BLESS. Braces group; they do not scope. Scope is created by binders only (λ parameters, ∀ iteration variables) — the Curry-Howard reading: a discharged hypothesis IS a λ. An explicit local-binding construct (let/where) is logged as a standing M1 decision.
## 16. ≜ vs ← scoping and creation
Question: how do define and assign differ?
Observed: `≜` always binds in the current scope; `←` mutates the nearest
enclosing binding and silently creates one in the current scope when
nothing is bound (assignment-before-definition is legal). Both are
expressions returning the value; both rebind freely (`x ≜ 1; x ≜ 3` is
legal re-definition).
Pins: `024_def_assign_rebind`, `025_def_assign_value`,
`026_def_vs_assign_scope`.
RULING: OVERRIDE (both halves). `≜` introduces a name exactly once per scope — same-scope redefinition raises `err_redef`; shadowing in inner scopes is legal. `←` mutates the nearest enclosing binding and raises `err_unbound` when none exists — silent creation is the typo trap. Both remain expressions returning the value.
## 17. Type constraints
Question: does `λx∈:` constrain anything?
Observed: the constraint parses (including supplementary-plane `𝔹`) and
is discarded unevaluated — `g ≜ λs∈𝔹: s + "!"` happily takes a string.
Matches the site's "parsed today, not yet enforced" claim.
Pins: `039_type_constraint_unenforced`.
RULING: BLESS. Type constraints parse and are discarded, unenforced — this is the published claim and Stage 5's mandate.
## 18. Nullary calls and zero-parameter λ
Question: `f()` parses — but can any function be called that way?
Observed: no zero-parameter λ can be written (`λ: e` is a parse error),
so every `f()` is a runtime `err_arity`. The call syntax exists; nothing
can satisfy it.
Pins: `046_arity_nullary`, `047_arity_extra`.
RULING: AMEND GRAMMAR. Nullary functions exist: `λ: e` is admitted (bare colon; the parenthesized spelling stays rejected per ruling 25). Effects made M0 procedural the day `✎` entered it; arity 0 is not an exception to . `f()` calls it; arity mismatches remain `err_arity`.
## 19. as multiplication
Question: is `` (U+2217) an operator, and what does it mean?
Observed: exactly `×` — same token, same precedence.
Pins: `041_asterisk_multiplication`.
RULING: BLESS. `` (U+2217) is exactly `×`.
## 20. Divergence: empty program
Question: is the empty program valid?
Observed: the grammar accepts it; the JS interpreter rejects it
(`err_unexpected` at 1:1).
Pins: none possible until ruled (decision 3 — divergent programs cannot
enter the corpus). Repro in DIVERGENCES.md (fuzz index 49).
RULING: OVERRIDE. The empty program is valid and produces no output. The grammar is right; the interpreter accepts it.
## 21. Divergence: sequences inside parentheses
Question: is `( e1 ; e2 )` valid? DECISIONS.md says `(...)` contains one
seqExpr; the JS parser allows exactly one expression.
Observed: the grammar accepts `(42;)` and `(a; b)`; the JS interpreter
rejects both (`err_expect`).
Pins: none until ruled. Repros in DIVERGENCES.md (fuzz indexes 86, 119,
247, 233, 279, 406, 468, 101…).
RULING: OVERRIDE. Parentheses contain one seqExpr per the standing DECISIONS ruling: `(e1; e2)` is legal, value = last expression. The interpreter implements its own language.
## 22. Divergence: `∘` composition
Question: does function composition exist in M0?
Observed: the grammar parses `f ∘ g`; the JS interpreter lexes `∘` (it
even has the `\circ` escape) but has no parse rule for it — every use is
`err_expect`.
Pins: none until ruled. Repro in DIVERGENCES.md (fuzz index 9).
RULING: IMPLEMENT. `∘` is function composition: `(f ∘ g)(args…) = f(g(args…))`. Operands must be functions — a non-function operand raises the expected-a-function key (reuse the existing key if the audit finds one, else introduce `err_fn`). Precedence and associativity follow the grammar.
## 23. Divergence: set literals
Question: `{a, b}` is a set per the grammar's brace disambiguation — does
the M0 core have sets?
Observed: the grammar accepts `({5, "a b"})` and friends; the JS
interpreter has no set support and rejects them (`err_expect`).
Pins: none until ruled. Repros in DIVERGENCES.md (multiple fuzz indexes).
RULING: PARSE-ONLY. Set literals parse (the interpreter gains the grammar's brace disambiguation) and evaluation raises `err_notyet`. Set semantics are an M1 design, logged.
## 24. Divergence: record literals
Question: `{k: v}` is a record per the grammar — does the M0 core have
records?
Observed: the grammar accepts `({y: 0})`; the JS interpreter rejects
(`err_expect`).
Pins: none until ruled. Repros in DIVERGENCES.md (fuzz indexes 25, 212,
425, 427, 447).
RULING: PARSE-ONLY. Record literals: same as 23.
## 25. Divergence: parenthesized λ parameters
Question: DECISIONS.md rejected `λ(a, b):` as a second parameter spelling
— but who enforces that?
Observed: inverted from every other divergence — the GRAMMAR rejects
`λ(a, b): e` (honoring the decision) while the JS interpreter accepts it.
The interpreter carries a syntax form the language explicitly rejected.
Pins: none until ruled. Repros in DIVERGENCES.md (fuzz indexes 13, 29,
76, …).
RULING: OVERRIDE. `λ(a, b): e` is rejected by the interpreter too — the grammar already enforces the ratified DECISIONS ruling.
## 26. Divergence: bare λ and Greek letters as identifiers
Question: the grammar tokenizes Greek letters (LAMBDA_VAR et al.) as
identifiers, so `{λ}` parses; the JS interpreter only knows λ as the
abstraction head.
Observed: grammar accepts `({λ})`; JS rejects (`err_expect` — λ demands a
parameter list).
Pins: none until ruled. Repro in DIVERGENCES.md (fuzz index 52).
RULING: AMEND GRAMMAR. `λ` is a reserved token, never an identifier. Only λ; other Greek letters (π et al.) remain identifiers — Fatima wants π.

114
conformance/SURFACE.md Normal file
View file

@ -0,0 +1,114 @@
# SURFACE — what `js/mpl.js` actually implements
Audited from the source of `js/mpl.js` at Stage 2 (C3, head `ea66a2a`) and
pinned by the corpus of that stage. **Historical record**: Stage 3 ratified
the 26 judgment calls (2026-07-09) and changed the surface where rulings
overrode it — rationals, boolean conditions, binding discipline, depth
limit, composition, and parser alignment. Where this file and
`JUDGMENT_CALLS.md` disagree, the rulings govern; the ratified corpus is
the executable truth.
## Lexer
- Whitespace: space, tab, CR, LF.
- Comments: line `-- …`; block `{- … -}`, nesting tracked (unterminated →
`err_comment`).
- Strings: `"…"`, escape `\n` → newline, `\t` → tab, any other `\x``x`
(the backslash is silently dropped — `\q` becomes `q`); unterminated →
`err_string`.
- ASCII escapes: `\word` for word ∈ {lambda, forall, in, coloneq,
leftarrow, implies, and, or, neq, leq, geq, times, div, trace, bot,
parallel, circ, ast}; unknown word → `err_escape`.
- Numbers: `[0-9]+(.[0-9]+)?` via `parseFloat` (all numbers are JS
doubles; no scientific notation, no leading `.`).
- Identifiers: `[a-zA-Z][a-zA-Z0-9_]*`; `true`/`false` are boolean
literals. A leading `_` is not an identifier start (`err_char`).
- Type symbols ` 𝔹` lex as identifiers (code-point-safe; 𝔹 is
supplementary-plane).
- Single-char tokens: `✎ λ ∀ ∈ ≜ ← ⟹ ∧ ≠ ≤ ≥ × ÷ ∘ ‖ ⊥ + - / = < > |
; : , ( ) [ ] { }`.
- Anything else → `err_char`.
## Parser (loosest to tightest)
`;` sequence → `‖` (desugars to sequence!) → `≜` (right-assoc, id target
only) → `←` (right-assoc, id target only) → `|` (left-assoc) → `⟹`
(right-assoc) → ```∧` → comparison (`= ≠ < > ≤ ≥`, non-associative —
`1 < 2 < 3` is a parse error) → `+ -``× ÷ /` → unary (`✎`, `-`) →
call `f(a, …)` (postfix, nullary `f()` parses) → atom.
Atoms: number/string/bool literals, `⊥`, identifiers,
`λ params [∈ constraint] : body` (≥ 1 parameter; the constraint is parsed
and **discarded unevaluated**), `∀ id ∈ expr : body`, list `[…]`, parens
`( expr )` (a single expression — `;` inside parens is a parse error),
braces `{ seq }` (`{}` evaluates to `⊥`).
Parse-class error keys: `err_char`, `err_escape`, `err_string`,
`err_comment`, `err_expect`, `err_unexpected`, `err_def_target`,
`err_assign_target`.
Lexed but unusable: `∘` (compose) has a token and an escape but **no
parser rule** — any use is `err_expect`.
## Evaluator
- Values: number (double), string, boolean, list, closure, `⊥`.
- `✎ e` prints `show(value)` and returns the value.
- `show`: `⊥``⊥`; strings bare at top level but **quoted inside
lists**; lists `[a, b]`; closures → `λ`; booleans `true`/`false`;
numbers via JS `String()` (integral doubles print without `.0`).
- `+` is numeric addition unless either side is a string — then it is
concatenation of `show`-rendered operands. `- × ÷ /` are numeric only
(`err_num`), `÷ 0``err_div0`.
- Guards: `c ⟹ e` fires iff `c` is `true` **or a non-zero number**;
strings/lists/`⊥` never fire. A non-firing guard yields NOMATCH, which
`|` catches; NOMATCH surfacing anywhere else becomes `⊥`.
- `∧ `: short-circuit; operands are tested with `=== true`, so non-boolean
operands behave as false (`1 ∧ true``false` — contrast with `⟹`).
- Comparison: `=`/`≠` via JSON serialization (structural for lists,
cross-type → `false`, `⊥ = ⊥``true`, comparing a self-referential
closure crashes keyless); `< > ≤ ≥` are raw JS comparisons (mixed-type
coercion applies).
- `≜` binds in the **current** scope; `←` mutates the nearest enclosing
binding, creating one in the current scope if none exists. Both return
the value; both may rebind.
- Braces `{…}` do **not** create a scope (bindings leak out). λ bodies and
each `∀` iteration do (the `∀` variable shadows and is restored).
- Closures capture the defining **environment** (later mutations are
visible), enabling recursion via `≜`.
- `∀ x ∈ list : body` requires a list (`err_iter`), evaluates the body per
element, and yields the last body value (`⊥` for an empty list).
- Errors carry a key + 1-based line:col. Runtime keys: `err_undef`,
`err_num`, `err_div0`, `err_notfn`, `err_arity`, `err_iter`,
`err_steps` (evaluation-step budget: 500 000).
- Deep recursion overflows the host stack **before** the step budget —
a keyless RangeError, unpinnable by the corpus (see JUDGMENT_CALLS).
## Grammar-only surface (no ruling, Stage 4+ material)
The grammar accepts these; the Stage-3 interpreter does not. No ruling
covers them and the fuzzer's generator does not emit them — they are on
the record here so the gap is a listed fact, not a surprise:
- `≈` (APPROX) and `` (SIM) comparison operators — interpreter: `err_char`.
- `"""raw strings"""` (RAWSTRING) — interpreter: `err_char` at the second
quote pair's content or `err_string`/`err_expect` depending on context.
- Hex (`0x1F`), binary (`0b101`) and exponent (`1.5e3`) number literals —
interpreter lexes the leading digits as a plain number and fails to
parse the rest (`err_expect`).
- `_` as a λ pattern (patternAtom UNDERSCORE) — interpreter: `err_char`.
Dead key: `err_comment` can no longer be raised — since the comment lexer
matched the grammar (a `{-` without its `-}` is a brace, not an
unterminated comment), no code path produces it. It stays in the error-key
list pending removal at the next legitimate interpreter change (no hash
churn for hygiene alone).
## Explicitly out of corpus scope
- `‖` — parses, and the evaluator runs it as plain sequencing, but its
semantics are an M1 design question (locked decision 6): no corpus
entry pins it.
- Everything the grammar has that `js/mpl.js` does not implement (modules,
resources, channels, exceptions, metaprogramming, records, sets, choice
types, …) — Stage 4/5 artifacts, not Stage 2 ones.

View file

@ -0,0 +1 @@
Hello, World!

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "example", "decision": "Ratified 2026-07-09 (Stage 3 batch — behavior blessed as observed; no single ruling)", "notes": "seeded from examples/01_hello_world.mpl"}

View file

@ -0,0 +1,2 @@
-- Hello World example
✎"Hello, World!";

View file

@ -0,0 +1 @@
120

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "example", "decision": "Ratified 2026-07-09 (Stage 3 batch — behavior blessed as observed; no single ruling)", "notes": "seeded from examples/02_factorial.mpl"}

View file

@ -0,0 +1,4 @@
-- Factorial example with proper precedence
factorial ≜ λn∈: (n≤1 ⟹ 1) | (n×factorial(n-1));
result ≜ factorial(5);
✎result;

View file

@ -0,0 +1,5 @@
14
20
5
2
4

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09 (Stage 3 batch — behavior blessed as observed; no single ruling)", "notes": "× ÷ bind tighter than + -; + - and × ÷ left-associative"}

View file

@ -0,0 +1,5 @@
✎(2 + 3 × 4);
✎((2 + 3) × 4);
✎(10 - 2 - 3);
✎(20 ÷ 2 ÷ 5);
✎(2 + 12 ÷ 4 - 1);

View file

@ -0,0 +1,5 @@
-5
5
5
-6
-3

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09 (Stage 3 batch — behavior blessed as observed; no single ruling)", "notes": "unary minus, including doubled and against binary minus"}

View file

@ -0,0 +1,5 @@
✎(-5);
✎(- -5);
✎(3 - -2);
✎(-2 × 3);
✎(-(1 + 2));

View file

@ -0,0 +1,3 @@
5/2
5/2
3

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 4", "notes": "/ is an ASCII alias of ÷"}

View file

@ -0,0 +1,3 @@
✎(10 / 4);
✎(10 ÷ 4);
✎(9 / 3);

View file

@ -0,0 +1,6 @@
42
3/2
1/2
2
7
1/2

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 4", "notes": "integral doubles display without decimal point; literals normalize"}

View file

@ -0,0 +1,6 @@
✎ 42;
✎ 1.5;
✎(1 ÷ 2);
✎(4 ÷ 2);
✎ 007;
✎ 0.50;

View file

@ -0,0 +1,3 @@
15/4
3/10
6

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 4", "notes": "IEEE double arithmetic, including the 0.1+0.2 representation artifact"}

View file

@ -0,0 +1,3 @@
✎(1.5 + 2.25);
✎(0.1 + 0.2);
✎(3.0 × 2);

View file

@ -0,0 +1,5 @@
a
b
a b
q"q
b\b

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 12", "notes": "string escapes \\n \\t \\\" \\\\ (unknown escapes like \\q diverge from the grammar — see DIVERGENCES.md, not corpus-pinnable)"}

View file

@ -0,0 +1,4 @@
✎ "a\nb";
✎ "a\tb";
✎ "q\"q";
✎ "b\\b";

View file

@ -0,0 +1,6 @@
n=5
5!
l=[1, 2]
b=true
v=⊥
ab

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 5", "notes": "+ concatenates when either operand is a string, rendering the other via show"}

View file

@ -0,0 +1,6 @@
✎("n=" + 5);
✎(5 + "!");
✎("l=" + [1, 2]);
✎("b=" + true);
✎("v=" + ⊥);
✎("a" + "b");

View file

@ -0,0 +1,3 @@
مرحبا
你好
Salaam

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09 (Stage 3 batch — behavior blessed as observed; no single ruling)", "notes": "non-ASCII string content passes through byte-intact"}

View file

@ -0,0 +1,3 @@
✎ "مرحبا";
✎ "你好";
✎ "Salaam";

View file

@ -0,0 +1,3 @@
[1, "two", true, [3, 4], ⊥]
[]
[λ]

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 5", "notes": "lists display with strings quoted inside; closures display as λ"}

View file

@ -0,0 +1,4 @@
id ≜ λx: x;
✎ [1, "two", true, [3, 4], ⊥];
✎ [];
✎ [id];

View file

@ -0,0 +1,3 @@
λ
7
1

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 5", "notes": "λ definition, display, application, multiple parameters"}

View file

@ -0,0 +1,5 @@
id ≜ λx: x;
✎ id;
✎ id(7);
fst ≜ λa, b: a;
✎ fst(1, 2);

View file

@ -0,0 +1,2 @@
11
21

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 9", "notes": "closures capture the environment, not values at definition time"}

View file

@ -0,0 +1,5 @@
x ≜ 10;
f ≜ λy: x + y;
✎ f(1);
x ← 20;
✎ f(1);

View file

@ -0,0 +1,2 @@
42
15

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09 (Stage 3 batch — behavior blessed as observed; no single ruling)", "notes": "curried application and λ literals as call arguments"}

View file

@ -0,0 +1,5 @@
twice ≜ λf: λx: f(f(x));
inc ≜ λn: n + 1;
✎ twice(inc)(40);
apply ≜ λf, v: f(v);
✎ apply(λn: n × 3, 5);

View file

@ -0,0 +1 @@
55

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09 (Stage 3 batch — behavior blessed as observed; no single ruling)", "notes": "binary recursion through a guarded alternative"}

View file

@ -0,0 +1,2 @@
fib ≜ λn: (n ≤ 1 ⟹ n) | (fib(n - 1) + fib(n - 2));
✎ fib(10);

View file

@ -0,0 +1 @@
125250

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 10", "notes": "linear recursion 500 deep (within the host stack)"}

View file

@ -0,0 +1,2 @@
sum ≜ λn: (n = 0 ⟹ 0) | (n + sum(n - 1));
✎ sum(500);

View file

@ -0,0 +1 @@
55

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09 (Stage 3 batch — behavior blessed as observed; no single ruling)", "notes": "∀ with an accumulating assignment"}

View file

@ -0,0 +1,3 @@
t ≜ 0;
∀ n ∈ [1, 2, 3, 4, 5]: t ← t + n × n;
✎ t;

View file

@ -0,0 +1,2 @@

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 2", "notes": "a ∀ expression yields the last body value; empty collection yields ⊥"}

View file

@ -0,0 +1,2 @@
✎(∀ n ∈ [1, 2, 3]: n × 2);
✎(∀ n ∈ []: n);

View file

@ -0,0 +1,3 @@
1
2
100

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 15", "notes": "the ∀ variable shadows per iteration and the outer binding survives"}

View file

@ -0,0 +1,3 @@
n ≜ 100;
∀ n ∈ [1, 2]: ✎ n;
✎ n;

View file

@ -0,0 +1,3 @@
A
B
C

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 3", "notes": "the canonical conditional: guarded alternatives with fallback"}

View file

@ -0,0 +1,4 @@
grade ≜ λs: (s ≥ 90 ⟹ "A") | ((s ≥ 80 ⟹ "B") | "C");
✎ grade(95);
✎ grade(85);
✎ grade(70);

View file

@ -0,0 +1,2 @@

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 3", "notes": "a guard that never fires, with no | fallback, surfaces as ⊥"}

View file

@ -0,0 +1,3 @@
✎((false ⟹ 1));
x ≜ (false ⟹ 1);
✎ x;

View file

@ -0,0 +1 @@
err_bool

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 13", "notes": "guard conditions: true or non-zero number fire; strings/lists never do"}

View file

@ -0,0 +1 @@
✎((1 ⟹ "one") | "no");

View file

@ -0,0 +1,2 @@
3
2

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 3", "notes": "fall-through chains take the first firing arm"}

View file

@ -0,0 +1,2 @@
✎((false ⟹ 1) | (false ⟹ 2) | 3);
✎((false ⟹ 1) | (true ⟹ 2) | 3);

View file

@ -0,0 +1,2 @@
1
2

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 16", "notes": "≜ and ← both rebind freely; ← works without a prior ≜"}

View file

@ -0,0 +1,4 @@
x ≜ 1;
✎ x;
x ← 2;
✎ x;

View file

@ -0,0 +1,4 @@
7
8
2
2

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 16", "notes": "both binding forms are expressions returning the bound value; ≜ chains right"}

View file

@ -0,0 +1,5 @@
✎(a ≜ 7);
✎(a ← 8);
b ≜ c ≜ 2;
✎ b;
✎ c;

View file

@ -0,0 +1,2 @@
99
99

View file

@ -0,0 +1 @@
{"status": "ratified", "source": "coverage", "decision": "Ratified 2026-07-09, ruling 9 and 16", "notes": "inside a λ, ← mutates the captured outer binding; ≜ creates a local one"}

View file

@ -0,0 +1,7 @@
x ≜ 1;
f ≜ λy: {x ← 99; x};
f(0);
✎ x;
g ≜ λy: {x ≜ 55; x};
g(0);
✎ x;

Some files were not shown because too many files have changed in this diff Show more