Progress Report #2

A number of things have happened to shape the Copper Virtual Machine. As I’ve already spoken of some things before, I can readdress some of those things.

As you may know, the core of the virtual machine is “done” with a little “d”. Here and there, new functionality may be added, but the language syntax is reaching a static state. Here are some of the changes.

  • The syntax has one change: adding the immediate-run token, using the colon, as explained in the article about functions prior to this.
  • Stack trace printing.
  • Added functionality for accessing core features directly.
  • Miscellaneous fixes.
  • writeToInt(), writeToFloat(), and writeToDouble() have been removed. I provide an explanation below.

Stack trace printing would seem to make little sense in a language with no function names, but it can be done by assigning an ID to every function created. The bummer here is that a function can be created multiple times with the same line of code and be given a new function ID each time, making it very difficult to track down. On the bright side, incorporating this tracking feature into an IDE could help trace back to the offending function because trying to do this by hand can be quite tedious. Naturally, I’m considering other approaches to aid in debugging, though these are likely to be tailored to those using Copper for scripting, not huge projects (for which Copper is not designed).

In an effort to make Copper objects be more usable in their basic state (without having to write all kinds of mini functions to do things), I added a few key functions to the list of built-in ones. The first is “type”. All variables in Copper are functions, but since different types of objects show up everywhere, I’ve wanted this function for a long time and hadn’t decided how I was going to implement it. It did require adding an extra function to Object class inheritors, but I’m sure programmers would be glad of that anyways. Another function I added is “set_member()” which allows setting a member of a variable by its name. This allows the user to use variables like hash tables and Python dictionaries. It is complemented by the function “member()”, which, as you can expect, gets a pointer to a member whose name is passed to the function. There will be more details about usage in the actual documentation.

A number of one-liners were fixed, some before they became problems. I like catching bugs before they hit me. It saves alot of time debugging. One of the bugs was hidden by how well the memory management works in Copper such that it would have only affected programmers trying to write IDE hooks into the engine. I have to shout out a thank you to the poor random nameless Joe whose article reminded me to order my reference counting calls correctly. I do owe thank yous to a number of people online, especially people on StackOverflow who post links. Sadly, it’s hard to remember usernames like iamapro90213b.

Outside of the engine, I’m working on other extensions. The numeric extensions changed dramatically. I felt that adding writeToInt() and related functions were tailored too much towards the special extension. Instead, I unified the extensions via a fast interface in a class outside of the core virtual machine components. This action has been for the better and resulted in improved code. However, more work is to be done, especially considering that I have not handled larger primitive data types (and I’d like to).

I am currently working on a lists extension, but there are so many details to that that it merits a new article.

Naming Conventions

Naming conventions in Copper have gradually evolved as I’ve written sample programs to figure out both what things look like and how they would look best as complexity increases. Currently, I’m using capital letters and underscores for any function from extensions, but programmers creating extensions and Copper users may use whatever they wish. I tried thinking of a good pattern for how to go about naming things, but because there is no distinguishing between functions and classes in Copper, it made the task difficult. Based on the paradigms I keep using, it tends to make more sense to name functions treated as long-lasting containers with a capital letter and functions that don’t with a little letter. What I don’t want is for people with a background in Ruby to think the nomenclature indicates something special about the object. There isn’t. In fact, it makes sense to have hybrids.

Using the current numeric extensions, I can easily write a Fibonacci sequence generator, which sort of takes the form of being a hybrid class and function:
Fibonnacci = fn(a b) {
ret(fn(a=a() b=b()) {
c = sum(a: b:)
a = b:
b = c:

a = Fibonacci(1 1)

Mind you, it is possible to do this in C++ using a class that overrides the operator().

Another consideration for nomenclature is with the functions that handle multiple parameters. There are functions in Copper that only accept one function, notably those beginning with the word “is”. However, I had a number of other functions such as “is_bool”, “is_string” that could accept more than one argument. The function name “is_same” (used for pointers) deceived me a couple of times such that I forgot to add my other parameter. Given that I think it would be more helpful, “is_” has been changed to “are_” for these functions. Grammatically, it looks bizarre, especially if you only pass one parameter, but that’s English for you.

I hope I’m not doing things in a way that makes it more difficult or confusing for other people to use Copper. Optimizing for oneself does not mean you are optimizing for someone else or anyone else for that matter. I am open to suggestions for language improvements and changes, though admittedly, I’ve hardly published the actual details.

4 thoughts on “Progress Report #2

  1. i love that variables are functions. i dont even know exactly what you mean yet, but i like your use of colon and and in python everything (a variable for example) is an object, so if everything (or at least most things) in copper are functions– hey, thats neat 🙂


    1. 😀 I had made functions objects when I tried implementing a language before and I realized that functions do effectively the same as a regular variable: return a value. The only difference was their syntax. I decide to eliminate this difference, and thus the idea for Copper emerged. I discovered the minimum necessities for a higher level language and presented them in my second blog post, syntax=require(min). The benefit of removing the distinction is that Copper becomes a statically typed language, despite having multiple object types. This eliminates the need for a declaration of type for variables without resulting in ambiguous code. Stay tuned – after the next post, I plan posting an article about how the system works on the C++ side.

      Liked by 1 person

      1. “functions do effectively the same as a regular variable: return a value. The only difference was their syntax. I decide to eliminate this difference, and thus the idea for Copper emerged.”

        love it!

        p = 7
        print p

        def p(): return 7
        print p()


      2. Something like that. Copper uses brackets for function bodies, but nothing says all the concepts here couldn’t be used in a spin-off language with a syntax like fig. In fact, based on the design of my VM, it’s possible to reuse the memory management, variables, and data containers for a new language that doesn’t need brackets.

        Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s