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

[Israel Matos]

On Tuesday, 5 May 2026 at 12:20:10 UTC, Marconi wrote:
> On Monday, 4 May 2026 at 18:40:59 UTC, Dejan Lekic wrote:
>> On Sunday, 3 May 2026 at 18:46:08 UTC, Marconi wrote:
>> PS. you do not need AI to speak to humans on this forum. Use 
>> your own brain to compose words into sentences and write them 
>> here. :)
>
> No way! :-) just kidding
>
> I change this language a lot since post one.
>
> [Github](https://github.com/soldate/kite)
>
>
> AI:
> Kite is an experimental “pretty C” language: Java-like object 
> references, C-like control, no GC, and no hidden ownership 
> model. Its main idea is that dangerous choices are explicit: 
> heap allocation goes through program-owned hooks, stack storage 
> uses `stack`, nullable/raw access uses `pointer`, and cleanup 
> uses `delete`.
>
>
> ```c
> // Kite code lives inside `type` or `special type` blocks.
> //
> // `special type memory` is the program-owned memory policy.
> // Normal object and array heap allocations pass through 
> `on_heap`.
> // This is not a GC: the program still decides when to release 
> memory.
> special type memory {
>     list heap_objects;
>
>     pointer on_heap(int size, int type) {
>         pointer p = allocator.alloc(size);
>
>         // The compiler exposes stable type ids such as 
> `node.id`,
>         // so the owner can track allocations by type if it 
> wants.
>         if (type == node.id) {
>             heap_objects.add(p);
>         }
>
>         return p;
>     }
>
>     void on_delete(pointer p, int type) {
>         if (type == node.id) {
>             heap_objects.remove(p);
>         }
>
>         allocator.free(p);
>     }
>
>     void clean_heap() {
>         heap_objects.delete_all();
>     }
> }
>
> // A normal user-defined type.
> // Object variables are references, not C-style stack structs.
> type node {
>     int value;
>     pointer node next; // explicit nullable/raw pointer; can be 
> 0
>
>     void init(int v) {
>         value = v;
>         next = 0;
>     }
> }
>
> special type main {
>     void main() {
>         // Heap object by default.
>         // This calls memory.on_heap(...), then node.init(10).
>         node a = node(10);
>
>         // References are non-null by default.
>         // `b` refers to the same object as `a`, like a Java 
> reference.
>         node b = a;
>         b.value = 20;
>
>         // Stack storage must be requested explicitly.
>         // This is still a non-null node reference, but backed 
> by local storage.
>         stack node local = node(30);
>
>         // Arrays follow the same rule:
>         // without `stack`, storage is heap storage and goes 
> through memory policy.
>         int[] dynamic_numbers = [1, 2, 3];
>         int[3] fixed_numbers;
>
>         fixed_numbers[0] = dynamic_numbers[0];
>         fixed_numbers[1] = dynamic_numbers[1];
>         fixed_numbers[2] = fixed_numbers[0] + fixed_numbers[1];
>
>         // C-style control flow, required semicolons, 
> fixed-size primitive types.
>         for (int i = 0; i < fixed_numbers.length; i = i + 1) {
>             console.write(fixed_numbers[i]);
>         }
>
>         // Manual lifetime.
>         // `delete` calls memory.on_delete(...) when the owner 
> defines it.
>         delete a;
>
>         // Owner-level cleanup can also be explicit.
>         memory.clean_heap();
>     }
> }
>
> ```
>
> Beautiful, isn't it?

Thing is: all the langugages you mentioned fix problems in 
different ways.

D fixes most of C++ problems...but can still blow you up if 
musised.
Rust make sure that you wont blow up 90% of the time and that's 
revolutionary. (unless unsafe {} bullshit).
C++ tries to stop the timer of the bomb but you trip on a ton of 
wires and blow up.
C you set up the bomb yourself and blow you up.

You __can__ have a hybrid model. But only if you can infer the 
mode you're currently working in, if you handle everything, then 
the compiler does, but also some undefined behavior too because 
why not? Makes it even harder to solve it. If you develop a 
language that:

1. You handle everything + memory.
2. It has a "hybrid" memory model // can have it, but rules are a 
must have
3. It's OOP                       // kinda makes sense for the 
first iteration but ... essentially actors now, like in Elixir.
4. The program cant free memory alone, unless you do it manually.
5. But it also frees memory automatically sometimes 🤡

If you go manual, you go all the way up and then maybe add a 
GC-ish compiler.

You're basically trying to make Smalltalk with a pretty syntax 
and adding pointers and undefined behavior and a lazy GC.

And since you want OOP-ish state you aren't making just a bomb, 
you're making both a memory hog and a nuke. What if theres a 1000 
instances of the same object? All of them with their own 
authorities? At this rate, they are essentially actors or message 
based concurrency. You could theroetically do it with a mother 
object at the start of the program, and design heavily in and 
hierarchy based system.

Sorry if that felt harsh, but its getting inconsistent and hard 
to reason about. Intent does not prevent bugs. You essentially 
have something closer to Java/Python/Nim/Elixir 
syntactically...but behaves just like C/C++ and tries to be Java. 
With OOP-ish state, well its hard without a global GC.

Right now since its the first stage of your project, I think you 
should focus on one: the programmer frees it, the GC frees it or 
RAII frees it or the objects frees it.