End of Support

As of one week, support for Copper has completely ended. Some time ago, I declared an end to the updates some time ago, but now I won’t be updating this blog anymore (unless I hand over the blog to someone else). But before you think that’s a bad thing…

End of Support does not mean “will become defective eventually”. Copper was written for version-agnostic C++, and C++ has remained relatively the same over the course of its life. Additions have been made to C++ as well as some language modifications to its ambiguous points, but none of these things affect Copper thus far.

The Copper virtual machine is still in perfect condition for use and doesn’t contain any bugs as far as I can tell. Being an embedded language, it lacks any IO mechanisms accessible within the language itself. OS hooks (such as file reading/writing) are what separates it from general programming languages. These shouldn’t be too hard to add if such reading and writing is done with strings, but I had originally planned on also loading and exporting Copper variables to file. (See “Things Not Done”)

Why Quit? That’s a long story in itself, and that story will appear on other my other blogs most likely, but the gist of it is: software programming is actually bad for you and me. It’s a real time sink that steals from our real lives in many, many ways. I had fun, but I’m done spending many long, lonely hours at night burning my eyes out, giving myself bad back problems, and typing for 10 solid years (2+ for Copper alone) to create stuff that no one but me planned on using. There’s more to that story, but you’ll have to read my other blogs for that.

Site Stats: There were a total of 12 followers, including myself, but the primary reader was codeinfig who wrote his own programming language, fig. There were 60 posts, 142 views, with 25 views coming the day this language was first mentioned on news.ycombinator.com, April 4, 2017. It’s been a long time since then. The homepage had 62 views, followed by Articles with 7, Introduction with 6, and About with 6. Quite sad. It means no one ever tried it out.

I guess in a world inundated with programming languages, a new one without bling hardly makes a splash. But even with that said…

I’ll never stop thinking of Copper as the greatest embedded programming language… ever.

Last Features

ret_type( fn )

The functions realize() and new() made type-creation more powerful, but as I worked with Copper, I ran into a more serious hole for which I had no appropriate fill: There was no way to check if a variable contained a function-with-a-body or a constant-return-function. (Constant-return functions are often used for single values like strings and numbers (e.g. a=5). You could do the same with a={ret(5)} but then static code analysis would be needed to determine the return type.) Consequently, you needed to call the function on the variable (that is: a()). But if the function wasn’t constant-return, you might be executing a body that contained errors. I needed a function that gave me the constant return type so that I could filter out functions with execution bodies. This function does just that. Granted, to be inclusive (that is, include a={ret(5)} ), static analysis would be required, but that situation is highly unlikely based on programmer laziness habits. (You can’t use share_body() with a=5, but there are already pointers, so use those instead).

Things Not Done (Formerly Planned)

I’ve listed these items as inspiration in case you’re considering creating Copper features yourself.

load_cu( "filename.cu", "global_var_name", var )

Some function like the above would have opened a Copper file named “filename.cu”, run it, and saved the members of the global variable “global_var_name” in the given variable “var”.

save_cu( "filename.cu", "global_var_name", var )

Some function like the above would have saved the members of the variable “var” into the global variable “global_var_name” in the Copper file “filename.cu” by writing it out like Copper. This would make it the inverse of the load() function.

file( "filename", mode )

Create a file handle. The “mode” might be “r”/”read” or “w”/”write” or “a”/”append” or contain members that indicate such as well as “utf8” and format stuff. Copper was originally meant to handle string data as binary, so format info for reading is unnecessary and would instead be handled by string interpreters. Writing, on the other hand, would probably need it unless for some strange reason you wanted to write multiple types of encoding into the same file and make the Copper file functions do the casting (but you could alternatively do that by converting strings and using raw as the file format mode).

Naturally, there would be functions like read(file_handle) and write(file_handle, “string”), which would return the file data as a string or write the file data.

utf8( "string" )

Creates a valid UTF-8 string from the given string. There would be comparable functions for UTF-16LE, UTF-16BE, and UTF32. In the spirit of the language of C, of which Copper has many things in common, there would be functions for operating on such a string, such as:

utf8_length( "string" )
utf8_concat( "string1", "string2" )
utf8_insert( "{0} + {1} = {2}", "Dan", "Emily", "Love" )

And as prototypical for Copper, these would return independent values rather than modifying the arguments.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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