frendsick / torth Goto Github PK

Describe the bug
The compiler gives ambiguous error messages when the file given to the compiler as code_file parameter does not exist. The error message indicates that the file could not be included, which is kinda true, but it would be better just to tell the user that the file does not exist.

To Reproduce
Steps to reproduce the behavior:

• Try to compile a file that does not exist that has any other file extension than '.torth'
  ./torth nonexistent.txt
• Compiler gives the following error message:

Compiler Error UNSUPPORTED_FILE_EXTENSION:
File 'nonexistent.txt' has unsupported file extension
Only .torth files are supported

• Try to compile a file that does not exist that has the '.torth' file extension
  ./torth nonexistent.torth
• Compiler gives the following error message:

Compiler Error INCLUDE_ERROR:
File 'nonexistent.torth' cannot be included.

Expected behavior
In both above cases, the compiler should indicate that compiling the file fails because the file is not found. The error message could be something like the following:

Compiler Error FILE_NOT_FOUND:
File 'nonexistent.txt' is not found

Screenshots

Document at least the following information from libraries:

• Name
• Description
• Included functions, constants, memories, etc and their descriptions
  • Probably no need to document the function contents anywhere else than in the code

Describe the bug
The Torth compiler cannot compile itself with the compiler version merged in PR #58, which enabled using recursion by introducing proper local variables to functions. The compiler version can compile any other known programs but itself correctly.

To Reproduce
Steps to reproduce the behavior:

1. Compile the bootstrap compiler: make
2. Compile the Torth compiler with the bootstrapped compiler: ./torth torth.torth
3. Compile the Torth compiler again ./torth torth.torth
4. After that the current torth executable is unable to compile any other programs due to segfault

Expected behavior
The Torth compiler should be able to compile itself again and again.

Screenshots

Additional context
This issue was introduced when function recursion was implemented in PR #58

At the moment the language does not care about the function parameter and return types or even how many of them are there. Implement type checking for function signatures to ensure the function takes and returns the expected types.

Describe the bug
Function parameter and variable values are shared between recursive function calls. This is a problem, at least if the function has multiple recursive calls to itself. This happens because each function's function parameters and variables are statically named memory locations.

To Reproduce
Steps to reproduce the behavior:

1. Compile and run the example program below ./torth -r fibonacci.torth
2. It prints wrong values to both its parameter num and the variable variable

include "std"
function Fib num:int -> int :
  NULL take variable in
  if num 1 <= do num return endif

  num 1 - Fib
  1337 variable =
  num 2 - Fib +

  // Expected variable value: 1337
  // Got: NULL
  "Variable value is: " puts
  variable print "\n" puts
end

function main :
  // Expected: 55
  // Got: 18446744073709551536
  10 Fib print
end

Expected behavior
Variables and function parameters should be separate for each recursive function call.

Screenshots

The output of the example program

The function parameters and variables are statically named memory locations in Assembly.

Additional context
We would need a way to have parameters that are not statically named in the assembly. For example, in C, this is done by pushing each variable to the stack, but I am not sure if that is feasible in the already stack-based language. Maybe?

Type checking of sorts were implemented in compiler/program.py inside function type_check_program using compile-time virtual stack. That stack however were not enough to provide accurate enough type checking for programs with different kinds of control clauses (IF, WHILE) or functions. Type checking should be re-implemented so that it takes code branching properly into account.

Make it possible to call a macro from within another macro

Document at least this information from intrinsics:

• Name
• Description
• Python meta code
• Assembly code

Add documentation on how to use the CLASS keyword and create objects.