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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6a26a44c348fcea3,start X-Google-Attributes: gid103376,public From: DSCI-New Jersey Subject: Re: INFO-ADA Digest - 13 Dec 1997 to 14 Dec 1997 Date: 1997/12/15 Message-ID: <199712151446.GAA12502@denmark.it.earthlink.net> X-Deja-AN: 298375354 Sender: Ada programming language References: <199712150631.WAA20162@finland.it.earthlink.net> X-Sender: dsci@mail.earthlink.net Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1997-12-15T00:00:00+00:00 List-Id: Please do not forward any more messages to this address. Robert Glenn Booker is not longer at this office. Thank you for your immediate cooperation. At 12:30 AM 12/15/97 -0600, you wrote: >Date: Mon, 15 Dec 1997 00:30:50 -0600 >Reply-To: Ada programming language >Sender: Ada programming language >From: Automatic digest processor >Subject: INFO-ADA Digest - 13 Dec 1997 to 14 Dec 1997 >To: Recipients of INFO-ADA digests > >There are 7 messages totalling 296 lines in this issue. > >Topics of the day: > > 1. Beware: Rep spec on an enumeration type causes code explosion (2) > 2. Beware: Rep spec on an enumeration type clause > 3. Need help with code? > 4. Which language pays most 17457 -- C++ vs. Java? > 5. Beware: Rep spec on an enumeration type ... > 6. Why it was a bad idea to drop The Mandate. >Date: Sun, 14 Dec 1997 22:47:34 -0800 >From: Alan E & Carmel J Brain >Subject: Re: Beware: Rep spec on an enumeration type causes code explosion >MIME-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Rakesh Malhotra wrote: > >> We work on safety critical projects. And if we have a safety critical >> bit of code that defines and uses an enumeration then we use the rep >> clause to provide more than 1 bit separation between adjacent values in >> the enumeration. That way if 1 bit got corrupted the value could not >> become some other legal value. > >See if I understand you correctly: Thus you'd use 2#1100 and 2#0011 for >example, to avoid single-bit soft failures. Just don't choose 2#0000 and >2#1111 as many soft failures either latch high or latch low. Right? > >Interesting, not seen this technique used before, but it makes sense in >some areas. And my vast ignorance is infinitesimally decreased, >thank-you. > >Am I right in thinking that in the areas where such paranoia is >reasonable, the code could well look like: > >SECTION_1 >begin > single statement, or at most a few >exception > when (etc) >end SECTION_1; > >SECTION_2 >begin > single statement, etc >exception > when (etc) >end SECTION_2; > >and repeat as nauseum. > >Such code, where efficiency is not a major consideration :) might well >be appropriate in certain specialised areas. Just not in the general >case, even for safety-critical stuff. >-- >aebrain@dynamite.com.au <> <> How doth the little Crocodile >| Alan & Carmel Brain| xxxxx Improve his shining tail? >| Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM > abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo > By pulling MAERKLIN Wagons, in 1/220 Scale >Date: Fri, 12 Dec 1997 21:25:33 -0800 >From: Alan E & Carmel J Brain >Subject: Re: Beware: Rep spec on an enumeration type causes code explosion >MIME-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >John G. Volan wrote: > >> There is no need for anything so elaborate. Just derive a holey >> enumeration type from a contiguous enumeration type. > >--->8--- >> My feeling is that "holey" enumeration types (like other Chapter 13 >> features) should really only be used at the "edges" of a program, >--->8--- >> Contiguous enumeration >> types should be used internally everywhere else in your program > >Concur. Matches my own experience exactly. Although we didn't test to >see what the performance hit would have been if we'd have used the >rep type throughout. Any experimental data on this? > >-- >aebrain@dynamite.com.au <> <> How doth the little Crocodile >| Alan & Carmel Brain| xxxxx Improve his shining tail? >| Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM > abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo > By pulling MAERKLIN Wagons, in 1/220 Scale >Date: Fri, 12 Dec 1997 11:30:19 +0100 >From: Franco Mazzanti >Subject: Re: Beware: Rep spec on an enumeration type clause >MIME-Version: 1.0 >Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" >Content-Transfer-Encoding: 7bit > >Rakesh Malhotra wrote: > >> We work on safety critical projects. And if we have a safety critical >> bit of code that defines and uses an enumeration then we use the rep >> clause to provide more than 1 bit separation between adjacent values in >> the enumeration. That way if 1 bit got corrupted the value could not >> become some other legal value. >> >> Hence type SIGNAL_TYPE is (RED, GREEN); >> for SIGNAL_TYPE use (RED => 16#00#, GREEN => 16#03#); >> >> So if a signal was supposed to be RED, with just a 1 bit corruption it >> could never become GREEN. Obviously we have these kinds of enum's and >> rep clauses all over the code space, and they are used in arrays to >> index etc etc. An even worse example (from the coder's point of view) >> is that we create our own BOOLEAN_TYPE with states defined as TRUE_STATE >> and FALSE_STATE ; then give both true and false explicit values; and >> then test for those in "if" statements etc :) Pretty horrible eh ? >> >> -- >> Rakesh. > > >Since the program behaviour when some invalid object is encountered is >highly >implementation dependent, this approach seems really dangerous to me ... >For example, for example, the following program, compiled with GNAT v.3.09 >happily (and legally) produces the output: > >> I is neither AA, BB or CC >> I is AA or BB > >with Ada.Text_IO; use Ada.Text_IO; >procedure Main is > type T is (AA, BB, CC); > for T use (AA => -1, BB => 10, CC => 20); > I:T; -- not initialised > V:array (T) of Integer; >begin > if not I'Valid then > Put_Line("I is neither AA, BB or CC "); > end if; > case I is > when AA..BB => -- can be selected if I is invalid > Put_line("I is AA or BB"); > when CC => -- can be selected if I is invalid > Put_line("I is CC"); > V(CC) := 0; > end case; >end Main; > >------------------------------------------------------------ > Franco Mazzanti > Istituto di Elaborazione della Informazione > mazzanti@iei.pi.cnr.it >------------------------------------------------------------ >Date: Sun, 14 Dec 1997 17:11:11 -0500 >From: Chris Morgan >Subject: Re: Need help with code? > >Not enough comments for a start! > >Chris > >"Eric Sabo" writes: > >> >> Can someone tell what am I doing wrong with this code? >> ----------------------- begin ---------------------------------------- >> generic >> type item_type is private; > >-- >Chris Morgan > "I'm considering throwing myself out of the window. It > wouldn't do me much damage because we're on the ground > floor, but it might make for a bit of variety." - Lizzy Bryant >Date: Sun, 14 Dec 1997 14:30:48 GMT >From: Kurt Watzka >Subject: Re: Which language pays most 17457 -- C++ vs. Java? > >Guillermo Schwarz writes: > >>For a language to be succesful, 6 things must happen: >>1. Actual programs must be written in it. >>2. Lots of libraries must be written for it. >>3. Most computer architectures must have a compatible version of it. >>4. Source code must be easily understable (by good coders). >>5. Lots of programmers must know the language in deep. >>6. The syntax must be simple. The semantics must be well defined. > >>C is ok with 1, 2 and 3, but not with 4, 5 and 6. >>Smalltalk is ok with 1, 2, 3, 4, 5 and 6. >>Take a look at Squeak. > >You forgot to mention that this is your opinion, and nothing but >your opinion. C is a relatively simple language, and I doubt that >there are too many people around who both qualify as good coders >and do not understand C after learning it. > >Can you come up with any substantial facts that support the claim >that more programmers know Smalltalk "in deep" than C? The syntax >of C is well defined. As long as you write code with well defined >semantics, well, the semantics are well defined in C. Whether >the liberty to write code with undefined or implementation defined >semantics is a weak or a strong point for C, even I do not care to >argue about. > >Kurt > >-- >| Kurt Watzka Phone : +49-89-2178-2781 >| watzka@stat.uni-muenchen.de >Date: Mon, 15 Dec 1997 02:15:57 GMT >From: Dale Stanbrough >Subject: Re: Beware: Rep spec on an enumeration type ... >MIME-Version: 1.0 >Content-Type: text/plain; charset=ISO-8859-1 >Content-Transfer-Encoding: 8bit > >"Well, this certainly allows us to size the problem: One must have a > graduate degree in language design and compiler techniques to use Ada. > That's quite a revelation. We would have never suspected that Ada was > that hard to use. > > This gets to the heart of the problem. Our programmers, being domain > experts, would rather take graduate degrees in their respective fields of > interest, in their chosen professions. If they were interested in being > compiler experts, they would have instead studied compilers, and they > would probably work for a compiler vendor, not a system vendor, because > few system vendors build compilers. Nor would they be experts at other > than compilers; there are only so many hours in the day. Domain expert > and compiler expert are very different fields." > > >I think this is a rather pessimisstic intrepretation of what Robert said. >Robert's point, which I agree with, is that if you want to use tools in >your job, you have to understand how to use them, and what their >limitations are. > >For example imagine someone who wishes to make films. "I've been to >director's school, I know how to direct, why do I need to know anything >about how video/film camera's work?". Yet I'm sure you would agree that >you can't film someone with the sun directly in the lens. What about >flare from lights? What other restrictions are there that are placed on >a director by technical limitiations? > >Using any technology without understanding it is just inviting disaster, >and this is shown out by your own experience. Yes your software "worked", >but it got tripped up by a bad implementation (it was slower than it >should have been). At the Melbourne TOOLS conference a few years back >Roger Osmond spoke about his team's experience using Eiffel in building >a data comms box (he was very enthusiastic). However initially his team >found that the software was unbelievably slow because they were >continually allocating memory, and leaving it to be cleaned up by the >GC system. In the end the domain experts needed to understand the >consequences of unfettered allocation in such an environment. They >needed to understand the technology to be able to use it constructively. > >As to your other point, attending a compiler construction course does >not mean you will be a compiler writer - it just means you are familiar >with the issues. It would be helpful if so many more students _did_ >attend these classes by the way - it would often help dispel the >"while (!(*p)) { *q++ = *p++} must be more efficient than an Ada for >loop" myth. > > >Dale >Date: Mon, 15 Dec 1997 02:19:33 GMT >From: Dale Stanbrough >Subject: Re: Why it was a bad idea to drop The Mandate. >MIME-Version: 1.0 >Content-Type: text/plain; charset=ISO-8859-1 >Content-Transfer-Encoding: 8bit > >"Even as we speak (type), systems > in which the long-gone program manager invented a > flimsy excuse to use C or C++ are in horrible > trouble because their compilers are obsolete, are > no longer supported, and the language definition > has changed. > >I would be truly surprised if this was the case for C. There >is a standard for C, which is very well known, and for which >there would be many compilers which are up to the mark. > > >Dale >