[teo_zero]

I find this promising. There are some weak points to highlight (not to criticize, but to help development).

What I don't like is that there are more ways to declare what a name means. Variables:

  var x = ...
  int x = ...

And even functions:

  fn f()...
  var f = fn()...

It makes reading someone else's code difficult. When I want to know what an identifier is, I scan the code until I find its declaration. I might do it manually or via some macros of my editor, but the fact that such declaration can appear in different forms makes things difficult.

Besides, looking for the first time at a piece of code it's not immediately clear if an identifier is a type or a variable. Especially in constructs where a variable and a type appear separated by a =, which suggests they are of the same kind:

  var box = rectangle {...

My personal preference to solve the two issues in one go would be to use : to mark the type (which could be omitted in case of auto inference) and make 'var' mandatory:

  var x : u8 = 27
  var y : = 'hello'
  var f : fn(int)->int = {

With : repurposed, it can't be used for the return type; I used -> as in other languages.

Now a macro or reader looking for the declaration of x, y or f knows exactly what to look for. Now types can only appear after a : or the keywords 'type' and 'as' (unless the syntax of the latter elements is changed to 'type:' and 'as:').

And talking about 'as', its priority must be clarified:

  z = a * -b as int

Does 'as int' apply to b, to -b, to the whole product, or to z?

I like how easy it is to declare union or sum types with '|', but the need to use 'as' and 'let' after an 'if ... is' makes it clumsy. Lazy programmers, the ones that wouldn't check for NULL in C, will simply add a 'let' here and there and perpetrate Tony hoare's billion-dollar mistake.

Finally, I'd like to understand exactly how the parser handles new lines. It looks like they end a statement, but are ignored in other contexts.