* Re: INFO-ADA Digest - 13 Dec 1997 to 14 Dec 1997
[not found] <199712150631.WAA20162@finland.it.earthlink.net>
@ 1997-12-15 0:00 ` DSCI-New Jersey
0 siblings, 0 replies; only message in thread
From: DSCI-New Jersey @ 1997-12-15 0:00 UTC (permalink / raw)
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
>
^ permalink raw reply [flat|nested] only message in thread