Introduce( []{} )

Functions are about all there is in Copper. This fact is so driven home that, after further consideration, it seems the “fn” is entirely useless. Should it remain?

As it is, functions can be created in four different ways plus an optional way that the interpreter supports:

fn(){}
fn()
fn{}
{}
fn

I decided to replace “fn()” with just simply “[]”. After all, there isn’t any need for the “fn” part when it should be obvious what the variable is storing. Using “[]” would also make code more readable because you wouldn’t be guessing what the parentheses was closing. As it is, parentheses could close either a function header or a function call.
The new syntax would reduce function creation to the following three options:

[]{}
[]
{}

I think this may also lead to fewer mistakes, and it’s easier to type. Here’s what it might look like in practice:

Set_button_callback( [pressed count=int(0)]{
	int_incr(this.count:)
})

The biggest challenge was overhauling the virtual machine to handle this. Forturnately, it didn’t proved difficult. It would have been more difficult to go from not having “fn” to having it.
A number of languages have this syntax, so it’s nothing new. Given that lists are created using an extension with a function call “list()”, making this change would not interfere with list functionality as it would for other languages.
Given that I’m using a repository, I created a new branch to save the old syntax. I usually hate to make breaking changes, but this one definitely seems to be for the better. The main bummers will be having to change all the blog posts I’ve written that use the old syntax, especially the stuff I haven’t posted yet which is already becoming outdated.
I believe I deliberated on this decision some time ago, but that was when I was still working out the details for the language syntax. As it is, it makes perfect sense.
One thing it will help do is to reduce the mistake I keep making in defining functions how every other language does it. It’s a habit that I get from programming in C++ so much.

myFunc(a) {
	print(a:)
}

The above code is actually a function call and an execution body that never gets executed. The function has to be defined first via:

myFunc = fn(a){
	print(a:)
}

Changing the syntax would make it:

myFunc = [a]{
	print(a:)
}

… whereby it would immediately be recognizable if I made the mistake of appending it to the end of the name:

myFunc[a] {
	print(a:)
}

This is still valid code: it creates a variable and a function with a single parameter that isn’t assigned to anything, but in this case, it looks nothing like valid syntax in any other languages I use, so I’m less likely to assume everything is fine. Matlab people may have a problem with it, but this language isn’t designed for them, otherwise I might be using silly operators like “:=” for assignment, among other things.

One of the benefits I’m already seeing is how I myself perceive the syntax. Having “fn” out front always made me think of these function-objects as functions first, then objects. The reality is, the syntax is such that the parameters section is just as important and useful as the body itself. For example, here is a comparison of the old way I was planning to make classes as opposed to the new way:

A = {
	this.toString = { print("class A") }
}
A()

New way:

A = [
	toString = { print("class A") }
]

The former allows for resetting the definition of “toString” back to its original form if it gets erased, but it requires that I call the function in order to create the members. The latter, on the other hand, requires no call, though it doesn’t have a body that allows it to be reset.
Thinking of it this way, it means that it would be very easy to make records using Copper and have all the benefits of a regular programming language.
Of course, I’m sure there are other languages used as such. It seems like languages are usually tailored towards either processing tasks or towards markdown and the overlap is, as in the case of Copper, accidental or cobbled together to add the desired extra functionality.

• Uncategorized