LETTERS

Harold T. Salive

Auckland, New Zealand

Doug responds: Thanks, Harold, for pointing out the correct codes for 28 and 30. The value for 62 is a space in my reference. Obviously, I should have referred to the original standard. In any event, I'll obtain the text of the standard ASAP and post a corrected version of the code.

As to my treatment of the STOP character, while I understand your concern, my goal was to generalize the creation of individual characters as much as possible. Placing the final bar of a STOP character outside the normal character routine seemed (and seems) reasonable to me.

The STOP character is the single character that extends beyond 11 units. Perhaps it would have been clearer to encapsulate all of the stop code printing within printCode128Term(). Thanks again for your thoughtful reading of the code.

Mind and Life

Dear DDJ,

Regarding Michael Swaine's, "Mind and Life as Mechanism" (DDJ, October 1994), mechanical models of life have always been repugnant to many. However, throughout history new knowledge about living creatures has only served to strengthen the hand of those who tout such models. Knowledge now culminates in the discovery that DNA governs the physical development of living creatures from birth. The ongoing genome-mapping project is writing a new chapter.

The brain/mind seems to be the final frontier in the search for a mechanical basis for life. I, for one, am ready to accept it. I've come to think of life simply as a fifth state of matter--after solid, liquid, gas, and plasma--to put it in prosaic terms. It seems that living creatures need not be considered anything more than complex, highly organized systems of molecules. How that organization continually fine tunes itself in an evolutionary sense is a central question. I cannot believe it is due strictly to random mutations triggered by cosmic rays as some say. Behavioral aspects affect and reflect neural interconnection patterns. Perhaps information of changes in those patterns tends to feed back into the genes somehow.

The earliest reference of the brain as mechanism in my library is Design For a Brain, by W. Ross Ashby (John Wiley & Sons, 1952), which predates our modern computers and is centered around a special-purpose computer called a "homeostat." It's an interesting book filled with diagrams and equations, not just text. Chapter 8's title is, "The Animal as Machine." Compare that with "Mind and Life as Mechanism."

"Roger Penrose," Michael states, "has presented an approach that rests ultimately on quantum uncertainty." I presume that refers to the Heisenberg uncertainty principle from quantum physics. If so, here's a late flash: Along comes Sallhofer (Z.Naturforsch, Hans Sallhofer, Maxwell-Dirac-Isomorphism, 1986) in Austria to proclaim, with some authority, that the probabilistic interpretation of quantum theory is a mistake. That it is due simply to a "lack of clarity" in the theory which is not present in the Dirac formulation. So that catchall phrase, "quantum uncertainty," may be on its way out.

Homer B. Tilton

Tucson, Arizona

Programming-Language Syntax

Dear DDJ,

Many years ago, Niklaus Wirth proposed a notation for defining the syntax of programming languages called, "extended Backus-Naur Form," or EBNF. Although its earliest publication seems to have been in a very short article in the Communications of the ACM in 1977, it is still alive and well. Recent ANSI/IEEE and ISO/IEC standards have made use of it.

So why am I writing this letter? Partly because EBNF is a good thing in and of itself: It is clear, unambiguous, readable, easy to learn, machine processable, and is not dependent on multiple fonts. I'm also writing this because I'd like to see a standard combining the various dialects of EBNF that have cropped up over the years. In fact, I'm probably willing to write the first draft of the standard. (I also hope to make some money by coming up with my own EBNF-based products.)

Are you or any DDJ readers aware of any ongoing work on standardizing EBNF? Perhaps an ANSI, IEEE, IEC, or ISO committee? If nothing is ongoing, then I might be interested in creating an informal committee for this. Would you be interested in being involved in the committee? Or would you just like me to keep you posted?

The first thing I would like to add to EBNF is a way of indicating comments. Before I invent something, is there any existing technique for this?

Anyone who is interested, or aware of any other EBNF-based software, is invited to send me e-mail or regular mail.

John Rogers

11604 104th Ave. NE

Kirkland, Washington 98034-6606

CompuServe 72634,2402

DDJ responds: This sounds like a worthwhile project, John, and hopefully, other readers will work with you on it. Keep us posted on your progress and let us know how we can help out.

Hause's Method

Dear DDJ,

I read your magazine for the first time in July. This is the best programming magazine I ever picked up: intelligent, unpretentious, and aware of the context of software engineering in the world outside. Jack Woehr's interview with Lotfi Zadeh was a pleasure to read and reread.

Now talking of fuzzy logic, what was Mr. Williams D. Hause's letter (DDJ, July 1994) trying to prove. I just bought a copy of Schneier's wonderfully plaintext Applied Cryptography. Mr. Hause was talking about a one-time pad! My sister and I used to send messages to each other like this. Mathematically unbreakable, except that our mother would tidy up our messages and one-time pads from inside the sofa to the kitchen bin.

I couldn't believe that Mr. Hause's nonsensical letter wasn't a joke. Here is my proof:

Theorem: Any notion N, when obscured by ridiculous pseudoformal reasoning R, produces a ridiculous nonsense. Proof:

Let K be a ridiculous, pseudoformal reasoning of X number of lines.

Let P be the plain notion encrypted in Hause's letter, of length X.

Let C be the confusion produced by K obx P. (obx is the Hause "obscure pseudoformal reasoning" operator.)

From the theorem I am trying to prove, we know that C is ridiculous nonsense and is therefore unbelievable.

Corollary: Using Hause's method I have discovered a truly remarkable four-line proof of the four-color map theorem, but my margin of credibility is too small to contain it.

Sandy Anderson

London, England

Another Approach to Callbacks

Dear DDJ,

I read with interest the article, "Associations in C++" by Dan Ford (DDJ, August 1994) because a team member of mine wrote an almost identical class with a slightly different twist. Instead of indirectly calling a method through a function, we simply called the method directly. To do this, the user of the callback registers calls not only the object pointer, but also the pointer to the method he wishes to have called. The method is then called in the standard way of calling methods through pointers: (objectPointer->*methodPointer)(param1, _;.

In this way, objects can directly register their own methods to be called on specific events. Of course, the obvious constraint on this is that the object and method pointers that are used are all derived from a common class. This is because the callback manager object must be able to hold the pointers in a variable of the appropriate type. In other words, you could not store the object and method pointers as void pointers and expect it to work (too bad, I say!). However, it is my opinion that this constraint is not a factor when properly designing application-domain frameworks. Of course, if you use Smalltalk, all of these problems that arise from using such a hybrid language become NULL and void!

Kevin W. Beam

Omaha, Nebraska

Table 1: Bar codes.

Code          Routine         AIM
              Errval          Value
28             {              <
30             }              >
62                            ^