i_am~super

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.

Copper Interpreter Published!

Finally the code-base for the first Copper language interpreter has been published on Github!

The Birth of Copper

I do love languages, and (as I wrote in my very first post on this blog) Copper has its origins in Goldfish, a language initially intended for AI. In a way, making a language was still on the bucket list, so the things I said in that post are not lie, but there is more to the story.

return(benchmark)

Finally, enough of the engine has been reimplemented such that I was able to perform benchmarking again. The results don’t look good.

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.)

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.

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. 😉