About Talks Articles

Rexx: one-based indexing and built-in tracing

3 min read

A software engineer’s life is not complete without implementing a programming language. While I did create a lightweight BASIC interpreter targeting embedded systems eighteen years ago, I’m still longing to design and work on my own style of programming language. Looking around various languages which have the goals of being powerful and yet easy to use at the same time, I stumbled upon Rexx (more precisely, IBM’s flavor of NetRexx) and boy, I do like it!

Many things have been said about Rexx advantages. However, if you allow me to pick two excellent features of Rexx which I would consider to steal for my own toy programming language, that will be these…

One-based index

Consider the following Rexx program:

message='Hello world'
say message.word(2)

The result is ‘world’. For “normal” mortals, it is not terribly surprising. The plain English version of the code is basically:

Say the 2nd word from the message ‘Hello world’

In many other languages, even BASIC, the first item in an array is denoted as the 0-th. That makes things complicated for “normal” people without computer or math background. In addition, often the array needs to have strict preallocated items and then it’s easy to go out of bound.

Off-by-one error is very common, I’ve seen many junior programmers fall into the trap. The choice of making the indexing resembles the human language is simply fabulous.

Built-in tracing

Since Rexx’s goal is to be appealing to normal Joe Sixpack, it has ways to simplify debugging. In fact, the traditional concept of debugging, with breakpoints and watches, would be too cumbersome. I am very delightful to see the concept of Rexx: tracing. Yes, this is very similar to my approach to trace the execution of JavaScript code (using automatic instrumentation). Rexx however has this as its built-in feature built in the core run-time.

What does tracing do? It basically simulates the troubleshooting steps of a normal human being if he is about to figure out the problem with his logic. This means doing a step-by-step analysis, following each line of the program and watching the impact of executing the line. Rexx does that faithfully.

trace results
trace var sum
sum = 
loop i=1 to 3
  sum = sum + i
end i
say sum

Running the above program gives:

3 *=* sum = 0
   >v> sum "0"
 4 *=* loop i=1 to 3
   >>> "3"
   >v> i "1"
 5 *=*   sum = sum + i
   >v> sum "1"
 4 *=* loop i=1 to 3
   >v> i "2"
 5 *=*   sum = sum + i
   >v> sum "3"
 4 *=* loop i=1 to 3
   >v> i "3"
 5 *=*   sum = sum + i
   >v> sum "6"
 4 *=* loop i=1 to 3
   >v> i "4"
 6 *=* end i
 7 *=* say sum
   >>> "6"

Even if at first the log looks daunting, after a while most people can appreciate why the step-by-step tracing is helpful. In fact, it’s a matter of matching what the program does (for each step) vs what you think it should do. For those who don’t have computer science background, this is learnable.

Obviously there is other fun stuff baked into Rexx. For example, precision arithmetic, just like in SpeedCrunch, always feels good. Finally, I don’t know how functional Rexx plugin for Eclipse is, but that would be the next thing I’m likely going to find out!

Related posts:

♡ this article? Explore more articles and follow me Twitter.

Share this on Twitter Facebook Google+

comments powered by Disqus