#+TITLE: Undâr Roadmap
#+AUTHOR: Zongor
#+EMAIL: archive@undar-lang.org
#+DATE: [2025-04-05]
#+LANGUAGE: en
#+OPTIONS: H:4 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+STARTUP: align fold nodlcheck hidestars oddeven lognotestate
#+TAGS: { TODO(t) NEXT(n) DONE(d) | HOLD(h) WAITING(w) CANCELLED(c) }
#+PROPERTY: header-args :tangle-mode (identity #o0644)

* Roadmap

** Memory System Improvements
in the beta phase the bump allocator will be removed and replaced with the following system: instead of the bump allocator memory and registers being separate, the frames are in vm memory and then dynamically allocate a frame and register with a size each time a function gets called of a particular arena size. the syntax would be fnN where N is the number is the size in kb for that particular frame, however the compiler will split up the available memory for that architecture into function arenas of the defined "theoretical maximum" of running coroutines. the "maximum" is going to be whatever is hardcoded for the VM, like 1MB or 100MB or 1GB or whatever. The true max will be <4GB because that is all that can be addressed by a u32. the sizes we can say that for a particular architecture has n many 128kb function and y many 8kb functions and so on; then the compiler could partition the system and report that the program requires x of this many slots of this size and y slots of another size. for strings we will extend the syntax we can use str8 is 8 bytes or str16 is 16 bytes or whatever, that way we have a shorthand that is consistent with the rest of the language and is friendly to new developers; however we would keep array syntax the same as in c-like languages `<type>[size]`. the stack and return stack need to be removed as well; like imagine you push some value onto the stack and then switch coroutines and then in that one it pops or pushes that would break. instead we will have a tiny stack per frame for function arguments and have a "return register" to allocate where the function should return to when it finishes. if it gets called recursively it will just take up a new block of the same size. recursive calls should be discouraged in general for this reason, its not a good technique for embedded development or permacomputing. so yes, it *will* compile, but guarantee the compiler *will* make surreal comments about your code. The compiler output in general should have an [[esolangs.org/wiki/INTERCAL][INTERCAL]] feel to it; the compiler needs to not take itself too seriously, but that does not mean it should not give useful advice to the programmer.

** Coroutine System

coroutine system that uses the yield keyword so that functions can run out of order. make all functions coroutines i.e. they should be first class objects in the vm. the system will work similar to a real time microkernel based os like qnx. when a coroutine yields the system will continue from the last function that was running, or it will continue in the "main function" which may spawn new coroutines. each call will allocate a new block in memory. there will also be a "behavior" system where a specific coroutine might have "restart on fail" where others might have "exit on fail" or still others might have "crash on fail", this allows for systems to react to changing external factors. in the long long term (post 1.0) i want to make coroutines similar to beam where they run mutithreaded an use mailboxes and message passing to communicate.

** Example: Hello world (=hello.ul=)

*WIP syntax, not final implementation**

#+BEGIN_SRC ul
fn main(int argc, str[] argv) {
  print("nuqneH 'u'?");  
}
#+END_SRC

** Example: 3D Client (=client.ul=)

**WIP syntax, not final implementation**

#+BEGIN_SRC ul
use "common.ul";

fn256 main(int argc, str[] argv) {
  nat w = 800, h = 450;
  Player me(argv[1], [0.0, 1.0, 2.0], PURPLE);

  bool running = true;
  while (running) {
    window("Client", w, h) {
      splitbox(parent.size, 0.25) {
        canvas() {
          if (button("Logout")) {
            me.logout();
            running = false;
          }
        }
      }
      splitbox(parent.size, 0.75) {
        canvas() {
          model(Floor([0, 0, 0], 30));
          me.update();
          model(Cube(me.pos, [0.5,0.5,0.5], me.color));
          if (Player[] others = me.server.read("players")) {
            for (p in others) {
              model(Cube(p.pos, [0.5,0.5,0.5], p.color));
            }
          }
        }
      }
    }
  }
  exits("Client Closed Successfully");
}
#+END_SRC

** Plex

A =plex= is a structure which, works like a struct but syntactically looks like a class. the naming of "plex" comes from douglas ross's paper "a generalized technique for symbol manipulation and numerical calculation". It is used instead of "class" or "struct" is to make a break from the historical baggage of "classes". unlike classes it does not describe a object in real life and copy it, but it allows for a convenient way to mediate states and handling. i.e. compositions + encodings instead of oop/polymorphisms. for example, instead of having a struct with a bool flag in it (like for a game alive/dead), we can create a multilist where the structs move from a "alive" list to a "dead" list; or things like that. instances of a plex in memory are called "atoms".

Plexes support permacomputing by allowing the developer to use lower level interfaces with a friendly syntax.

**WIP syntax, not final implementation**

#+BEGIN_SRC ul
plex Player {
  str name;
  real[3] pos;

  init(str name, real[3] pos) {
    this.name = name;
    this.pos = pos;
  }
  update() {}
  logout() {}
}
#+END_SRC

the language is statically typed and similar to c but with some array semantic ideas from fortran like row major, fortran style replaces need for vec or mat. arrays are first class values, the compiler uses optimized opcodes for array manipulation. 

**WIP syntax, not final implementation**

#+BEGIN_SRC ul
real[3] pos = [1.0, 2.0, 3.0];
real[3][3] mat = identity(3);
real[3] result = mat * pos;  ! compiler generates matrix-vector multiply
#+END_SRC

- Row-major order
- Fat pointers for slices and strings
- No =vec3=/=mat4x4= structs needed
- Supports composition, slicing, element-wise ops

it has a abstraction layer for devices that work as system calls that can open, read, write, close, and use ioclt for extra system calls that are beyond ops. 

** Devices

(partially implemented)

core devices include 
- screen
- mouse
- keyboard
- terminal
- tunnel

Devices are accessed via a namespace "path/to/device" and are implemented outside of the VM's runtime. This allows for the interface of the system to be the same within the VM but allow for specific variations on a concept depending on the device it is running on.

*** Immediate Mode GUI

UI elements are draw directly on the canvas and syntaically are spacial to show which elements are child elements of each other. Calling a function is the equivelent of a redraw of that element

*** 3D Modeling

3D Primitives + Constructive solid geometry (Simialr to OpenSCAD or .kkrieger) allow for the construction of more complex 3D models from the manipulation of primitives. It also has the ablity to create textures dynamically similar to .kkrieger, textures can be imported and auto mipmaped from larger sizes down to the internal RGB332 + 8x8 - 32x32 tile system.

** Tunnels: Unified I/O (Plan 9 / 9P-Inspired)

Tunnels are an abstraction called a tunnel which acts like a device like a screen, mouse, etc. that is inspired by Plan9. Plan 9 was an operating system developed at Bell Labs that treated all resources (including network connections and UI elements) as files in a hierarchical namespace. it allows files, web requests, sockets, etc. to be viewed through a simple unified interface. it is very similar to the 9p protocol where everything is a file in a filesystem, it just might be a file located on a server halfway across the world or on another planet. the only thing that is the difference is that it takes longer to read the file on mars compared to the file on your local system. the way the device system works is that it is written by a developer in another language like c, but from Undâr's pov the interface remains the same, its just a namespaced device like all the other devices, so that it is easy to understand by a new developer. so it is comparable with tcp/udp sockets or something esoteric like a lorawan network, or some new communication method that hasn't been invented yet.

**WIP syntax, not final implementation**

#+BEGIN_SRC ul
Tunnel server = Tunnel("tcp://localhost:25565");
if (server.attach(auth)) {
  Player[] players = server.read("players");
  server.write("me", me.update());
  server.clunk();
}
#+END_SRC

*** Tunnel Operations

| Op         | Meaning                                                           |
|------------+-------------------------------------------------------------------|
| =.attach()=  | Authenticate and open communication                               |
| =.open()=    | opens a tunnel for doing operations on                            |
| =.create()=  | creates the plex from the database graph file from file structure |
| =.remove()=  | removes the plex from the database graph file from file structure |
| =.read()=    | reads from a tunnel                                               |
| =.write()=   | writes to a tunnel                                                |
| =.walk()=    | moves around the filesystem or through the graph                  |
| =.flush()=   | cancels long operation and dumps whatever is in buffer            |
| =.clunk()=   | Close communication                                               |
| =.stat()=    | returns the status of the file resource                           |
| =.version()= | returns the version code for the connected tunnel                 |