@reiver

Programming Language Design Ideas: Equation Pointers

Back when I was still in University, I had a strong interest in programming language design.

An interest like this eventually leads you to do things like buying and reading the (famous) "Dragon Book". (Also known as "Compilers: Principles, Techniques, and Tools".) Although in reality, I have 6 book on my bookshelf on the general topic of compilers, interpreters, etc. After all, if you are going to design a new programming language the only "good" way to reify it is to make a compiler or interpreter.

I think this strong interest in programming language design came out of it being the period where I was first being exposed to programming languages and was still learning how to program.

Keep in mind that this is about 20 years ago! (And I think more than 20 years ago, for the particular thing I am going to describe.)

But it being that period of first exposure, it caused me to have a number of ideas for programming languages.

About a year or two ago, I was talking about my former strong interest (in programming language design) with a friend. It brought back some of those ideas I had decades ago.

Pointers

Although I had taught myself the QBASIC programming language prior to all this, I think the first time I got exposed to pointers was when I was learning the Turbo Pascal programming language (in College).

The bit about pointers that was relevant to what I am talking about here is how they compared to normal variables.

If you assign a normal variable to another variable, and then change the original variable, the other variable doesn't change.

That's a lot easier to understand with actual code. So, let's see that with an example.

Note, since it has been a long long time since I've coded in Turbo Pascal and I don't really remember the syntax, I'll show an example in Golang instead.


a := 1
b := a

a = 2

fmt.Printf("a = %d\n", a)
fmt.Printf("b = %d\n", b)

// Output:
// a = 2
// b = 1

Note that the b variable did NOT become 2 when we assigned the value 2 to the variable a. There is no lasting link between the variables a and b.

But when we use pointers, things work differently!

For example.


a := 1
b := &a

a = 2

fmt.Printf("a = %d\n", a)
fmt.Printf("b = %d\n", *b)

// Output:
// a = 2
// b = 2

This time when we assigned a value of 2 to the a variable, the b variable also got the value of 2. With pointers, there is a lasting link between the variables b and a.

That's the essence of what many people will want to do with pointers.

Expression Pointers

Back then I thought to myself that I'd really like it if I could do this with expressions too.

In fact, I'm pretty sure I asked the instructor teaching Turbo Pascal if there was a way to do this with expressions too. Although I think I said the word "equations" rather than "expressions".

What I wanted was a way to have (in pseudo-code) an equation like this.


a := 1
b := 2

c := a + b

And then make it so there is a way to say that, if the variable a or b have their values changed then the value of the variable c is also automagically changed too.

So maybe we would want a special syntax for that to differentiate between a normal equation and a pointer equation. So maybe somthing like this.


a := 1
b := 2

c := a + b

(I'm not trying to suggest this is the best syntax for this. I just need to use something for my examples.)

Of course, this could be for a much more complex expressions.


a := 1
b := 2

d := 2「*」a 「+」 a「*」「sin」(b)「/」b

In other words, what I wanted is that there would be a lasting link between the variable c with both the variables a and b.

So, something like this.


a := 1
b := 2

c := a + b

fmt.Printf("a = %d\n", a)
fmt.Printf("b = %d\n", b)
fmt.Printf("c = %d\n", c)

// Output:
// a = 1
// b = 2
// c = 3

a = 5

fmt.Printf("a = %d\n", a)
fmt.Printf("b = %d\n", b)
fmt.Printf("c = %d\n", c)

// Output:
// a = 5
// b = 2
// c = 7

This is what, back then, I thought of as "equation pointers". Although "expression" rather than "equation" maybe be more appropriate; so "expression pointers". Although, you could extend this to "statements" too; so also "statement pointers".

Having a deep understanding of how computer work I know that these aren't really "pointers". But from that more naive perspective I had a couple decades ago, it was how I thought of it.

Syntactic Sugar

Of course, there are ways to could get this kind of effect.

But this is really about syntactic sugar.

It is about having an easy way to express this idea in a programming language. Which can also result in an easy way for others to read and grok its usage when done in a particular programming language.

--