Re: GNAT packages in Linux distributions

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Wed, 12 May 2010 17:37:44 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Any program is partially correct, if otherwise has not been observed. I
> fail to see how Eiffel is different from C or Assembler in that respect.
If Eiffel was the same as C or assembly, why would Meyer have created it  
and why people seeking for safety would be interested in this one ?

OK, the latter assertion is not proof of anything, and I may just be  
talking about people who are wrong.

Go further : look at Eiffel's syntax and semantic associated to each  
syntactic elements and compare that to what's provided with C (by the way,  
there exist formal specifications for C as well, I mean ACSL previously  
presented) or assembly. Can't you see something different ?

There is at least, and this is not subjective, two areas in which it  
differs : expression and runtime-check.

Well, I've noted you do not like runtime-check because it is not [formal]  
proof of anything, but no one said it is formal proof, this is just better  
to catch error the sooner and understand why this was an error. This is  
already the purpose of exceptions, and Eiffel's formalism helps in that  
area... because it comes with a formalization.

About expression now, although understandability of a source does not  
provide proof, this help to at least make partial assertions and discover  
what's wrong. Obviously, static checker does not even need input which are  
human readable : does this means we do not need human-readable as a  
feature ?

A C or assembly designed application is unlikely to raise a run-time  
exception when it detect an erroneous runtime condition. It will just  
raise exception (or signals) when CPU will be in a critical states as  
request for data in an non-existing memory page, as an example. Detecting  
error at runtime in the program state itself, at an higher level, is  
better than this critical kind of CPU level critical state. It is best to  
face an error like “this class invariant was violated” than “this access  
to this memory address failed”. The purpose of Eiffel is to help to catch  
errors at the higher level as possible, thus at a level which is nearer to  
human or proper application functionalities concern. In that way, this is  
a step toward abstraction and formal specification.

This is not, this is a step toward.

Eiffel's not SPARK, there is no doubt about it, and that was previously  
stated, even by Eiffel advocators.


However, to say “C, assembly and Eiffel are all the same and none provided  
better proof an application may at least run partially good” is a lot said  
(it is by the way as much true that jocks and teasing kept apart, C is not  
the same as assembly)

And like Pascal said : “Eiffel is far more easier than SPARK” (you cannot  
request every one to know SPARK, and you help them when you provide them  
something like Eiffel).

Given all that : SPARK is largely known as not being able to handle some  
complex applications, which are yet of every day use (like a web browser).  
If SPARK cannot handle the whole of these applications, what can we do ?  
Eiffel's approach is a suggested one... This does not statically check  
statically, this do it at runtime instead, ... still better than no  
abstraction and formalization at all.

-- 
pragma Asset ? Is that true ? Waaww... great