These few commits add support for the optional syntax (?) in the parser and AST nodes. Now, as it turns out, the golang implementation hasatype Optional struct, whichimplementstype Val interface...

So I can either "hack" that in the current interpreter (i.e. probably short-circuit interpretation, and "early" returnNull), or... I guess it's what I'd recommend anyways, I start revisiting the whole type system. Which also leads me to bunch of questions. Including the need forValue to own "thread safe" values... I never really got why this is dealt with at that level in the "graph". As a CEL expression is to be immutable (modulo some cases e.g. the accumulator in macros), and even if an expression is to be shared across thread for concurrent execution, wouldn't it be theContext that should be thread safe, and can't we consider the expression as immutable, possibly the expression being reference counted?

Anyways, I guess I'm opening quite a can of worms here. But I think I'd be tempted to start exploring revisiting the type system, leave thread-safety aside, if only for now. There, my first question becomes: should we go fordynamic dispatch (i.e. have a it all model with traits) or would it be nice to keep things as concrete as possible? I feel the go implementation has a bit of "interface derangement syndrome", but it might also all be for a good reason...