Tags

, , ,

Optional values are one of the fundamental extrinsic types in Leaf, as are shared values. Originally optional values were used just like regular values, dereferenced automatically. I was always uncertain of that. It made the code simple but it didn’t hold up to a promise of safe code. It was essentially a null pointer error in disguise. I’ve since removed the automatic dereferencing.

Quick syntax introduction

Optional values can be created using the ? operator. Unlike the traditional cond ? true_val : false_val ternary operator, Leaf splits this up into two fundamental operators.

1
2
var a : integer = 5
var b = cond() ? a

The above creates an optional integer value, either it is 5 or unset.

1
var c = b | 10

The | is a default operator. The above expression will be the value of b if set, or 10 if not set. Together these look like the traditional ternary operator:

1
var d = cond() ? 5 | 10

If cond() is true then d == 5 otherwise d == 10. By splitting up the syntax we get the more generic ? and | operators. These help integrate optional types fully into the language.

Type declaration

The syntax for declaring an optional in Leaf is simply add optional to the type:

1
2
var a : integer optional
var b : pine optional

It can also be added to an inferred type, for example in the case of a parametric function that can take any optional argument:

1
defn leaf = ( a : optional ) -> { ... }

Dereferencing

Originally I had the language automatically derefernce optionals. In the below function the optional arguments could be used directly.

1
2
3
defn leaf = ( a : integer, b : optional integer ) -> {
    return a + b
}

The same could be done for fields in a class or tuple.

1
2
3
4
5
6
7
typedef point : [
    x : integer
    y : integer
]

var p : optional point
std.print(p.x)

The above would raise an error since p has no value (the default of any optional type is to not have a value).

As convenient as this was, it started to feel like it was just hiding errors. I decided this automatic dereferencing should be removed.

Using the | operator

The | can be used to avoid any explicit dereferncing.

1
2
3
defn leaf = ( a : integer, b : optional integer ) -> {
    return a + (b | 5)
}

The expression b | 5 will use the value of b if available, or 5 if it is not set. This is the desired way to work with optionals. The compiler doesn’t let you ignore the fact that b may not be defined, thus no error is now possible.

The future ?. operator

It’s not quite complete when dealing with fields however:

1
2
var p : optional point
str.print( p.x | 5 )

This will still raise an error as p.x cannot be resolved. Without a terse way to deal with this we’d end up with syntax bloat on optionals. I am going to add an optional operator ?. to deal with this:

1
std.print( p?.x | 5 )

p?.x evaluates to the value of x if p has a value, otherwise it evalutes to an optional unset value. This will work in a chain as well:

1
std.print( a?.b?.c?.d | 5 )

Explicit dereference

There are some situations where an explicit dereferencing of the optional are required. For that I added the unopt operator.

1
has(p) then std.print( unopt(p).x )

unopt(p) raises an error if p is not set, that’s why I check if with has(p) first. I’m not entirely certain of the name unopt yet, and it might still be changed. I just wanted to start with an unambiguous name.

Advertisements