The Dio Programming Language

Nulls And Errors Must Be Checked

Take this example code. The compiler will report two errors

//At the moment unions may only be one type and error
example(int? value) int | error {
if value < 0 {
return 1
}
return error
}

main() int
{
val = example(null)
return val
}
Error 3,8-13: Variable must not be null (value)
Error 11,11-18: Must handle error case for function (example)

When working with integers it'd be extremely weird if both "value<0" and "value>=0" are both false. Whenever something is null it must be checked before using the value. Errors must always be checked, but have a special syntax

example(int? value) int | error {
return -1 if value == null
if value < 0 {
return 1
}
return error
}

main() int
{
val = example(null) ## {
return 2
}
return val
}

Variables Are Marked

In many languages a programmer may assume a variable might be modified when it is passed into a function. In C and C++ it is extremely common to use pointers and the 'const' keyword to prevent the pointer from being modified. Lots of data are reused across objects and usually those languages speed is important and objects are reused. Conditionally modifying data may surprise programmers and cause bugs.

In dio the calling function has to use symbols to denote what data may be modified an what data is given away. NOTE: Next release may offer alternative syntax

example(int a, b`; u8[25] c@) void { c[0]`=b; b`=a; }

main() int
{
a``=5 //you may write "a=5" since a is never modified in this example
b``=6
c``=$u8[25]
example(a, b`, c@)
puts(itoa(b))
return 0
}

Here we can plainly see b might be modified and c is given away. Using c after the function call will cause an error

Miscellaneous

Minor improvements were made to prevent annoyance and errors due to typos some are

  1. Int's are not bools. So if 1 and intValue && intValue2 are compile errors
  2. Operator precedence has been changed. The bit operators (& | ^) are higher precedence than compare (==, !=) so 6&2 != 0 is true and 6|2 != 0 doesn't magically become a 7
  3. Because = creates a variable accidentally writing if a=b will cause a compile error even if a and b are bool
  4. Writing a|b&c will cause a compile error since it's easy to confuse the precedence order. Currently the compiler allows this syntax. Earlier the compiler gave a syntax error and stops which was annoying so it was disabled. Later the compiler will report this as a logical error.