Re: INFO-ADA Digest - 13 Dec 1997 to 14 Dec 1997

Re: INFO-ADA Digest - 13 Dec 1997 to 14 Dec 1997

[DSCI-New Jersey]

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 <INFO-ADA@LISTSERV.NODAK.EDU>
>Sender:   Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
>From:     Automatic digest processor <LISTSERV@LISTSERV.NODAK.EDU>
>Subject:  INFO-ADA Digest - 13 Dec 1997 to 14 Dec 1997
>To:       Recipients of INFO-ADA digests <INFO-ADA@LISTSERV.NODAK.EDU>
>
>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 <aebrain@DYNAMITE.COM.AU>
>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 <aebrain@DYNAMITE.COM.AU>
>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 <mazzanti@IEI.PI.CNR.IT>
>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 <mihalis@IX.NETCOM.COM>
>Subject: Re: Need help with code?

>
>Not enough comments for a start!
>
>Chris
>
>"Eric Sabo" <sabo@hhs.net> writes:
>
>>
>> Can someone tell what am I doing wrong with this code?
>> ----------------------- begin ----------------------------------------
>> generic
>>  type item_type is private;
>
>--
>Chris Morgan <mihalis at ix.netcom.com>
>     "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 <watzka@STAT.UNI-MUENCHEN.DE>
>Subject: Re: Which language pays most 17457 -- C++ vs. Java?
>
>Guillermo Schwarz <gschwarz@netup.cl> 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 <dale@GOANNA.CS.RMIT.EDU.AU>
>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 <dale@GOANNA.CS.RMIT.EDU.AU>
>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
>