Lambda the Ultimate

No?

Being an old avionics man I can comment on this. In Air Force jargon AFCS stands for automatic flight control system. AFCS’s originate long before digital computers as electronic analog computers and even electro-mechanical computers. AFCS’s include autopilots, bomb navigation systems like the famous Norton bombsight. Lead collision aiming and firing systems developed in the 1950’s to attack bombers and many others. In the 1960 these systems were gradually digitized.

The paper referenced here: Design Patterns for Avionics Control Systems, written in 1994, seems to be a modern OOP programming strategy for these systems. The architecture depicted can be seen as a virtual machine very similar to the older electronic analog and mechanical machines. All that seems to change is the computers and the software. And in an age of register machines let us not forget the compilers.

But don’t think that this is some sort of video game or simulation. There is a lot going on here besides computer programming! This is a computer program in a real environment. The program must “work” up to some standard in this real, dynamic, and uncertain environment. The strategy used is the very classic feedback control strategy. More generally known as goal orientation.

An example might be to fire some weapon and detonate it slightly above and in front of the target. We must do this in spite of evasive maneuvers, wind disturbances, countermeasures, darkness, weather, etc. In short the world is not cooperating with us in our goal of destroying the target! No particular plan can work for long. We must adapt and change. The system does this by continuously senescing differences between what it needs and what is actually happening and computes a corrective action. Did the action work or not work in correcting the problem? If the action didn’t work; why didn’t it work? What can it do now to reach the goal? Notice that there is a works or doesn’t work logic (ie synthetic) as opposed to a true or false logic (ie analytic).

Problems of synthetic logic typically require a virtual machine to redefine the logic on the register machine (thus the DSL interpretation). Notice that this would not be necessary if the system were analog. There is nothing strange about synthetic logic.

It turns out that this is a favorite problem of ours. There is a language called Lewis that we think and hope is a consistent synthetic logic coupled with an analytic logic (ie a general solution for problems such as the one above).

A few more comments that might make Lewis more understandable: Lewis has evolved slowly over a period of 10 to 20 years depending on how you look at it. If you look closely you can find an old fashioned Lisp. An If-clause can consist of nested functions a mile long. On top of this there is a backward chaining rule system with two types of rules, FORMAL and EVENT. EVENT rules are synthetic. They define action not a state change and when they work they update facts called modal facts (ie the state change or situation change occurs only if the action “works”), if the action doesn’t work the system backtracks, thus there is an opportunity to deal with or correct any failure that might occur. This is not something I created out of thin air, it actually has a name and a long academic history. It’s called pragmatism. An event rule is closely related to the “sign” concept.

Formal rules are very similar to prolog rules. They never change anything except in the sense of a side-effects, but they can add facts to the data base.

Hank Thediek
ps can't figure out how to put a link in these pages. You can read about Lewis at http://home.sprynet.com/~hthedick/homepage.htm