A programming language idea: no static code, explicit caller context (Kite)

Marconi soldate at gmail.com
Wed Apr 29 21:23:15 UTC 2026


Thinking more about it, I believe `caller` may be a much better 
fit for resource authority than for error handling.

For allocation, filesystem access, logging, I/O, etc., the model 
feels natural: the callee should not silently decide policies, so 
it asks the caller for authority.

But for errors, the caller is not always the right entity to 
understand what happened. The immediate caller may have less 
context than the callee, and the top-level caller cannot 
reasonably know every possible low-level failure.

So I’m reconsidering the idea of `caller.error(...)`.

A better direction may be to keep errors as a language-level flow 
mechanism, closer to V’s `or` style:

     config = parse(input) or {
         return ConfigLoadFailed(err)
     }

That way, the callee still classifies what failed, each layer can 
translate the error into its own domain, and the caller decides 
policy only when it actually has enough context.

So perhaps:

     caller = authority for resources/effects
     error flow = handled by the language

This seems cleaner than forcing all error handling through 
`caller`.


More information about the Digitalmars-d mailing list