Progress Report #5

State Restored!

That about describes everything about Copper right now, for the most part. The Copper interpreter was originally a state machine and the new version isn’t any different in that regard. But the “state restored” in this case primarily refers to the fact that everything I had in the original version of the interpreter has been restored in the new version including all the built-in functions. That means I’m back to where I was about 5 weeks ago, but this time, I have what I believe to be a MUCH faster interpreter, though I have yet to benchmark it. (Ok, so the ability to run Copper functions outside of Copper has not been finished and I’ll talk about that.)

Continue reading “Progress Report #5”


Progress Report #4

Transition complete. There are now 3 branches: fn, Bobcat, and master (also known as “Cheetah”). I’m hoping that the new code-base in Cheetah will prove to be much faster than the original design. All things considered, I knew I had designed a slow system. It was effective and relatively easy to maintain, and the new system is likely to be slightly more challenging. :/ However, I maxed out what I was going to get out of the old design. The processing code was very bulky with tons of methods dedicated to it. I spoke about its task system in a previous post, which should have been published a long time ago, but now is as good a time as ever to compare it with the new system. The new system (the new engine, that is) has a separate parsing and execution system, reducing the primary execution sector (the methods doing the repetitive operations) to only a handful of methods.

Continue reading “Progress Report #4”

The Task Processing Model – Branch Bobcat

ATTENTION: This applies to the first two branches of Copper, known as “fn” (original, using “fn” for function start syntax) and “Bobcat” (the version to begin using the square bracket syntax). The task-processing system has been replaced in the new master branch known as “Cheetah”.

Copper is a very simple language. Unsurprisingly, the language requires a number of little quirks on the backside that make the model I’ve chosen for processing tokens to look like gold in hindsight. … Maybe I’ve just done this before and learned from experience. 😉

Continue reading “The Task Processing Model – Branch Bobcat”

Progress Report #3

Sometimes the easiest way to see if something will work is to start coding it, writing down ideas as you go. The adage is 100 hours of programming will save you 10 hours of planning. That can be very true, but sometimes it isn’t possible to figure out if an idea will work until you try putting it together in code. You’re going to need to write some pseudo code, and you may get to the point where you’re just writing code.

Continue reading “Progress Report #3”

benchmarking the branches

Before going too far, I wanted to test the speed differences in the two branches to see how much of a different “fn” makes in speed and if it even merits consideration. For this, I would need a lengthy test, but to ensure that the data is reasonably comparable, I needed code that was about the same in time for both branches. Hence, I created a looping test that merely iterates an integer and outputs the speed. The times for both branches should be different by no more than a small amount. If that amount happens to be equal to or greater than the difference in times for a test comparing the usage of “fn” to not, then either the test isn’t time-consuming enough, or the time cost for function construction doesn’t outweigh the cost elsewhere, or – a stretch – there really is no difference because the clock() stinks, at least on my PC. The clock() can be shown as reliable by getting consistent clock times, so any times that are greater than the clock-time variance are significant times. That makes only the first or second options viable.

Continue reading “benchmarking the branches”