– Typee Documentation –

1 – Introduction

1.1 – What is Typee?

Typee is an Object Oriented Programming language. Its syntax is derived from other OOP language such as C++11, Java 8.0 and Python 3.8. Typee is neither compiled nor interpreted as are other programming languages. It is a translated language. This generic programming language is indeed translated in source code of other programming languages, such as Pytohn, Java or C++.

It finally appears that Typee is a very good language to learn programming.
It should be a very good support for computering science and programming curses, since it then open doors for the easy learning of Java, C++, C#, Python, etc.!

Important notice: unfortunately, due to the easy and natural way of programming with Typee it appears that once you will have begun to code in Typee you won’t go back to any other programming language… Fortunately, Typee translators are available or will be available for most of the common generic programming language – i.e. C++, C#, Java and Python at first.

1.2 – Typee language characteristics

We list here only the main characteristics of Typee.

  • Object Oriented Programming;
  • typed variables and objects;
  • classical scalar types;
  • Templated on functions, methods and operators – as with templates in C++ and generics in Java while with bonuses on operators;
  • auto typing in specific cases – as with auto in C++ and as is by default in Python;
  • ‘for’ and ‘if’ comprehensions – as in Python;
  • built-in containers for objects – as in Python: list, set, dict,
    plus array;
  • classical instructions plus bonuses – e.g. else associated with for and while as in Python or with switch;
  • classical exception handling;
  • classical operators plus a few bonuses – e.g. 0-shifting as built in Java;
  • few undefined operators available for users specific definitions;
  • unnamed functions – as in Java or Python lambdas;
  • an embed instruction for the embedding of native code in Python, C++ or Java for instance;
  • and few other goodies you will enjoy to use.

While navigating in this documentation, you will find numerous information on Typee grammar specification, the Typee translator software architecture (see short description below) or the whole software documentation – as generated in HTML by an open source application, PyYadc (Yet another documentation compiler).

Please be aware that this project is under construction and that currently NO running version is available. Documentation as well as directories tree and their contents are highly subject to change, actually on a daily or at least on a weekly basis.

Rationale

At first, this was a personnal project. It aimed at developping an upper layer to Python with a true type verification. This had already been partially addressed by Google with their project PyType. The kind of annotations this project proposes is now widely accepted and inserted in new Python code. PyType is a static analyzer that infers and checks types for Python code.

PyType is a static type inferencer and type checker for _Python_ code. 
It is capable of analyzing existing Python code to determine what possible 
types could be used on APIs throughout the program.

(source: Google project PyType)

Well. This is not exactly full type checking – while it is perfectly adapted to Python programming for which no type declaration is needed before manipulating objects.

But we wanted to get a typed language to further translate it in Python code, full static type checking having been done before automatically generating Python modules then running the Python interpreter on them.

1.2.1 – Typee: neither compiled nor interpreted but translated

Traditionnal OOP languages are either compiled (e.g. C++) or interpreted (e.g. Python ). They even may be first compiled into an intermediate code which is then interpreted (e.g. Java and its Bytecode interpreted by a Java Virtual Machine that has to be implemented on each of the different targetted devices).

Typee is neither compiled nor interpreted. It is rather translated into other OOP languages, such as Python which chronologically is the first addressed OOP language from: Python, C++ and Java. During the translation, type infering and checking is done not only for APIs as does PyType but also on all the other parts of the code.

While this may seem to be valuable for untyped languages such as Python, it should appear to be not useful for other typed languages, of course.
Yes, but wait…

1.2.2 – Typee: one code for many implementations

Here is the core usefulness of Typee: once a program has been written in Typee, it can then easily be translated in any other available OOP language. At first, this will be a translator to Python. But as soon as other translators will be available, e.g. for C++ or Java, the same code will be available for translation in these languages also.

This is what we call the DOGM concept: Do Once Get Many.

As long as related libraries are added to the package (for instance graphical ones or GPU parallel programming ones) and are programmed in Typee with dedicated code (i.e. native embedded code) for the targetted OOP language, it should be easy to program applications for Windows, Linux, iOS or Android with a single code programmed in Typee.

Here we are!

1.2.3 – Has this been done before?

Well, it might be that this has already been done before, yes.

Haxe is en excellent example of transpilation from one formal generic language to many others. “The Haxe Foundation was created to fund long term Haxe development and provide support to companies using Haxe.” as is said on their related Web site. This creation took place with many commercial partners, after many years of open-source development (which started by 2005).

Meanwhile, Haxe is translated in many languages and for many platforms, with Web development as its first intention.

The Haxe compiler is specified with functionnal programming language OCaml, an Inria extension of ML:

ML is a general-purpose functional programming language developed by Robin Milner and others in the early 1970s [first appeared in ’73] at the University of Edinburgh, whose syntax is inspired by ISWIM. It has roots in the Lisp language, and has been characterized as “LISP with types”. Historically, ML stands for MetaLanguage: it was conceived to develop proof tactics in the LCF theorem prover (whose language, pplambda, a combination of the first-order predicate calculus and the simply-typed polymorphic lambda calculus, had ML as its metalanguage). It is known for its use of the Hindley–Milner type system, whose type inference algorithm can automatically assign the types of most expressions without requiring explicit type annotations. Additionally, the use of this algorithm ensures type safety—there is a formal proof that a well-typed ML program does not cause runtime type errors.
(source: https://IPFS.io/ipfs)

See also: OCaml.org

The description of the Haxe compiler is concise and ensures correctness of types checking. That’s great.
OCaml gets also a very good reputation about its computational optimization on time processing.

The global software architecture of Typee, while having been specified with no knowledge of the Haxe one, is finally the same as the Haxe compiler. As you will see below, Haxe and Typee both specify a front-end and many back-ends. Typee seems then to be a well designed “transpiler” (i.e. a compiler with no binary machine-code generation).

So, would the work have been already done?
Well, not exactly as we aim at doing it!

There are still a few concepts that are offered as built-in goodies in Typee that are not in Haxe. The main one is the native code embedding which helps generate efficient targeted code for some parts of it. Others are concepts that constitue Typee built-in libraries while they have been later added as external libraries with Haxe.

Finally, noone would re-program the Haxe compiler in Haxe. Its (fully correct) OCaml implementation being a functionnal one, this would need reprogrammation from scratch in an imperative language (i.e. Haxe). Typee first implementation being done in Python 3.8, it will be far easier to later reprogram it in Typee which, then, will be translated in far better time-efficient languages (e.g. C++).

Really so, Here We Are!

1.3 – Typee global architecture

Typee has been specified as would have been any compiler. Our bedside book for a long has been “Engineering a Compiler, 2nd Edition, Keith D.Cooper & Linda Torczon, Elsevier, 2012” and we encourage the reader to read it.

We have choosen this book because it was newer than the famous Dragoon book “Compilers, principles, techniques, & tools, 2nd ed.” from Alfred V. Aho, Monica S. Lam, Ravi Ethi and Jeffrey D. Ullman, Pearson-Addison Wesley, 2007 – while this Dragoon book had been used to specify the Python interpretor CPython.

1.3.1 – Global architecture of a compiler

A compiler is composed of a front-end, a back-end and an optimizer.

The Front-End

The Front-End contains a scanner that scans the code and generates a first level of intermediate code: the tokenized code.

The generated tokenized code is provided to a parser that parses the tokens and generates a second level of intermediate code: the IC. The parser parses this code and checks it for syntax correctness. Syntax errors are emitted during this step of the compilation.

The generated IC is finally passed to an elaborator that elaborates all the other checkings – such as types infering and checking, for instance. Not declared variables or objects, or types errors are emitted during this step of the compilation.

The Back-End

The Back-End generates the final binary code for the targetted processing unit. It gets as input the intermediate code IC as generated by the elaborator of the Front-End, once this IC has been fully checked and validated. The Back-End output is a binary file that contains either executable code within a targetted Operating System or binary code and linkage metadata to be later linked with other code.

1.3.2 – The Optimizer

According to the targetted processing unit, the Optimizer optimizes the finally generated binary code. According to the IC generated by the Front-End it may also provide optimizations within the IC, e.g. by duplicating code of small functions rather than calling them (speed optimization) or by removing dead code as long as this can be statically detected (space optimization).

1.3.3 – Global architecture of Typee

Well, Typee is a translator, not a compiler. So, we only implement the Front-End and the Back-End steps of a compiler. The optimization last step will not be implemented for translation from Typee to targetted programming languages. This optimization last step is left to the final compilers / interpreters that will be applied to the source code of every  targetted programming languages.

1.3.3.1 Typee Front-End

As for any compiler, Typee gets a scanner for the tokenization of the code, a parser for syntax checking and an elaborator for undeclared variables detection, types infering and types checking.

It generates an Intermediate Code and passes it to the Back-End as long as all checks are ok.

1.3.3.2 Typee Back-End

The Typee Back-End finalizes the translation to the targetted programming language. Remember, as a first step, Python is the targetted language. C++ and Java will come next.

According to this, the Back-End of Typee contains as many generators as targetted languages, each of them generating the corresponding code to be either interpreted (Python) or compiled (C++, Java) with the corresponding interpreter / compiler.

1.3.3.3 Optimizer

Typee implements no optimizer. This step is left to the final interpreters and compilers of the targeted programming languages that will do a definitively correct job.

1.3.3.4 Final step

The final step for the user is then to run the compiler or the interpretor of the targetted language. Of course, this step can be automated via scripting and Typee project aims at providing such scripts to ease the whole process.

1.4 – Visit us

Our GitHub repository is at https://typee-language.github.io/Typee/

You can follow us also at https://twitter.com/TypeeProgrammi1 and at https://www.facebook.com/LanguageTypee – as long as these are still alive.

< previous (documentation home) | (2. language specs) next >