The interpreter and compiler are using more stack than expected. This leads to unfortunate stack overflows.

Implement a data stack to avoid over using Rust's stack, improve performance and make the Tako stack behaviours independent of Rust's semantics

Is your feature request related to a problem? Please describe.
Operators are a common and useful programming language feature that dramatically decrease line noise and typing overhead for programmers making use of common functions (e.g. integer addition, insertion into a container, set operations etc).

Describe the solution you'd like
Tako should have a mechanism for (infix) operators, similar to Haskell i.e. the operators are infix (by default) functions that can be passed just like other functions, but are normally parsed differently.

Describe alternatives you've considered
Prefix operators (e.g. +(a, b) instead of (a+b)) would be one way forward, but are fairly clunky and too dissimilar to mainstream languages to be widely accessible.

Infix functions (e.g. a(+)b) would be more flexible, supporting named infix functions as well as operators, but would be unclear to new devs.

This depends on some starter work on #48.

It will be useful to have an interpreter that can be set automatically generated code, checking that the code doesn't crash if it passes the semantic checker and does crash (or behaves badly) when the semantic checker raises issues should allow faster progress on the checker and language semantics.

This should include a full specification of the parser in something like EBNF allowing automated checking that the parser actually conforms to the specification, giving some form of error on inputs that deviate from the spec (though not crashing).

Is your feature request related to a problem? Please describe.
Rule application should not be automatic in many circumstances (and possibly all).
Instead rules/rewrites should be applied as directed by the programmer.
This should include any 'glue' code that connects the applied rule to the current context.

Describe the solution you'd like
Function calls are the accepted method of applying rewrites / invoking behaviour in programming languages. I intend for this feature to look very similar to the current convention in Python.

i.e. Invocation

ret = function(argument_one, argument_two, keyword_arg_foo = foo, keyword_arg_bar = bar)

and Declaration to be similar to Haskell and Idris, the difference is that rather than asserting only the types of our arguments and return value, we assert the space of types of the environments that the function can be safely used in. We therefore separate the name/call notation from the type signature.

minimum(lst) = {lst=(h, t), lst:List, h:a -|
    case(
         { t=[] -| ret = h }
         {x = minimum(t), x >= h -| ret = h}
         {x = minimum(t), x < h -| ret = x}
    )
|- ret, ret isa a }

Describe alternatives you've considered
Automatic function calling is an alternative that is interesting as a concept i.e. the programmer would be expected to write functions by writing increasingly strict pre and post conditions and breaking up functions into smaller functions when there were multiple different possible implementations that were possible.
e.g.

downloadWebPage(url, path) {url isa URL, path isa Path, conn isa InternetConnection, +download isa File}

downloadWebPage then can find the functions defined for InternetConnections and URLs (and Paths).
There seems to be no obvious way to constrain this to the desired behaviour though: the system could easily select to do something nonsensical like sending a delete request and then producing a empty file in the given path. Though this is makes little sense for the name we have given, it makes more sense for a function called something like 'clearDistributedCache'.

Should include some documentation, maybe one day a blog etc.

Remove the dependency on the bash script and write tests

Support should be added for

• Booleans
• String with default and paramaterisable character types
• Lists
• Integers with size variants
• Floats with size variants

Type class style constraints should allow all of these to easily interoperate.

This will probably also require infix/mixfix operators+calls.

Should show the code around the error

Should explain the error and the expectation better

Tako currently has stubs for Inkwell integration

Currently the semantic checker does a pass over the ast but doesn't build the call graph or do actual checking.

The first step to fix this is to build a graph of calls between functions so that the requirements can be propagated along the edges.

Interactive mode should be like an IDE and have common features like Control+P (Command P on Mac) for a searchable commands list.

Is your feature request related to a problem? Please describe.
Most compilers struggle to distribute compilation tasks across all cores, generally limited to distributing each code unit and waiting for dependencies to be compiled before projects can be compiled. This massively restricts the possibilities for fast compilation.

Describe the solution you'd like
Using an Entity Component system based design, most compilation data can be stored in arenas, allowing systems to perform fast processing of many items and each system can be run in parallel on multiple different cores with producer consumer relationships when multiple systems can be run simultaneously.

Describe alternatives you've considered
The current state of the art for most compilers is tree walking and compiling code units separately. This has several limitations (not least that LTO and normal optimisation are handled so differently).

Additional context
Currently experimenting with specs (from the amethyst ecosystem) which has parallelism support.

Is your feature request related to a problem? Please describe.
Current triples can only be combined when their preconditions and postconditions match.
These matches are unnecessarily restrictive and do not support rewriting or reasoning.

Describe the solution you'd like
I propose that conditions be 'solved' rather than simply checked, using a search based rewriting strategy similar to Prolog's query resolution algorithm.
This should allow expressive pre+post-conditions that can express more clearly the requirements that a function has without requiring users to manually promise that things are safe (without any actual checking).

Describe alternatives you've considered
One alternative would be having Coq style expressions that are added in the process of 'merging' two triples that mutate the pre/post conditions until there is a match or a failure. This would lead to writing proofs that functions could be run in others contexts which may be hard to reason about.

Also, Coq already does this quite well.

I have yet to find another alternative.

Additional context

Unfortunately this requires the addition of 'unknown variables' or placeholders that are not explicitly specified and inference rules for resolving predicates. This complicates the symbol and predicate models.

e.g. {?x, ?y, ?z, isa, ?x isa ?y, ?y isa ?z}[]{?x isa ?z} allows the program to reason about the isa relationship.

http://mesonbuild.com/Tutorial.html

Building on #48 there should be a simple way to build more complex data structures that support tagging (at compile time where possible).

Ideally these would be subtypable (i.e. Left a and Right b a subtypes of Either a b and do not need to be defined separately). This should make typing guarantees more useful without requiring common Haskell patterns such as data Value = IntV Int | BoolV Bool. Instead it should be possible to have a type Value = Int | Bool, only requiring clarification when those types overlap.

This may require work on Rapid check or switching to Autocheck.