# Work to do for the first version

There are three items left before I have something minimally viable: type unification minimal support for exceptions * a language template

I will probably require a monomorphism restriction to get a working version released.

## Progress

Those three requirements are still in planning.

### Type unification

Have worked out:

1. How to express negative type assertions to support switch statements.
2. How to express overloads as unions.
3. The type signatures of the builtins I plan to support.

### Exceptions

I’ve got the syntax for exceptions and a short list of exceptions. (Only division by zero and invalid array lookups.) This does prevent having a few string munging functions like ord.

I’ve removed the ability of exceptions to contain loops to simplify the initial implementation.

It seems like they can be replaced with switch-case statements.

### Language template

I’ve worked out the builtins to support, and a sketch of the syntax of the project file.

At this point, the project file could just be TOML.

## 1.0 Requirements

To get from minimally viable to somewhat useful, let’s avoid stuff that would be nice:

1. Doesn’t need a lot of languages
2. Doesn’t need an interpreter
3. Doesn’t need a type system with bells and whistles

It does though, need:

1. Serialization.
2. Versioning.
3. Decent parsing and error reporting.
4. Build support.

### Error reporting

The parser is not forgiving. I’m probably using megaparsec wrong, or may need to add a concrete syntax tree prior to the AST to recognize errors so I can display meaningful error messages.

Also, I love megaparsec, but it’s a recursive descent parser and that means you have to discover invalid parses manually and work around them. I’m also not exploiting the fact that it’s combinatorial, e.g. I’m not embedding syntaxes.

### Build support

A major requirement of the project is that auto-generation of code integrates into the build process as seamlessly as possible. Newer build tools generally support this, but it’s often quite arcane.

I think the most direct route here is the tool is published as a self-contained library for major architectures. That is, if you’re building to python, you’d include tenet-python as a library and you’d import it as a custom command in your setup.py that can be installed via pip install.

That doesn’t need to be complex; all we need is a statically linked binary for the appropriate architecture and a wrapper that invokes it as a regular command line utility.