Re: Ada and Java. different behaviour. casting long to int problem.

["Vladimir Olensky" <vladimir_olensky@yahoo.com>]

Sera Hirasuna wrote in message <7kg9is$85g@dfw-ixnews8.ix.netcom.com>...
>This is Richard Riehle appropriating time on his wife's email account.
>
>
>In article <t7so7rdd1u.fsf@calumny.jyacc.com>,
> Hyman Rosen <hymie@prolifics.com> wrote:

>
>This example serves us well in this kind of discusson because
>it illustrates a key difference between Ada and most other
>languages:  the language design criteria.
>
>The design criteria for Ada are critically different from those
>of the C family of languages (C, C++, Java, etc.)  One of the
>most important of those criteria is that each Ada statement
>should default to "safe."  That is, "safe" is the normal mode
>for an Ada program construct.   The default mode for C is "unsafe."
>C++ and Java inherit many of the unsafe features of C, particularly
>at the algorithmic level.
>
>It is easy to include in a language for which the default is "safe,"
>features that relax those safety constraints.  It is more
>difficult to start with an unsafe language and make it more safe.
>
>Ada permits a designer to bypass the safety default using such features
>as unchecked operations and interfaces to unsafe languages.  The
>ability to bypass the default is sometimes necessary.  Sadly, some Ada
>programmers use it too often.  As long as one is designing with standard
>Ada constructs, the safety is in place and an huge number of errors
>are detected by the compiler.


I would like to add some things to the all  said above.

I think that Ada 95 design could go a little bit further and would seriously
consider  experience of M3.
M3 designers at their time had seriously considered experience of Ada 83
regarding safety and made one extremely good design decision (to my point of
view - others may have different opinions of course).
They divided all language features to safe and unsafe ones (just the same as
in Ada ).
By default system in a safe mode which is very restrictive. Program safety
is guaranteed by the M3 itself.
But any language that should be able to do something serious should allow
unsafe operations  which are usually low level operations, unchecked
conversions etc.  So M3 allows them but only in UNSAFE modules. In UNSAFE
modules it is programmer responsibility to provide system safety using
potentially unsafe operations.
As a result of such decision all (potentially) unsafe operations (if really
needed) are concentrated in  few unsafe modules and it makes it much easier
to trace all (potentially) unsafe code in the overall system design.
I think  Ada is a little bit behind M3 here.  Ada  tells that it has
potentially unsafe operations and tells that it is programmer responsibility
to provide system safety when using them (the same as M3).  But Ada allows
to use them in any piece of code, in any package. As a consequence of that
such potentially unsafe operations may be scatted all around program pieces
(packages) and this makes it difficult to trace all potentially unsafe
operations. Of course good system designer may concentrate such operations
in few packages and give them appropriate names (e.g. package
unsafe_something ). But nothing in the language itself forces him/her to do
so. Here I could recall frequent argument in Ada vs. C++ discussions. It is
frequently said that though C++ provide many more safety features that C
they are not often used just because nothing prevents C++ programmer from
use of unsafe features of C and that Ada is better that C++ in that respect
as it forces programmer to use safe features ( as there are only a few
number of unsafe ones).

Coming back to M3 decision about safe and unsafe operations it is very good
from overall system design management process.  If you are a manager  and
you have some number of employees you divide pieces of work and areas of
responsibility between your employees and as result you know who is
responsible for what. This forces employees to take more serious approach to
the work as they know that this is only his/her responsibility to provide
good result and there would be no one to blame for the bad result.
M3 provide the same kind of  management.
It divides areas of responsibility of providing safety between core language
itself (in the safe modules  and interfaces) and programmer (in unsafe
modules). It does not allow any unsafe operations in safe modules.
But when programmer need to use them then it defines interface/module as
unsafe and clearly understand that it is his/her responsibility to provide
needed level of safety here.
I think that advantages of such approach are very obvious and clear.
Probably reason why Ada 95 did not took such approach was requirement of
upward compatibility with Ada 83 or may be something else. I do not know.
May be people that took part in Ada design could clarify that issue.
Here I would like to stress once more that any Ada developer may follow the
same approach as in M3 (and good one probably would do so) but nothing in
the language forces him/her to do so.

-----------------------
Another thing that I would like to mention here is MDC thoughts about types
with saturation behavior.
It seems that  no one paid attention to that  as I have seen no comments
about that.
I would like to say that I fully support this idea.
Saturation is one of the fundamental things in physics, electronics,
mechanical engineering, control systems operations and many  other areas
(including mental activity as well :-)
If language could support such fundamental  types it could be very fruitful
in many areas and could add some more flexibility and safety that are
already major features of Ada.
Of course such types probably could be created by programmer itself but it
does not look to be very simple and straightforward  and it probably
requires some low level support to be efficiently implemented.

>And that is why Ada is the correct choice for safety-critical software.


Right now probably there are no other choices.
May some time later we will have one more  -  Ada-M :-)


Regards,

Vladimir Olensky