AHelper, how are you planing to handle running the GC system. Will it be entirely random or will it be run automatically at times or what?

This will depend on how it runs. In interactive mode, it should run after evaluation. In bulk execution mode, it should run whenever low on resources.

Now, I could set object freeing to free up memory once all references on an object are cleared. However, by freeing later, I could utilize a system to remove duplicate objects (2+2+2 keeps duplicating '2' objects).

I realize I can't simply call the GC any time I want as unowned nodes created in function execution would be incorrectly freed. To be honest, right now, not 100% sure. I could abort the current expression being evaluated (given the source text is available), free it, run the GC, and try one more time. There really won't be a case where the textual form of the lisp expression isn't available any more.

Changed up ownership to a stricter reference counting system and I have no memory leaks (besides not being able to delete variables which I haven't found possible in Lisp so far). Deletion is performed upon freeing an object rather than waiting for a garbage collection pass. Below is a demo of print (multiargument print command), add (simple integer addition), setf (Similar to setq in Lisp), and mem (Gets RAM usage for global table and all objects, dumps the table showing reference counts as well as associated object).

Code:

setf polished some more and let has a basic implementation. Currently having problems with setf inside of let, such as let((a),setf(a,123),print(a)). This runs, but memory is not being free'd properly.

a) How are you avoiding/finding cycles?
b) Are you doing any sort of compaction?

a) What do you mean by cycles? Infinite loops? Nothing yet, will worry about that once a more complete set of operations is done. For thoughts on that right now, most likely I will monitor depth and limit it based on stack size (GlassOS is limited, Linux here is >8MB).
b) Compaction is planned in terms of combining duplicate nodes. This will most likely be done after string evaluation. There are still more optimizations that can be done, such as merging the globals table into individual nodes (globals table holds object pointer, ref. count, and name as a linked list. Merging would drop 1 pointer.) and specialized nodes (NUM objects have unused car and cdr pointers, cons has unused integer value, etc.).

No, I mean pointer cycles. You're doing garbage collection based on reference counting, but if you have a cycle of references that point to each other, but no longer have an active reference in user-accessible code, the whole cycle should be collected, but won't be in pure reference-counting scenario. This is how Firefox used to leak oodles of memory.

Work has begun again on a tiny BCD floating point number library in C that will be used for floats in lisp. I so far have addition and subtraction, will work on mult. and division soon.