Change some definitions and remove thoughts.md

README.md

@@ -39,6 +39,7 @@ Generic lisp synatx highlighting should provide good results, however.
 * Proper tail calls.
 * Direct interop with C via abstract types and C functions
 * Dynamically load C libraries
+* Functional and imperative standard library
 * Lexical scoping
 * Imperative Programming as well as functional
 * REPL
@@ -88,7 +89,7 @@ make test
 
 ### CMake
 
-On a posix system using make as the backend, compiling and running is as follows (this is the same as 
+On a posix system using make as the backend, compiling and running is as follows (this is the same as
 most CMake based projects).
 
 ```sh

src/core/gc.c

@@ -385,5 +385,5 @@ void dst_clear_memory(void) {
 }
 
 /* Primitives for suspending GC. */
-int dst_gclock() { return dst_vm_gc_suspend++; }
+int dst_gclock(void) { return dst_vm_gc_suspend++; }
 void dst_gcunlock(int handle) { dst_vm_gc_suspend = handle; }

src/core/gc.h

@@ -39,9 +39,6 @@
 #define dst_gc_unmark(m) (dst_gc_header(m)->flags &= ~DST_MEM_COLOR)
 #define dst_gc_reachable(m) (dst_gc_header(m)->flags & DST_MEM_REACHABLE)
 
-// #define dst_gclock() (dst_vm_gc_suspend++)
-// #define dst_gcunlock(lock) (dst_vm_gc_suspend = lock)
-
 /* Memory header struct. Node of a linked list of memory blocks. */
 typedef struct DstGCMemoryHeader DstGCMemoryHeader;
 struct DstGCMemoryHeader {

src/core/wrap.c

@@ -111,14 +111,14 @@ Dst dst_wrap_nil() {
     return y;
 }
 
-Dst dst_wrap_true() {
+Dst dst_wrap_true(void) {
     Dst y;
     y.type = DST_TRUE;
     y.as.u64 = 0;
     return y;
 }
 
-Dst dst_wrap_false() {
+Dst dst_wrap_false(void) {
     Dst y;
     y.type = DST_FALSE;
     y.as.u64 = 0;

src/include/dst/dst.h

@@ -161,7 +161,7 @@ void dst_clear_memory(void);
 void dst_gcroot(Dst root);
 int dst_gcunroot(Dst root);
 int dst_gcunrootall(Dst root);
-int dst_gclock();
+int dst_gclock(void);
 void dst_gcunlock(int handle);
 
 /* Functions */

src/include/dst/dstconfig.h

@@ -91,7 +91,10 @@ extern "C" {
 #define DST_LITTLE_ENDIAN 1
 #endif
 
-/* Check compiler */
+/* Define how global dst state is declared */
+#ifdef DST_SINGLE_THREADED
+#define DST_THREAD_LOCAL
+#else
 #if defined(__GNUC__)
 #define DST_THREAD_LOCAL __thread
 #elif defined(_MSC_BUILD)
@@ -99,6 +102,7 @@ extern "C" {
 #else
 #define DST_THREAD_LOCAL
 #endif
+#endif
 
 /* Include default headers */
 #include <stdint.h>
@@ -112,7 +116,7 @@ extern "C" {
         __LINE__,\
         __FILE__,\
         (m));\
-    exit(-1);\
+    exit(1);\
 } while (0)
 #endif
 

src/include/dst/dsttypes.h

@@ -348,11 +348,11 @@ struct Dst {
 #define dst_unwrap_integer(x) ((x).as.integer)
 #define dst_unwrap_real(x) ((x).as.real)
 
-Dst dst_wrap_nil();
+Dst dst_wrap_nil(void);
 Dst dst_wrap_real(double x);
 Dst dst_wrap_integer(int32_t x);
-Dst dst_wrap_true();
-Dst dst_wrap_false();
+Dst dst_wrap_true(void);
+Dst dst_wrap_false(void);
 Dst dst_wrap_boolean(int x);
 Dst dst_wrap_string(const uint8_t *x);
 Dst dst_wrap_symbol(const uint8_t *x);

thoughts.md

@@ -1,64 +0,0 @@
-# Thoughts
-
-A collection of thoughts and todo tasks for the project.
-
-- Remove the concept of 'Ast node'. While providing fine-grained source mapping is
-  is reasonably useful, it complicates the implementation of macros and other source
-  transforming operations. Instead, we can key collection types (which have the unique
-  pointer property) to source mapping information in a external data structure, which is specifically
-  for source mapping. This data structure would be a hash table that used pointer equality
-  instead of value equality for entries.
-
-  The compiler would then need to keep track of 'most specific collection' node when compiling,
-  as the value itself would not always be a collection and contain source mapping information.
-
-  As a result, we could remove special forms like 'ast-quote', as well as ast-unwrapping logic
-  which potentially duplicates a fair amount of data. Macros would be easier to write without
-  needing to either unwrap ast values or sacrifice all source mapping.
-
-- Serialization and deserialization of all datatypes. This would allow loading of bytecode
-  without needing the compiler present. However, loading C functions is currently problematic.
-  C functions could perhaps be wrapped in data structures that contain some meta information
-  about them, say home module and types. This could also allow some automated type checking for
-  C functions rather than writing it manually. Some slight overhead could perhaps be compensated
-  for by adding optional ommission of typechecking later for C functions if it can be statically
-  shown the types are sound.
-
-- Better support for custom user datatypes. Tables and structs do work well for creating
-  custom 'objects' and records, but lack ability to differentiate between object style
-  values and data structure style values. For example, simply adding special keys as fields
-  would make plain a table or struct possibly become object-like if the write keys are added.
-
-  A Lua like solution would be metatables. It would perhaps make sense to only allow
-  metatables on tables, as object like behavior seems to makes most sense on mutable data (?).
-  For example, metatables on a struct could allow non-pure behavior unless they were extremely
-  limited, or purity was enforced somehow. This could break expectations of a struct to behave
-  as immutable data.
-
-  Also, it might make sense that the metatable of a value would actually be a struct, so
-  a metastruct. Implementations of Lua (LuaJIT) do not allow (or do not acknowledge) 
-  changing certain values of a metatables after it is set, such as gc, for performance
-  reasons.
-
-  Currently, tables can have a prototype table, which is used to look up values recursively if they
-  are not found in the original table. This provides a partial solution to custom user types,
-  but does not have the felxibility of Lua style metatables.
-
-- Actually make a debugger. While the VM changes to enable debugging are relatively
-  simple, make  a useful debugger would be another project. At first, simply inspection
-  of the generated bytecode assembly would be a good start. Single stepping, continuation, 
-  and inspecting the stack and current fiber would be a start.
-
-  Preferably this would be programmed in dst. The needed functionality could be exposed
-  in the fiber API.
-
-  Later, with information from the compiler, we could inspect variables and upvalues
-  by symbol. The current compiler does not do full SSA optimization, so named values
-  are always accessible in the stack when in scope.
-
-- Create a pool for fibers. Whlie the general purpose allocator and GC can be made more efficient,
-  Fiber's can be well pooled because the allocated stack is large and can be reused. The stack
-  size parameter on dst_fiber could simply become the minimum memory allocated for the stack. (Do
-  a linear search throught the pool).
-
-- Implement multi-methods.