Control flow abstraction to avoid built-in exceptions, defer, multi-return, error handling, nil, etc.

basilTeam / basil

Fast and flexible language exploring partial evaluation, context-sensitive parsing, and metaprogramming. Compiles JIT or AOT to native code.

BSD 3-Clause "New" or "Revised" License

124 stars 11 forks source link

Control flow abstraction to avoid built-in exceptions, defer, multi-return, error handling, nil, etc. #22

Closed dumblob closed 3 years ago

dumblob commented 3 years ago

Custom effects like in Koka (https://koka-lang.github.io/koka/doc/book.html#sec-handlers ) seem to be a neat way to abandon nil in Basil as well as exceptions etc. and making these constructs purely user-level and much more flexible.

What do you think?

dumblob commented 3 years ago

As a universal and performant underlying principle CPS as proposed in https://github.com/basilTeam/basil/issues/21 could be used. This way any effect system, coroutine system, multicore scheduling system, etc. can be implemented with ease.

elucent commented 3 years ago

In the interest of keeping Basil's core semantics quite simple (since the partial-evaluation aspect and context-sensitive parser are complicated enough...), I've been shying away from things like an effect system. I do rather like the model as a means for expressing the responsibilities of different procedures...but I haven't really explored it fully enough to see how well it would adapt to Basil (it could be rather difficult to determine effects in compile-time code, for instance, where we can dynamically assemble expressions in function bodies and values are dynamically typed).

The current plan is to use optional/result types for error cases. Some kind of callback or exception system is worth considering for the future, but it introduces a lot of complexity for not, IMO, a tremendous amount of unique useful functionality. Closing for now, but I might refer back to this whenever I have a nice proposal for continuations for Basil (the best exception system for your project is the one you implement yourself...or at least, in theory 🙃).

dumblob commented 3 years ago

If not effects in the broader sense as in Koka, then I'd strongly discourage from any effect or exception system.

In such case I'm a strong proponent of sumtypes with syntax sugar for optionals & results and additional compile time safety guaranteeing no nil/null/none dereference will happen in runtime etc. See e.g. https://github.com/vlang/rfcs/pull/7 how this could be achieved (how to guarantee it is outlined in https://github.com/vlang/rfcs/pull/7#issuecomment-921706984 ).

I think all these guarantees and sumtype semantics (incl. sugar as well as optimized special cases under the hood) could be doable with Basil.

So that'd be my recommendation instead of some special Basil-style exception handling aka poor man's pseudo-effect system :wink:.