package-type imports

TODO.md

@@ -1,22 +1,44 @@
-# "quick" fixes
+# "quick"/"easy" fixes
 
 - for global initialization cycles, report also starting and ending lines
 
+- intern strings across all phases of the compiler and reference strings by their hash/id
+  - makes string comparison and equality checks faster and takes up less memory
+
 # milestones
 
-1. import system:
-  - directory level package style like odin (and go?)
-  - globals in different files under same package are automatically merged into same namespace
-  - globals defined in different packages must be imported via their package
-  ```
-  import "some_package" # automatically imports all public globals under `some_package`
-  other_name :: import "some_package" # imports all public globals under `some_package` into `other_name` namespace
-
-  some_package.hello # accesses the `hello` global from `some_package`
-  other_name.hello # accesses the `hello` global from `some_package` via `other_name` namespace
-  ```
-
-2. get c interop working:
+1. get c interop working:
   - link with c / compile c code into binary alongside brolang code
   - create bindings from c headers
+  - figure out how to represent variadic arguments
+    - proposal (from an older document):
+      ```
+      # functions with variadic arguments
+      printf :: c func(fmt []u8, args ...) int  # `...` is essentially an anonomous tuple type used in function arguments. `...` collects remaining arguments in a type inferred tuple (infer from anchor)
+      ```
+      - notes on structs and tuples from same older document:
+        ```
+        # structs carry only data, no methods, no behavior
+        Stuff :: struct {
+            first u32
+            second float
+            third [5]i32
+        }
+        
+        # tuples are just structs without field names (accessed via index: ``some_tuple.0``, ``some_tuple.1``, etc.)
+        # anonomous tuple type inferred from literal and type anchors?
+        some_tuple :: { 4, "hello" }
+        ```
   - find out how this should co-exist with the import system
+    - maybe c header files should just be treated as individual packages
+      - that is also typically how they're used in c projects as they define an interface to a module (or package)
+      - that means that bindings should be automatically generated by the compiler when the user imports a c header file:
+        - `import "relative/path/to/some_header.h"` - wraps the c header file in a brolang package called `some_header`
+        - `other_header :: import "relative/path/to/some_header.h"` - wraps the c header file in a brolang package called `some_header` into `other_header` namespace
+        - implementation of the functions declared by the generated bindings is provided by the c implementation and requires the c implementation to be linked with the brolang binary
+      - this requires the ability to declare a "bare" function (as an interface) that is linked to the c implementation
+        ```
+        # declare the bare extern function for c interop (notice only the signature is provided, not the implementation)
+        # this should only be allowed for extern functions, i.e. `c func`
+        extern_c_sum :: c func(a, b int) int
+        ```