From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fee8802cc3d8334d X-Google-Attributes: gid103376,public From: "Vladimir Olensky" Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/20 Message-ID: <929824768.978.25@news.remarQ.com> X-Deja-AN: 491524938 References: <7jt2c0$vrb@drn.newsguy.com> <7k57vb$1ipf@drn.newsguy.com> <3766650F.705125B7@pwfl.com> <7k64t7$igo$1@its.hooked.net> <7k689a$ci2@drn.newsguy.com> <3766C842.E1EAB60A@pwfl.com> <3766D1CC.D712895E@itools.symantec.com> <7k8nn5$qcb$1@its.hooked.net> <3767E8A2.EF1A0570@itools.symantec.com> <7k8tv3$3gm@drn.newsguy.com> <7kg9is$85g@dfw-ixnews8.ix.netcom.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Complaints-To: newsabuse@remarQ.com X-Trace: 929824768.978.25 K3TLTKYJOA5C9C7F8C qube-01.us-ca.remarq.com Organization: Posted via RemarQ, http://www.remarQ.com - The Internet's Discussion Network NNTP-Posting-Date: Sat, 19 Jun 1999 20:39:28 GMT Newsgroups: comp.lang.ada Date: 1999-06-20T00:00:00+00:00 List-Id: 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 , > Hyman Rosen 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