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

[Marconi]

On Wednesday, 29 April 2026 at 22:51:59 UTC, H. S. Teoh wrote:
> T

Thanks, this is a very insightful response — it helped clarify 
several things for me.

On not taking the idea to extremes

I agree with your point about small, local allocations.

It wouldn’t make sense to force every tiny temporary buffer 
through caller.alloc, especially when the compiler can place it 
on the stack efficiently. That would introduce unnecessary 
indirection and overhead.

So a better distinction would be:

local / temporary data → handled directly (stack, registers, 
compiler-managed)
heap / long-lived / policy-dependent allocation → requires caller 
authority

The goal is not to eliminate direct allocation, but to prevent 
hidden policy decisions in reusable code.

On allocation policies as libraries

Good question.

I think the distinction is that a library that implements an 
allocation policy is not the same as a library that consumes 
allocation.

A data structure (like a linked list) should be agnostic and 
request allocation:

node = caller.alloc(Node)

But an allocator library is itself providing that policy:

class ArenaAllocator {
     alloc(size) { ... }
}

The choice of which allocator to use still belongs to the 
caller/root environment.

So libraries don’t decide policies — but they can implement them.

On the impure nature of the real world

I completely agree here.

The goal is not to pretend the world is pure — that would be 
unrealistic. The OS, filesystem, environment, and many APIs are 
inherently impure and global.

What I’m aiming for is not to eliminate impurity, but to make it 
explicit.

So instead of hidden global access, something like:

caller.fs.open(...)
caller.system.setTimezone(...)

The operation is still impure, and may affect global state — but 
the authority to perform it is explicit in the code.

So perhaps the idea is better framed as:

not removing global effects, but removing hidden access to them.

On your D example (GuiApi)

That example is very close to what I had in mind.

The GuiApi object being passed into the callback is essentially a 
capability — only code that receives it can perform GUI 
operations. That maps very well to the idea of “caller authority”.

The main difference I’m exploring is whether the language could 
make this pattern less verbose.

As you pointed out, once you start passing multiple APIs (GUI, 
allocator, filesystem, network, etc.), the boilerplate becomes 
significant.

So I think language support would be essential here — otherwise 
this pattern becomes too heavy to use in practice.

On the underlying motivation

Your points about reusability and avoiding rewriting code 
resonate a lot with what I’m trying to achieve.

The goal is exactly that:

algorithms should not depend on allocation strategy
logic should not depend on platform or environment
code should be reusable across contexts (GUI, CLI, tests, 
network, etc.)

In that sense, the idea is less about OO per se, and more about:

separating logic from environment and policy.

Refining the idea

Based on your feedback, I think the core principles are better 
stated as:

pure code is free
local temporaries are free
effectful operations require explicit authority
libraries can request resources but should not silently decide 
policies
real-world impurity exists, but access to it should be explicit
language support is needed to avoid excessive boilerplate

So perhaps a better summary is:

Kite does not try to make the world pure — it tries to make 
authority explicit.

Thanks again — this helped a lot in shaping the idea.