rename some things, create new parser defs.

README.org

@@ -17,7 +17,7 @@
 
 * Undâr
 
-Undâr is a programming language for the purpose of creating 3D games and graphical user interfaces that work on constrained systems, microcontrollers, retro consoles, and the web using emscripten. The language emphasizes hardware longevity, energy efficiency, and the preservation of digital art and games for future generations.
+Undâr is a programming language for the purpose of creating 3D games and graphical user traits that work on constrained systems, microcontrollers, retro consoles, and the web using emscripten. The language emphasizes hardware longevity, energy efficiency, and the preservation of digital art and games for future generations.
 
 It has an internal REPL that allows for quick development as well as the ability to dump the program to a binary rom for preserving that program/game/etc.
 

ROADMAP.org

@@ -214,7 +214,7 @@ function main(int argc, str[] argv) {
 
 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.
+Plexes support permacomputing by allowing the developer to use lower level traits with a friendly syntax.
 
 **WIP syntax, not final implementation**
 
@@ -260,7 +260,7 @@ core devices include
 - 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.
+Devices are accessed via a namespace "path/to/device" and are implemented outside of the VM's runtime. This allows for the trait 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
 
@@ -272,7 +272,7 @@ UI elements are draw directly on the canvas and syntactically are spacial to sho
 
 ** 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.
+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 trait. 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 trait 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**
 

docs/SPECIFICATION.org

@@ -261,7 +261,7 @@ scope closes the tunnel
 note the plex must always be of a plex which is "tunnel-able"
 i.e. Files, sockets, etc
 
-Tunnels have almost the same interface as 9p since they are closely
+Tunnels have almost the same trait as 9p since they are closely
 based on 9p.
 
 *** transplexs for tunnels

src/tools/assembler/assembler.c

@@ -1,34 +1,82 @@
 #include "assembler.h"
 #include <stdio.h>
 
+typedef enum { GLOBAL, LOCAL } ScopeType;
+typedef enum { 
+    VOID,
+    BOOL,
+    I8, 
+    I16, 
+    I32, 
+    U8, 
+    U16, 
+    U32, 
+    F8, 
+    F16, 
+    F32,
+    STR,
+    PLEX,
+    ARRAY,
+    FUNCTION
+ } SymbolType;
+
 typedef struct field_s {
-    char* name;     
+    char *name;     
-    TokenType type; 
+    SymbolType type; 
     u32 offset;     
     u32 size;       
 } Field;
 
-typedef struct plex_def_s {
+typedef struct function_def_s {
-    char* name;
+    char *name;
+    SymbolType args[8];
+    u8 arg_count;
+    SymbolType return_type;
+} FunctionDef;
+
+typedef struct trait_def_s {
+    char *name;
+    Field *fields;
     u32 field_count;
+    FunctionDef *methods;
+    u32 method_count;
+} TraitDef;
+
+typedef struct plex_def_s {
+    char *name;
     u32 logical_size; 
     u32 physical_size;
     Field *fields;
+    u32 field_count;
+    TraitDef *traits;
+    u32 trait_count;
+    FunctionDef *methods;
+    u32 method_count;
 } PlexDef;
 
 typedef struct array_def_s {
-    TokenType type;
+    SymbolType type;
     u32 length; 
     u32 logical_size; 
     u32 physical_size; // logical_size * type_size + 4
+    union {
+        PlexDef *plex;
+        struct array_def_s *array;
+    } ref;
 } ArrayDef;
 
 typedef struct symbol_s {
   char *name;
   u32 address;
-  TokenType type;
+  ScopeType scope;
+  SymbolType type;
   u32 logical_size; 
   u32 physical_size; // logical_size * type_size + 4
+  union {
+    PlexDef *plex;
+    ArrayDef *array;
+    FunctionDef *function;
+  } ref;
 } Symbol;
 
 typedef struct symbol_tab_s {

src/vm/device.c

@@ -10,12 +10,9 @@ i32 vm_register_device(VM *vm, const char *path, const char *type, void *data,
 
   dev = &vm->devices[vm->dc];
   dev->handle = vm->dc++;
-  strcopy(dev->path, path, DEVICE_PATH_MAX_LENGTH);
-  dev->path[DEVICE_PATH_MAX_LENGTH - 1] = '\0';
-
-  strcopy(dev->type, type, DEVICE_TYPE_MAX_LENGTH);
-  dev->type[DEVICE_TYPE_MAX_LENGTH - 1] = '\0';
   
+  dev->path = path;
+  dev->type = type;
   dev->data = data;
   dev->ops = ops;
   dev->size = size;

src/vm/opcodes.h

@@ -95,9 +95,9 @@ typedef enum {
   OP_STRING_TO_REAL  /* string_to_real    : locals[dest] = src1 as real */
 } Opcode;
 
-#define MAX_REGS 32
+#define MAX_LOCALS 32
 typedef struct frame_s {
-  u32 locals[MAX_REGS]; /* R0-R31 */
+  u32 locals[MAX_LOCALS];  /* $0-$31 */
   u32 start;               /* start of memory block */
   u32 end;                 /* end of memory block */
   u32 return_reg;          /* register to store return value in parent */
@@ -124,13 +124,10 @@ typedef struct device_ops_s {
   i32 (*refresh)(void *device_data, u8 *buffer);
 } DeviceOps;
 
-#define DEVICE_TYPE_MAX_LENGTH 16 /* 15 chars + null terminator */
-#define DEVICE_PATH_MAX_LENGTH 64 /* 63 chars + null terminator */
 
 typedef struct device_s {
-  char type[DEVICE_TYPE_MAX_LENGTH]; /* e.g., "screen", "mouse", "gpio" */
+  const char *type; /* e.g., "screen", "mouse", "gpio" */
-  char path[DEVICE_PATH_MAX_LENGTH]; /* "/dev/screen", "/dev/input/mouse/0",
+  const char *path; /* "/dev/screen", "/dev/input/mouse/0", etc. */
-                                        etc. */
   void *data;                        /* device_specific data */
   DeviceOps *ops;                    /* operations vtable */
   u32 flags;                         /* permissions, status, etc. */

src/vm/vm.c

@@ -98,7 +98,7 @@ bool step_vm(VM *vm) {
     return false;
   }
   case OP_CALL: {
-    u8 N, return_reg, src_reg, args[MAX_REGS];
+    u8 N, return_reg, src_reg, args[MAX_LOCALS];
     Frame *child;
     u32 jmp, heap_mask, i;
 

test/paint-bw.ul

@@ -9,7 +9,7 @@ const byte LIGHT_GRAY = 182;
 
 byte selected_color = 255;
 
-interface Device {
+trait Device {
   nat handle;
 }
 

test/paint.ul

@@ -9,7 +9,7 @@ const byte LIGHT_GRAY = 182;
 
 byte selected_color = 255;
 
-interface Device {
+trait Device {
   nat handle;
 }