This language looks super promising. With the exceptions of 'no type inference' and 'no arithmetic precedence', I really like its anti-features list.
With regard to 'no arithmetic precedence', I tried
printLn((1 + 2) + 3);
and
printLn(1 + 2 + 3);
Sure enough, the first one compiles, but the second doesn't.
Also, (n-1) is a parse error unless you put a space after the minus.
I got curious if recursion was properly handled, given it wasn't in the anti-features list, but no luck:
module body Foo is
function go(acc: Nat64, n: Nat64): Nat64 is
if n = 0 then
return acc;
else
return go(acc + n, n - 1);
end if;
end;
function main(): ExitCode is
printLn(go(0, 135000));
return ExitSuccess();
end;
end module body.
I prefer the rule in my own languages of "no arithmetic expressions whose meaning can be changed by adding parentheses". So `x + y - z` is allowed but `x - y + z` is not.
If operators are over-loadable, you support floats (in a non ffast-math mode), or you treat overflow in most non-modular-arithmetic ways, (x + y) - z and x + (y - z) are different.
Maybe it's worth saying "they're close enough to the same that parentheses should be optional", but I can definitely see the argument for just requiring them regardless.
Valid point, though my current language supports neither overloading, floats, nor non-modular integer overflow, and parentheses are permissible where not required (for extra-semantical cases where order does matter) :)
I wouldn't rely on TCO being available, the bootstrapping compiler right now just emits very simple C (though GCC/LLVM might eliminate the recursion if they can).
Ideally I'd like stack overflow to be a clean abort rather than a stack overflow (just to make the error message more explicit) but I haven't got around to adding that.
That's curious - one of the example programs computes the fibonacci sequence. The language is clearly still a work in progress. I wonder what the difference is in your recursion and what's listed?
I disagree with you about 'no type inference'. I understand why some swear by type inference, but personally I prefer the complete clarity it provides to avoid it. If writing those characters annoys you, have tooling help you with avoiding that.
With regard to 'no arithmetic precedence', I tried
and Sure enough, the first one compiles, but the second doesn't.Also, (n-1) is a parse error unless you put a space after the minus.
I got curious if recursion was properly handled, given it wasn't in the anti-features list, but no luck:
yields