To try and see if the GC is actually doing something, I was trying to make a program that made the GC do things. On running this program, ONLY when the GC is stressed using the -S flag:

class A {
    init() {
        this.x = 0
    }
}

{
    var obj = A()
}

The program stops, either via a segfault or a SIGABRT. The error message (on the fish shell) for the segfault is like this:

fish: Job 1, 'zen -S gc_test.zn' terminated by signal SIGSEGV (Address boundary error)

Or if it stops via SIGABRT it has something about realloc():

realloc(): Invalid pointer
fish: Job 1, 'zen -S gc_test.zn' terminated by signal SIGABRT (Abort)

On a bit of a closer look it appears that the program hasn't even started running when this error occurs, since adding the -T flag to trace script execution gives nothing. Adding the -D flag to dump disassembled bytecode however gives this:

== init ==
0000    3 OP_GET_LOCAL     0000
0002    | OP_CONSTANT      0001 '0'
0004    | OP_SET_PROPERTY  0000 'x'
0006    | OP_POP
0007    4 OP_GET_LOCAL     0000
0009    | OP_RETURN
realloc(): invalid pointer
fish: Job 1, 'zen -DSL gc_test.zn' terminated by signal SIGABRT (Abort)

It seems like the error might be occuring right as compilation ends, and before the VM starts. Again, the last error may be a SIGSEGV or a SIGABRT, but its still clear that something is wrong with the memory management.

Currently, the output of zen does provide colors (not a lot though, only the error messages are in color so far) but only on Unix-like shells. Windows shells like cmd.exe and PowerShell are out of luck.

As far as I'm aware, Odin does not have the capability to colorize input cross-platform, so I'm thinking of using some C code like in my watchlist project and importing it as a library to Odin to do this task.

Modules can be imported using the import keyword:

import "module.zn"

I'm still thinking about an export system; either JS-like or Lua-like.

As for how it works, it'll simply run any of the modules that have been imported so that the variables declared in the modules are added into the global scope so that the importing program can use them.

This is long-term, so it'll be a while before it is here.

examples/demo.zn doesn't run correctly; upon inspection of the bytecode it was found that the break statement was bugged and was jumping to far greater distances than just outside of the loop, specifically the while true loop in the demo; which caused the VM's stack to misbehave and thus become empty before the end of the program.

This is probably an issue with how the jump offsets are calculated in the compiler, need to look into it further.

The language is good and simple with "if else" but it can be better with ifn't and whilen't syntax

Use case: ifn't and whilen't will prevent the need to use the not operator in the code

Variables inside a closure that have been declared as val are reassignable, despite val being for single-assign variables. This has been a known issue for a while, but I haven't been able to think of a way to fix it just yet so I haven't worked on it so far.

A program that represents this is as follows:

func outer() {
   func inner() {
       val x = "outside"
       return x
  }

   return inner
}

var y = outer()
y = "abcd"

This program should NOT compile, and must error when trying to create the var y; since vals can't be redeclared as vars either. The reassignability must not happen AT ALL.

Related to #11. That issue should should only be worked on once this is complete.

When just playing around with the REPL, I discovered this weird issue:

Welcome to zen!
Press 'Ctrl-D' to exit.
zen:1> var x = 1
zen:2> x |> it + it
compile error at end: Expect ';' after expression.
  on [line 2]

This is supposed to print 2, not an error.

Seems to me like this is a bug in the compiler in the part responsible for compiling the it tokens. I assume it does not expect more than one its.

Currently, checking for the existence of variables and erroring based on the result is done at runtime. It was only possible to do so at runtime at first; but after I added final variables (now vals), it has become possible to do so during compile time, as I had to do so to prevent reassignment or redeclaration of such variables.

The one challenge here is implementing such checking for upvalues, since the val checking hasn't yet been implemented for them either.