Tag: interpreted programming language


This feature was implemented a long time ago and is available on every branch of Copper

Creating classes is an interesting paradigm (should be spelled “paradym”, but nobody asked me). Many languages implement such a feature (C++, Ruby, PHP, etc.), some languages make the feature so terse it’s hard to recognize without reading docs, some languages don’t even bother with it, but you can still implement it with some work. There have been a number of arguments about whether closures and classes are essentially the same thing with different names, but I’m on the side that thinks otherwise. It’s a matter of construction, and certainly closures are far easier to create in some languages than in others. I won’t go into a discussion of class versus closure, but I will admit that the line is certainly very blurry, and Copper adds another dimension to it.

Continue reading “i_am~super”

Type System Revise

I did some speed profiling… – something I probably should have done a before outright stating my virtual machine is “not improvable” on its blog. Of course, I know better, and that’s why I performed speed profiling.
The profiling narrowed down the bulk of the speed bottleneck to function calls (actually, it was a confirmed educated guess, but I think I know where the other bottlenecks are).
Not to the surprise of any expert, the primary issue turned out to be string comparison. Strings add up to be amazingly expensive. Currently, there are too many function calls that depend on them in the script execution section of the engine.
Continue reading “Type System Revise”

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”