jank already uses value-based errors for internal systems, such as the lexer and parser, but Clojure-looking systems use exceptions. On top of that, Clojure itself demands support for throw and try. In those areas, we're using exceptions. This limits the portability of jank, though, and it comes at a cost in binary size as well as performance in those exceptional scenarios.
Chris Lattner explains here how Mojo is replicating exception semantics using value-based errors. This enables much more portability, such as running on both embedded systems and also GPUs, where exceptions may not be usable.
In short, he described it this way: If every function returns a result<T, E>, we can replicate exception semantics like so.
throw just becomes an early return with an error value
Every function call gets its result checked and, if it's an error, the function early-returns the error (which then gets returned upward)
try becomes an extra bit of logic that, rather than early returning on an error, jumps to the catch block (and, if needed, the finally afterward)
So this will require some codegen work. It will also require removing all exception throwing/catching from jank's code, in favor of result usage. This is the direction I've been pushing jank and Chris' confirmation here only helps with that momentum.
jank already uses value-based errors for internal systems, such as the lexer and parser, but Clojure-looking systems use exceptions. On top of that, Clojure itself demands support for
throwandtry. In those areas, we're using exceptions. This limits the portability of jank, though, and it comes at a cost in binary size as well as performance in those exceptional scenarios.Chris Lattner explains here how Mojo is replicating exception semantics using value-based errors. This enables much more portability, such as running on both embedded systems and also GPUs, where exceptions may not be usable.
In short, he described it this way: If every function returns a
result<T, E>, we can replicate exception semantics like so.throwjust becomes an early return with an error valuetrybecomes an extra bit of logic that, rather than early returning on an error, jumps to thecatchblock (and, if needed, thefinallyafterward)So this will require some codegen work. It will also require removing all exception throwing/catching from jank's code, in favor of
resultusage. This is the direction I've been pushing jank and Chris' confirmation here only helps with that momentum.