Monday, June 30, 2008

READ and her friends

The recent conversation on the Signature web site about the usefulness of the READ statement started me thinking. There is no question that READ is a weak sister. Her newer siblings EXTRACT and INQUIRE are much better. Not only do they do more, they tell much more about the intentions of the coder. When you see an INQUIRE in a program you know you are dealing with a file that is not going to be changed; an EXTRACT alerts you that this is a file that will be changed.

The suggestion made on the web site in June 2008 was to change the Comet run-time so that READ would act like INQUIRE. After all, if all the coder wants to do is get a record, and did not use an EXTRACT, then why not let the system treat the READ just as it does an INQUIRE. The suggestion was roundly denounced. The consensus was to leave old code alone; "If it aint broke, don't fix it." I could not agree more.

Not the run time, the compiler
My suggestion is less dangerous. Rather than fool with the run time, make the compiler a little friendlier, a little smarter. The compiler should warn the coder that the READ statement is bad news and that INQUIRE or EXTRACT are the preferred statements. This kind of change would affect only new programs and programs that are being updated. And, if all you got was a warning message then you could elect to leave well enough alone when making a minor change to an old working program.

Warning messages
And while we're taling about changing the compiler's warning messages maybe we can eliminate the useless warning about duplicate definitions. No, not the error message that says the same variable is defined with different characteristics. That's a real error. I'm talking about the warning that tells you that CNBR$ is defined three times in the source. When I see that warning message filling up the compile screen I want to yell, "I know, I know, I know it's defined three times in three USEFILES and I don't dare to change them."

Warning you about non-errors that you can't change is not all that helpful. Now what I would like is a list of unreferenced statement labels and unreferenced variables. I like removing unreferenced statement labels so I can better see how the program logic works. And I like removing unreferenced variables for the same reason, BUT please don't tell me about unreferenced variables and statements in USEFILES. Please tell me about unreferenced statements and variables defined in the source program. Now that would be a useful warning message.

How about WRITE?
WRITE suffers from the same limitations as READ. It has been supplanted by it's big brothers INSERT and REWRITE just as READ has been passed by EXTRACT and INQUIRE. Why not smarten up the compiler to gently warn the developer that maybe WRITE is not the best choice.

I'm really hard pressed to find a good case for using a READ in new code but I can see at least one situation where I would use WRITE. I have designed some update programs to be restartable and in those programs I can WRITE and rewrite the new transaction file records repeatedly and do no damage. The transaction record key is unique, so the transaction record will be written once under normal circumstances, but in a restart situation it could be safely written over again. So a compiler warning message would be appropriate. I know that WRITE is not the best command to use, but in this program I know I want to use it.

Signature must be dealing with changing the compiler as they continue to add new, more powerful commands to the Comet environment. The suggestions I'm making here are probably much more difficult to implement than simply adding a new command to the language but if you agree with me and add your comments to this blog, maybe the volume of our voices will encourge them to consider these improvements.