Question

I am currently developing a compiler for a very limited object oriented language. I want to treat all values as objects and operators on those values will be implemented as methods. The compiler transforms the program into assembler for a stack-based virtual machine.

During compilation I transform integer literals into objects of a special “Integer” class. Arithmetic operators are implemented as methods of that class (using inline assembler). So that 4 + 5 basically equals to 4.add(5).

The problem I am facing right now is the special case for boolean values. If there is an if statement:

if(10 > 5 || 12 < 10)

this would currently be transformed into: 10.greaterThan(5).or(12.lessThan(10))

Now obviously those integer literals can also be calls to a function with side-effects. Implementing those binary operators as method calls yields a problem in this case as short-circuit evaluation gets impossible.

So my questions are:

1. How do other languages achieve short-circuit evaluation but still treating every value as an object?

2. According to Wikipedia “ALGOL 68 used “proceduring” to achieve user defined short-circuit operators & procedures.” – How does this work?

Answer 1

The usual technique, I believe, involves either call by name or call by need. The idea is that the parameter of or is not the result of the comparison, instead it is the comparison itself converted in to a thunk, which is converted into the result value whenever (in call by name) or the first time (in call by need) it is needed.

When converting an expression into a thunk, you are basically creating an anonymous function, and you can treat the compilation problem as such. It involves compiling the expression into code that will evaluate the expression. It also involves creating an object (the thunk itself) which refers to (or contains copies of) those local variables that the expression uses, along with a pointer to the compiled code of the expression. The object needs to be interface compatible with your boolean class so that the code using it does not have to care whether it has a genuine boolean or a thunk posing as such. Whenever someone needs the boolean value, the thunk would execute the compiled expression code and provide the resulting value.

If call by name is sufficient to you, that’s all there is to it. For call by need, there’s added complexity from caching the result of the evaluation.