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.

Advertisements

Copper Interpreter Published!

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

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.

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.

FFI = cu.translate(other)

Interpreted languages would be useless without extensions or some foreign function interface. Unfortunately, this is a very, very annoying position to be in because we’re effectively going back and forth between “trusted code” and “not-trusted code”. This gives rise to a number of potential problems to solve, and coming up with solutions for them for Copper wasn’t easy because the solutions are custom fits for a language and engine that have never before existed.

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