Mr. Hashemi: a Persian-language fork of GraalVM's SimpleLanguage

A fork of SimpleLanguage with the keywords translated

Mr. Hashemi is described as a national programming language, a fork from SimpleLanguage, which in turn is the GraalVM project it links to.

That lineage is the whole story of the implementation. A fork of a Truffle-based language inherits the parser, the AST, the object model and the tooling, and the work in this repository is the keyword layer plus whatever else the author changed. The repository layout confirms it, with a language/ directory for the language implementation itself, a generate_parser/ directory that is clearly where the grammar is produced, a native/ directory for the native image support, a launcher/ directory for the run configuration, a docs/ directory, and a test-report/ directory alongside a pom.xml at the root.

A pom.xml at the root means it is a Maven project, which is what a GraalVM language implementation looks like, and the badges in the README show a FOSSA licence and maintainability status, a SonarCloud maintainability rating and a SonarCloud coverage badge, so the project is wired into the standard Java static analysis and code coverage services.

The language is called national for a reason that is stated plainly: the keywords are Persian. The programming model underneath is still the SimpleLanguage one, which is a deliberately simple object-oriented language, and the README says the logical operators are basically like Java, with a link to the Java tutorial page listing them.

The stated ambition is unusual and worth quoting as it is: the authors hope Mr. Hashemi gets enough attention to make billions of tomans out of the project. That is a joke and a real design goal at the same time, since a language whose keywords are Persian is explicitly aimed at Persian speakers.

How you would run it, and what the documentation leaves out

There is no install command in the README, and that is worth saying plainly rather than working around.

What the project does give you is a project page at mr-hashemi.github.io/mr-hashemi/ and a repository whose layout matches a GraalVM language project. The language/ directory is where the implementation lives, generate_parser/ is where the grammar is produced, native/ is for the native image work, launcher/ holds the run configuration, and pom.xml at the root is the Maven build. So the expected route to a running interpreter is the standard GraalVM language build, through the Maven project, rather than a documented install script.

The documentation surface is equally thin. The README's basic syntax section covers functions, loops, conditionals, variable declaration and the logical operators, and it links to the Java tutorial page for the operator list rather than restating it. The docs/ directory in the repository holds whatever else exists. There is no written account of the object model beyond the jadid() call and the dot notation, no description of the textblock and json support that version 0.05 added, and no explanation of how the launcher, the native image build and the parser generator fit together at runtime.

That thinness is the honest characterisation of this project. It is a fork of a working language with a translated keyword set, published so that people can read the implementation and try the syntax, not a language with a specification, a standard library and a compatibility promise. The gap between the SimpleLanguage it forks and the Mr. Hashemi it presents is the keyword layer, and the README covers that layer and almost nothing else.

The one place where the documentation is unusually complete is the example program, and it is complete in a way that lets you read the language's whole surface from a single block of code: a function declaration, a call, a loop with a Persian keyword, a print call, a string variable, an integer, and a second function taking a parameter. If you are evaluating the language, that example plus the syntax list is the entire specification.

The tooling around it, and what the badges are measuring

A language project lives or dies by its tooling, and the badges in the README show a project plugged into the usual Java services.

The FOSSA badge reports the licence and maintainability status for the repository, and there is a second FOSSA badge in the licence section of the README shown at a larger size, which is the usual way to display the licence analysis prominently. FOSSA scans the dependency tree and reports what licences are in play, which for a language implementation that pulls in a large tree of GraalVM and ANTLR related artefacts is the check that tells you whether you can redistribute the built result.

The SonarCloud badges are a maintainability rating and a coverage percentage. Both point at the same project, so the repository is analysed on SonarCloud, and the coverage badge implies the test suite is executed and reported there rather than only in the local test-report/ directory that sits in the repository root.

That test-report/ directory is worth a note, because committing test output is a practice that some projects do and some forbid. Here it is part of the tree, which suggests the author wanted the results visible in the repository, and it is also a hint about the shape of the test suite, since a language project needs both unit tests for the AST and the evaluator and end-to-end tests that run a program and check the output.

The .github/ directory at the root is where the continuous integration lives, and there is a .gitignore alongside it. The generate_parser/ directory is the one to look at if you want to understand the language, because a Truffle language's grammar is the source of truth for the syntax, and the keyword mapping from SimpleLanguage to the Persian set is most likely visible there as a change to the lexer's token names.

The project is not archived and the default branch is master, so the tree is still browsable, which matters for a repository whose value to a reader is mostly as a readable example of how a language is put together.

The syntax, and the keyword mapping you have to memorise

The README's basic syntax section is short, and the whole language is described in a handful of rules.

Functions are declared with the keyword bebin before the function name, and the program starts from a function called azinja. To call a function you simply call it. The example defines two functions, azinja and derakht, and calls derakht from inside azinja.

The example itself is the clearest illustration:

bebin azinja() {
  i = 0;
  ta (i<1) bood {
    bechap("adad bede");
    n = adadBekhoon();
    derakht(n);
  }
}

bebin derakht(n){
  i = 0;
  matn = "";

  ta (i <n) bood {
    matn = matn + "*";
    i = i + 1;
    bechap(matn);
  }

  j = 0;
  ta (j<4) bood {
    bechap("*");
    j = j+1;
  }
}

So bechap is the print call, matn holds a string, and the loop construct is ta with a condition and the keyword bood. The condition construct is age with a condition and bood, replacing the usual if and braces form. The braces remain, and the semicolons remain, and the indentation is the same shape as Java.

One detail in the example is worth flagging for anyone writing code in it. The documentation describes the usual while loop as ta (shart) bood {code}, so the loop keyword is the while form. In azinja the loop is written as ta (i<1) bood with no increment of i inside the body, which means the loop body executes only because i starts at zero and the condition is false after the first pass. It reads like an if statement wearing a loop's syntax, which is either an intentional idiom or a quirk of the example, and the documentation does not say which.

Variables are declared without a type keyword. A string is a name assigned a quoted literal, a number is a name assigned a numeric literal, and an object is created with a call to jadid() and then given fields with the dot notation, for example chiz.sefat1 for a string field, chiz.esm for another and chiz.sen for a numeric one.

Three releases, all in 2020, and a licence that permits reuse

The release history is short enough to state in full, and the dates are the most telling fact about the project.

Version 0.05 came out on 2020-01-02 with textblock and json support. Version 0.06 followed on 2020-01-04, and version 0.07 on 2020-07-24. There have been no releases since, and the last push to the repository was on 2026-06-30.

A repository that was pushed to in 2026 but has not released since 2020 is a project in maintenance rather than active development. The kind of change that lands in such a repository is a fix or a documentation tidy, not a language feature, and a contributor picking it up should expect to bring their own idea of what a 0.08 would contain.

The licence is UPL-1.0, the Universal Permissive License, which is the one Oracle uses for many of its open source projects and which permits use, modification and redistribution including commercially, without the copyleft obligation of the GPL. For a language implementation, that is a sensible choice, because it lets a company embed the interpreter in a product without the source disclosure that a GPL language runtime would bring.

The version numbers also tell you the project's own assessment of itself. A language at 0.07 with three releases in the first seven months of 2020 and nothing after is an experiment, and the README is written in the register of one, opening with the line that other languages are just too difficult, and asking the reader to ask Mr. Hashemi to do the job right for them.

The project page is at mr-hashemi.github.io/mr-hashemi/, and the README's own documentation is the syntax list and the example, with the docs/ directory in the repository holding whatever else there is.

Editorial conclusion

Mr. Hashemi is worth a look if you are interested in how a real language is built on a Truffle framework, because it is a fork of a working language rather than a from-scratch parser, and the tree shows the expected pieces of a GraalVM language project. It does not suit you as a language to build a project on, since the last release was 0.07 in July 2020 and the last push was on 2026-06-30, which suggests occasional maintenance rather than a maintained toolchain. Before you try it, read the syntax list in full, because the keyword mapping is not obvious and the example in the README uses the loop keyword in a way that reads like a single-iteration guard.

Frequently asked questions

Official sources

1. Issues
2. License: UPL-1.0
3. mr-hashemi/mr-hashemi on GitHub
4. README
5. Releases