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

[H. S. Teoh]

On Wed, Apr 29, 2026 at 05:50:08PM +0000, Marconi via Digitalmars-d wrote:
[...]
> The core idea is simple, but strict:
> 
> There is no static code. Everything is object-oriented.

Why object-oriented?  There are many programming problems that are
better solved with other paradigms.


> No static methods, no global functions, no hidden global state.

Sounds like it will be far removed from the machine.  How exactly do you
plan to map the high-level code to machine code?


> 🔹 Core model
> 
> Every method call has two explicit references:
> 
> this → the object whose method is being executed
> caller → the object that initiated the call
[...]
> 🔹 Why introduce caller?
> 
> Most languages implicitly lose track of who requested an operation.
> 
> By introducing caller, we make this explicit:
> 
> The callee knows who is asking
> The caller retains control over resources and error handling

Interesting concept.  Curious to find out where you go with this, it
looks like there might be some interesting consequences.


> 🔹 What this enables
> 
> 1. Memory allocation controlled by the caller
> 
> Instead of allocating memory implicitly, the callee can request it:
> 
> buffer = caller.alloc(size)
> 
> This prevents hidden allocations and makes ownership explicit.

So every caller must implement an allocator?  And since I can't imagine
every object implementing its own allocation scheme, I'd imagine the
result would be that it would shunt calls to .alloc to *its* caller,
etc., until it ends up in main() or whatever the top-level caller is?


> 2. Explicit error propagation
> 
> Instead of throwing exceptions globally:
> 
> caller.error("Something went wrong")
> 
> Errors always return to the origin of the operation.

I like this idea.  Let the caller decide what to do when an error
condition is encountered.

But how do you handle the case when the caller doesn't have the context
to know what to do?  Manually bubble the error condition up the call
chain?  The further removed from the source of the error, the less
likely the code will be able to recognize the error (even though it
would probably have more context to know what to do with it).

So either the top-level caller will have to specialize on every single
possible error down its entire call-chain (an impractical proposal), or
all errors eventually will turn into a generic failure condition because
once you go past the first level of caller, nobody knows what to do with
it anymore except treat it as an opaque generic failure.


[...]
> 🔹 Base Object
> 
> A root Object class could provide minimal operations like:
> 
> printing
> memory allocation (via caller or delegated components)
> error reporting
[...]

Again, why objects?  Experience shows that OO isn't the best model for
many programming problems.  It works well when the problem space maps
well to the OO model, but when it maps poorly, you start to see code
smells and antipatterns like singleton classes (basically global
functions and state masquerading as members), needless indirection
(boxing PODs and the resulting mess of incompatible types for the same
values), downcasting, etc..

A simple example is standard math functions.  These are global,
stateless functions that don't allocate or raise error conditions.  How
would you represent them?  Where would you put them, since you prohibit
global functions?  I guess in a singleton class?  How would you prevent
the user from creating multiple instances of this class?  What would it
mean for there to be multiple instances of a Math class?  (I consider
singleton classes an antipattern.)

Also, how would you interact with the outside world?  If you need to
call an external library, for example, how would you represent the
global state internal to that library?  What about I/O?  How would you
represent global state change induced by an I/O operation, e.g., writing
data to a file that alters OS behaviour?  Wouldn't that be "hidden
global state"?  Unless you represent it explicitly somehow -- but how?
As another singleton class?  (Which again is an antipattern, because
you've just reintroduced global state after so meticulously getting rid
of it.)


T

-- 
Talk is cheap, because the supply is always greater than the demand.