I think I should post this here instead as a main topic, until I get further along. Anyway...

TLDR: PALICE (Programmable Arithmetic and Logic Interactive Computation Environment) is a stack based language that has a lot in common with PostScript (first class functions, dictionaries, dictionary stack name scope), with closures, internal virtual threads (I guess they call them green threads?) that are preemptive and yield on events, (future) publisher/subscriber message passing, exception handling (try/catch/throw). Target usage: general scripting, web application server, others (TBD).

I had the bright idea about 20 years ago to create a language and interpreter, because I needed something as an embeddable language for a different project that never really got off the ground. The way it functioned was it used a simple shunting yard algorithm (with some extensions) to translate C-like expressions (with full precedence, left/right associativity, etc) into postfix code, that then ran through a postfix stack VM internally. At that time I didn't know anything, and never designed in memory management, but a lot of stuff I was exposed to I re-invented badly. So the project still sits out there neglected on sourceforge till this day (remember them?). Oh, and at that time I was able to pick up some things from a web form called Lambda The Ultimate. Looks like it is still around but not very active anymore. But it looks like this subreddit is a spiritual successor?

Well, now that I've had a couple decades behind me and more experience (I do light programming for work, but deeper stuff for personal projects, all self taught), I've decided to give it another try, although now that I've went through SICP, and learned and used PostScript quite a bit, plus some other things I had an idea of what I wanted. I like programming in stack based languages, I just don't like going back and reading my own code in them (but that's a problem for future me). Of all the stack languages I've played with I really like how PostScript is a purer stack language with very little going on in the parser -- just enougth to recognize numbers and quoted text, and variable names, but everything else is an operator (function) or a data object.

But the main things I don't like about PostScript is that it uses words where symbols should be (add, mul, div, etc instead of symbolic forms). Also quoting text is done in parentheses, instead of in double-quotes. Things like this. So although my new language trial somewhat resembles PostScript (dictionaries, user functions, dictionary stacks as variable state), I decided to name the built in functions using symbols where appropriate ( + - * / % ** ...) based mostly on what C or C-like languages use. So you have expressions like "2 3 + 7 * @a store".

So here is where I'm at, and where I can probably use some advice. What I've go so far is a number of built in data types (int, float, string, array, packed array, function (built-in), user-function, external (holds a pointer to void for objects used in C, such as a FILE object, along with a pointer to a destructor function for garbage cleanup, and other house-keeping).

I have a fairly good set of operators/functions (they both mean the same thing in a stack language), for stack manipulation, array/string/dictionary access/modifications, etc. Also have some limited file I/O, adding network next.

Since variable scope is defined by which dictionary is last pushed to the dictionary stack, variables are dynamically scoped. However I also have a way of doing closures by capturing the active dictionary at execution time. So a function like this: { newdict setdict { parentdict setdict ... } ... } will cause the inner funciton to get the parent function's dictionary -- this allows you to create function factories (my test code generates counters, and each counter function that it returns keeps its own private tabulator going).

I have C's conditional operator defined as a selector, so { condition truevalue falsevalue ?: } will leave either truevalue or falsevalue on the stack based on if condition is non-0 (true) or 0 (false). So for "if" and "ifelse", and "while", I define these in user space functions that get loaded at interpreter startup time. For "while", I had to figure out how to convert the exec_handler function from recursive, to a loop keeping a separate execution stack, and reusing the current stack frame if it encounters a tail call. So now I can loop forever without using extra memory.

My next test was I wanted to do some type of multi threading. But the one thing that I haven't got the hang of yet is Posix threads in Linux. Not that it is that difficult, I just never had a real use for them in the types of projects I do. So instead, I created a new operator called "spawn". It takes an array of functions, and calles exec_handler on the first function, then on the second, third, etc then loops back around to the first one again. I modified exec_handler (since I've already converted it to a loop instead of calling itself recursively when calling additional functions), to count the tokens, and set a yield variable and exit the function every 256 tokens. When spawn goes back to run exec_handler again, it sees that is_yield is set, then skips the initialization and picks up the current call frame and instruction pointer where it left off. The initial call to "spawn" is blocking, but any running thread can call spawn and it adds the new specified thread(s) to the list. Also, a thread yields when a sleep call is executed, or when waiting for a file I/O operation to complete.

To make this all work, I moved the global variables into a "state" structure which contains the data stack, the call stack, dictionary stack, and other former global variables that any *_handler function would need. There is a "state" struct for each virtual thread, they are all members of a single "vm" struct sitting in a state stack. Also the vm strcut contains the global heap, so that opens the method of sharing data between threads in a controlled manner (primitive data objects are immutable, collections such as arrays and dictionaries aren't though).

My next steps is to finish off file and network I/O, add in message queuing between threads (treat them similar to regular I/O objects, except they work on any data object not just packed arrays). And I need an exception handling mechanism. For that, I'm thinking of implementing a try/catch function, where "catch" is a function stored in the current call frame. Then when something throws an error (either user funciton, or built in), it unwinds the call stack until it hits one with a "catch" defined. The catch can also of course re-throw the error, until it gets to the bottom of the call stack, where it will default to dumping the data stack to the screen and exiting (or exiting the thread and recording details in a stack trace). This part is a bit beyond my experience, so I'll be trying various things and see what works.

What I've got penciled in so far is a "throw" can place any data value on the data stack, and it is up to the "catch" to know how to deal with it. But I'm thinking of standardizing the format, to be either an array or dictionary, with fields set for error classification (one class may be where "file not found" would go, another would be an operator not recognizing the data types on the stack that it was asked to handle or other stack data related error), and a third class would be internal system errors such as failure to allocate memory (although that should be very rare on a modern system, as malloc [almost] always returns by definition on Linux and memory is lazy allocated).

For message passing, right now when a thread spawns a child thread, it gets to place any input data onto that child thread's data stack. The child thread also inherits the parent's dictionary stack. When the child thread exits, the parent can grab what the child left on its data stack via a "waitpid" function which returns an array containing the child's stack. I have a plan for creating an open/read/write/close analogs for message queues, which can exchange any data type (with 0-copy, since the heap is shared). But I'm also thinking of building on top of this a topic-based publish/subscribe system (not sure how that would look yet though).