Python from Wise Guy's Viewpoint

[Kenny Tilton]

Fergus Henderson wrote:

> Kenny Tilton <ktilton at nyc.rr.com> writes:
> 
> 
>>Dennis Lee Bieber wrote:
>>
>>
>>>        Just check the archives for comp.lang.ada and Ariane-5.
>>>
>>>        Short version: The software performed correctly, to specification 
>>>(including the failure mode) -- ON THE ARIANE 4 FOR WHICH IT WAS 
>>>DESIGNED.
>>
>>Nonsense.
> 
> 
> No, that is exactly right.  Like the man said, read the archives for
> comp.lang.ada.

Yep, I was wrong. They /did/ handle the overflow by leaving the 
operation unguarded, trusting it to eventually bring down the system, 
their design goal. Apologies to Dennis.

> 
> 
>>From: http://www.sp.ph.ic.ac.uk/Cluster/report.html
>>
>>"The internal SRI software exception was caused during execution of a 
>>data conversion from 64-bit floating point to 16-bit signed integer 
>>value. The floating point number which was converted had a value greater 
>>than what could be represented by a 16-bit signed integer. This resulted 
>>in an Operand Error. The data conversion instructions (in Ada code) were 
>>not protected from causing an Operand Error, although other conversions 
>>of comparable variables in the same place in the code were protected. 
>>The error occurred in a part of the software that only performs 
>>alignment of the strap-down inertial platform. This software module 
>>computes meaningful results only before lift-off. As soon as the 
>>launcher lifts off, this function serves no purpose."
> 
> 
> That's all true, but it is only part of the story, and selectively quoting
> just that part is misleading in this context.

I quoted the entire paragraph and it seemed conclusive, so I did not 
read the rest of the report. ie, I was not being selective, I just 
assumed no one would consider crashing to be a form of error-handling. 
My mistake, they did.

Well, the original question was, "Would Lisp have helped?". Let's see. 
They dutifully went looking for overflowable conversions and decided 
what to do with each, deciding in this case to do something appropriate 
for the A4 which was inappropriately allowed by management to go into 
the A5 unexamined.

In Lisp, well, there are two cases. Did they have to dump a number into 
a 16-bit hardware channel? There was some reason for the conversion. If 
not, no Operand Error arises. It is an open question whether they decide 
to check anyway for large values and abort if found, but this one arose 
only during a sweep of all such conversions, so probably not.

But suppose they did have to dance to the 16-bit tune of some hardware 
blackbox. they would go thru the same reasoning and decide to shut down 
the system. No advantage to Lisp. But they'd have to do some work to 
bring the system down, because there would be no overflow. So:

(define-condition e-hardware-broken (e-pre-ignition e-fatal)
   ((component-id :initarg :component-id :reader component-id)
    (bad-value :initarg :bad-value :intiform nil :reader bad-value)
    ...etc etc...

And then they would have to kick it off, and the exception handler of 
the controlling logic would get a look at the condition on the way out. 
Of course, it also sees operand errors, so one can only hope that at 
some point during testing they for some reason had /some/ condition of 
type e-pre-ignition get trapped by the in-flight supervisor, at which 
point someone would have said either throw it away or why is that module 
still running?

Or, if they were as meticulous with their handlers as they were with 
numeric conversions, they would have during the inventory of explicit 
conditions to handle gotten to the pre-ignition module conditions and 
decided, "what does that software (which should not even be running) 
know about the hardware that the rest of the system does not know?".

The case is not so strong now, but the odds are still better with Lisp.

kenny


-- 
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
  http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey