You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
NOTE: If we want to compile with -fno-exceptions, we'll also need to remove any dependencies (including the C++ stdlib) which are using exceptions. This may be a huge undertaking.
The text was updated successfully, but these errors were encountered:
Is this now just a "simple" task of implementation or is there more design left to be done?
I think that it's mainly down to tackling the huge implementation at this point. We'd need to remove exceptions from everywhere in jank and replace them with result<T, E>. From there, we can change function codegen to always return a result type, too. Overall, it's likely a couple months worth of work, which is why I can't prioritize it until after jank is released.
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
andtry
. 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 valuetry
becomes an extra bit of logic that, rather than early returning on an error, jumps to thecatch
block (and, if needed, thefinally
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.NOTE: If we want to compile with
-fno-exceptions
, we'll also need to remove any dependencies (including the C++ stdlib) which are using exceptions. This may be a huge undertaking.The text was updated successfully, but these errors were encountered: