Help Me Please :)

Help Me Please :)

[Will Mann]

Can some one help me with my Ada.. my lecturer has given me code that
doesn't work... the compiler says that it can't handle "A".."Z" the
error message is :

 Inappropriate operands for "DOT_DOT" operation, continuing

Thanks

--

:\        /   |   |           ALL DONE BYE BYE!
: \  /\  /  * |   |
:  \/  \/   | |__ |__

Re: Help Me Please :)

[Robert Dewar]

In article <38BC4EAF.209AE20C@port.ac.uk>,
  Will Mann <csm90231@port.ac.uk> wrote:
> Can some one help me with my Ada.. my lecturer has given me
code that
> doesn't work... the compiler says that it can't handle
"A".."Z" the
> error message is :
>
>  Inappropriate operands for "DOT_DOT" operation, continuing

Well here is how you might be able to find that out for
yourself. Obviously the compiler does not like the operands
for your .. expression, so look up in your Ada book the rules
for .. and you will find that discrete types are required.
Now look up discrete types, and you will find that they
include integer and enumeration types, including particular
character types. Clearly you are trying for the latter here,
so go look up what character literals should look like, and
you will find that they use single quotes, so you should
have written

   'a' .. 'z'

I think you might have had an easier type finding the error
for yourself with GNAT:

g.adb:3:17: expected a discrete type
g.adb:3:17: found a string type

In general I think the error messages from GNAT are likely to
be clearer for a beginner (or anyone else for that matter),
since huge effort has gone into making the messages clear.
You might consider getting hold of a copy of GNAT (which is
available for free download -- go to the ftp directories
at cs.nyu.edu, directory /pub/gnat).

At the very least, if you get another message you don't
understand, you can try and see what GNAT says :-)

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[Florian Weimer]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In general I think the error messages from GNAT are likely to
> be clearer for a beginner (or anyone else for that matter),
> since huge effort has gone into making the messages clear.

The GNAT compiler error messages are remarkably clear, but the GNARL
(i.e. runtime) "messages" (i.e. text messages associated with an
exception) are mostly non-existent.  For example, I think it would be
very nice to get the information that a certain Program_Error
exception was caused by a failed Accessibility_Check.

Are other compilers different in this regard?

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
RUS-CERT, Univ. Stuttgart         http://cert.uni-stuttgart.de/

Re: Help Me Please :)

[Larry Kilgallen]

In article <2000Mar3.183321.69279@ludens>, gazso@ludens.elte.hu (Erdelyi Gaspar) writes:

> I think that GNAT is not comparable to DEC Ada (for OpenVMS) which provides
> very useful error messages. DEC Ada is Ada83 only and the prices are not
> comoparable, too...
> 
>   Gaspar Erdelyi
>   university student 

DEC Ada is Ada83 only, but for a university student the VMS Hobbyist
License gives you DEC Ada for free (restricting it to personal use
that is not commercial).  Thus in your situation I would say prices
are quite comparable.

Re: Help Me Please :)

[Robert Dewar]

In article <2000Mar3.183321.69279@ludens>,
  gazso@ludens.elte.hu (Erdelyi Gaspar) wrote:

> I think that GNAT is not comparable to DEC Ada (for OpenVMS)
> which provides very useful error messages. DEC Ada is Ada83
> only and the prices are not comoparable, too...

Well the prices are not that far from comparable, but that's
another issue anyway. With regard to error messages there are
four cases of interest:

1. Cases where DEC Ada 83 simply gets confused, and GNAT does
not. There are quite a few of these, one notable example is
the GNAT circuit for dealing with the semicolon/IS confusion.
All other compilers I know can get confused by this, including
DEC Ada 83.

2. Cases where GNAT gets confused, and DEC Ada 83 does not. I
don't currently know of any such cases, but that does not mean
they do not exist. If you know of such cases, it is always
useful to submit them to report@gnat.com, we are always working
to tune the error message circuit (indeed giving good messages
is a hobby of mine :-)

3. Cases where neither compiler gets confused and the error
messages are comparable. Having worked through the entire
DEC test suite, which contains thousands of examples of
error situations, I would say this is probably the most
common case.

4. Cases where neither compiler gets confused and the
error messages are substantially different. These are
interesting cases to look at. Sometimes there is simply
a difference in style. GNAT aims at trying to keep error
messages short and informative, whereas DEC Ada 83 often
gives rather voluminous messages. In GNAT, you can more
nearly approximate this verbose mode by using the -gnatf
switch. But there will still be differences, some of these
might just be a matter of taste, some may be cases where
real improvements are possible (there are certainly cases
in the DEC test suite where the GNAT message is more useful,
I don't know of any cases left where I consider the DEC
Ada 83 message significantly better in this test suite,
because we used the suite to tune up such cases in GNAT :-)

Here again, in case 4, it is very useful if you send in
cases where you think an error message can be improved.
This actually is a much more general request than just
comparing these two compilers. Any time you get a compile
time message that you think could be clearer, send it along.
We may well agree, and we may well be able to do something
about it.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[tmoran]

>For example, I think it would be
>very nice to get the information that a certain Program_Error
>exception was caused by a failed Accessibility_Check.
>
>Are other compilers different in this regard?
  Yes.  Compiler differ a lot in what you get from
Ada.Exceptions.Exception_Information.

Re: Help Me Please :)

[Richard D Riehle]

In article <lJSv4.1648$im1.34999@news.pacbell.net>,
	tmoran@bix.com wrote:

>>For example, I think it would be
>>very nice to get the information that a certain Program_Error
>>exception was caused by a failed Accessibility_Check.
>>
>>Are other compilers different in this regard?
>  Yes.  Compiler differ a lot in what you get from
>Ada.Exceptions.Exception_Information.

It has often been noted, by those in the embedded software community, that
the features of Ada.Exceptions are not very useful.  "Who wants to be passing
all those strings around all the time?"   In other environments, especially
command and control systems, this package is turning out to be useful.  

I have taken to describing the exception handling event in terms of electrical
design.   We can overload a circuit and burn down the house.  We can install
a fuse and prevent the overload from doing its damage.  We can design the
exception handler as a software circuit-breaker that detects the problem,
corrects it, resets itself, and continues on with normal processing.

The non-stop characteristics of a command and control system dictate that the
exception handling often be designed as a software circuit-breaker rather than
a fuse.  We see this in many software designs, regardless of language.  The
problem with Ada is its designation of exceptions as something slightly apart
from a typical data type.  


In some languages, exceptions are first class objects.  Ada exceptions are
not first class objects for very good reasons.  However, it is sometimes useful
to promote them to first class objects and benefit from whatever information 
one can get when the software circuit-breaker is triggered.  

One way to promote an Ada exception to a first class object is to declare it as
an Ada.Exceptions.Exception_Occurrence.  A compiler, such as that from Aonix or
RR Software, that returns detailed information in a call to the function,
Ada.Exceptions.Exception_Information, permits the developer to design a logging
module for later review of software circuit-breaker events.  In fact, the package
is designed to permit an access to an exception occurrence, thereby implying some
capabilities one could find very useful in a CCC3I/CCC4I environment.  

I have decided to include an entire chapter on this topic in the book I have been
writing about Object Technology in Ada.  It is taking longer to finish this book
than I expected because I keep coming up with ideas.  I guess we call this "feature
creep" in software development.  As soon as some publisher says they want to take
it "as is" I'll stop and turn it over to them as a first edition.  Meanwhile, working
on it keeps me out of trouble.  

Richard Riehle

Re: Help Me Please :)

[Steve Arnold]

Richard D Riehle wrote:

> I have decided to include an entire chapter on this topic in the book I have been
> writing about Object Technology in Ada.  It is taking longer to finish this book
> than I expected because I keep coming up with ideas.  I guess we call this "feature
> creep" in software development.  As soon as some publisher says they want to take
> it "as is" I'll stop and turn it over to them as a first edition.  Meanwhile, working
> on it keeps me out of trouble.  

Come on Richard, I've been waiting long enough (and Jeff's class is
getting
obtuse).  When can we expect to take a look at this book?

**********************************************************************
Steve Arnold                                     sarnold@earthling.net
"We'll chase them like rats across the tundra!"
                                                -unknown

Re: Help Me Please :)

[Robert A Duff]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

> In some languages, exceptions are first class objects.  Ada exceptions are
> not first class objects for very good reasons.
                              ^^^^^^^^^^^^^^^^^

I beg to differ.  I think this is one of the few cases where those other
languages got it right, and Ada got it wrong.

If you want strings, Ada.Exceptions works OK (although it's annoying to
have "exceptions" and "Exception_Ids", which are both essentially
representations of the same concept).  If you want to attach some other
type of data to an exception, you're stuck with several poor
alternatives: You could encode that data as a String, but then you lose
type checking -- the declaration of an exception ought to declare the
type of attached data, forming a compile-time-checkable contract between
the raise point and the handler point.  Or you could store the
information in a global, but then you lose task safety, and there are
issues of exactly when that global data is valid.  Etc.

- Bob

Re: Help Me Please :)

[James S. Rogers]

Robert A Duff wrote in message ...
>Richard D Riehle <laoXhai@ix.netcom.com> writes:
>
>> In some languages, exceptions are first class objects.  Ada exceptions
are
>> not first class objects for very good reasons.
>                              ^^^^^^^^^^^^^^^^^
>
>I beg to differ.  I think this is one of the few cases where those other
>languages got it right, and Ada got it wrong.


Have you ever used exceptions in C++? Very few people do.
The problem arises from the fact that exceptions are first class objects.

In C++ you cannot "catch" an exception without knowing its type. This means
that you must have exquisite coupling with all your dependent compilation
units
to use exceptions reliably. This coupling requirement works strongly against
encapsulation and modularity.

The only way around this is to declare a single exception type for all
exceptions
generated by an application. This leaves you in the same position as you are
in Ada.  Of course, the problem with this solution for C++ is that you will
probably use
class libraries, which, if they use exceptions at all, will probably not
conform to the
exception class chosen by your team. If this is the case, then you are in a
much
worse situation than if you used Ada.

Jim Rogers
Colorado Springs, Colorado

Re: Help Me Please :)

[Robert A Duff]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> writes:

> Have you ever used exceptions in C++? 

No.  The last time I used C++ (some years ago), most compilers did not
support exceptions.  The closest I could get was reading about them in
Stroustrup's book.  But I have used exceptions in other languages that
define exceptions as first-class objects.

>...Very few people do.
> The problem arises from the fact that exceptions are first class objects.

I don't understand this problem.  Perhaps you could give an example?  Is
the problem you're talking about C++-specific, or are you claiming it's
a fundamental problem with the idea of exceptions-as-objects?

One problem I see with C++ exceptions is that anything can be an
exception -- you can throw a string or an int or whatever.  I would
prefer to have a distinguished exception class, and then you could
define new exceptions by subclassing that.  Several other languages that
have first-class exceptions do exactly that.  But this seems like a
minor issue.

> In C++ you cannot "catch" an exception without knowing its type. This means
> that you must have exquisite coupling with all your dependent compilation
> units
> to use exceptions reliably. This coupling requirement works strongly against
> encapsulation and modularity.

Again, I don't get it.  Of course you can't catch an exception without
knowing its type.  Just like in Ada you can't handle an exception
without knowing its name.  I don't see how that breaks encapsulation and
modularity.

> The only way around this is to declare a single exception type for all
> exceptions
> generated by an application. This leaves you in the same position as you are
> in Ada.  Of course, the problem with this solution for C++ is that you will
> probably use
> class libraries, which, if they use exceptions at all, will probably not
> conform to the
> exception class chosen by your team. If this is the case, then you are in a
> much
> worse situation than if you used Ada.

- Bob

Re: Help Me Please :)

[Brian Rogoff]

On Sun, 19 Mar 2000, Robert A Duff wrote:
> "James S. Rogers" <jimmaureenrogers@worldnet.att.net> writes:
> 
> > Have you ever used exceptions in C++? 
> 
> No.  The last time I used C++ (some years ago), most compilers did not
> support exceptions.  The closest I could get was reading about them in
> Stroustrup's book.  But I have used exceptions in other languages that
> define exceptions as first-class objects.
> 
> >...Very few people do.
> > The problem arises from the fact that exceptions are first class objects.
> 
> I don't understand this problem.  Perhaps you could give an example?  Is
> the problem you're talking about C++-specific, or are you claiming it's
> a fundamental problem with the idea of exceptions-as-objects?

I agree with Bob Duff here, in that I don't understand. When I was hacking 
Java, my complaint about the exception mechanism wasn't that you could 
throw objects, it was that you had to declare or catch all exceptions,
which causes lots of people to subclass from RuntimeException to avoid
this. But that's not the issue at hand.

I think exception types would be a good thing, but its way too late to fix 
that now, and it was probably too late for Ada 95. A future Ada-inspired 
language could fix this.

-- Brian

Re: Help Me Please :)

[Tucker Taft]

Brian Rogoff wrote:
> ...
> I think exception types would be a good thing, but its way too late to fix
> that now, and it was probably too late for Ada 95.

In fact, early in the Ada 9X process we proposed the equivalent of
parameterized exceptions that formed a hierarchy.  All quite elegant.
It could still be done in my view.  It was just beyond what the 
reviewers were ready for at the time.

An alternative simpler addition is to add a package "Ada.Exceptions.Objects"
or equivalent, which allows one to "Raise_With_Object" where you could
pass in an object of any type extended from, say, Exception_Object_Root,
and be able to retrieve it given an Exception_Occurrence, in the same
way one can pass in a string, and retrieve it.  We might set some
arbitrary upper limit on the 'Size of the object passed in that must
be supported by an implementation, e.g. 1500 bits (analogous to the
200 character limit for exception messages).

> ... A future Ada-inspired
> language could fix this.

It's really not that far fetched.  E.g.:

    Out_Of_Space : Exception(X : Integer; Y : access Blob) is 
      new Storage_Error;
    ...
    raise Out_Of_Space(X => 5, Y => Blurfo'Access);
    ...
  when OOS : Out_Of_Space => 
      Put_Line("Out of space, needed: " & Integer'Image(OOS.X));

> -- Brian

-Tuck

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Help Me Please :)

[Richard D Riehle]

In article <wccog8dqvk6.fsf@world.std.com>,
	Robert A Duff <bobduff@world.std.com> wrote:

>Richard D Riehle <laoXhai@ix.netcom.com> writes:
>
>> In some languages, exceptions are first class objects.  
>> Ada exceptions are not first class objects for very good reasons.
>                                                 ^^^^^^^^^^^^^^^^^
>>I beg to differ.  I think this is one of the few cases where those other
>languages got it right, and Ada got it wrong.

Delighted to have this response from you.  I have been spending some
time with C++ lately and find the exception model to be confusing,
error-prone, and more complicated than necessary.  One reason I like
the Ada model is its simplicity compared to other languages.  We
can agree to disagree on this.  

>If you want strings, Ada.Exceptions works OK (although it's annoying to
>have "exceptions" and "Exception_Ids", which are both essentially
>representations of the same concept).  If you want to attach some other
>type of data to an exception, you're stuck with several poor
>alternatives: You could encode that data as a String, but then you lose
>type checking -- the declaration of an exception ought to declare the
>type of attached data, forming a compile-time-checkable contract between
>the raise point and the handler point.  Or you could store the
>information in a global, but then you lose task safety, and there are
>issues of exactly when that global data is valid.  Etc.

For embedded systems, one does not want to be, in the words of Dr.
Tokar of DDC-I, ..."passing strings all over the place."  Also, 
for non-embedded systems, not all compilers adequately support 
the facilities of Ada.Exceptions, especially.  Janus and ObjectAda
have pretty good support for the function, Exception_Information,
but some others do not.  

The reason for promoting an exception to a typed value has to be 
compelling.  Consequently, it is rarely necessary.  In an application
such as a non-stop command and control system, one could find compelling
reasons for wrapping an exception_occurrence in a tagged type and
referring to it during some lull in activity as part of a logging
operation.  There are other circumstances when promoting an 
exception to a first-class object might be compelling.  

In the absence of such compelling circumstances, insisting that an 
exception be a first-class object simply complicates the entire
exception handling process.  The Ada solution, which provides the
option of promoting it to a first-class object, seems to me the
optimal solution.  

Thanks for you insight on this.  I beleive it is an important thread
of discussion about Ada, one we do not visit often enough.  

Richard Riehle
richard@adaworks.com
 

Re: Help Me Please :)

[Florian Weimer]

Robert A Duff <bobduff@world.std.com> writes:

> Richard D Riehle <laoXhai@ix.netcom.com> writes:
> 
> > In some languages, exceptions are first class objects.  Ada exceptions are
> > not first class objects for very good reasons.
>                               ^^^^^^^^^^^^^^^^^
> 
> I beg to differ.  I think this is one of the few cases where those other
> languages got it right, and Ada got it wrong.

Yes, that's my impression as well.  Although the Ada approach makes
it much easier to write general purpose exception handlers (which only
log unexpected exceptions), some things are quite difficult to handle.

For example, look at the POSIX.5 binding.  There's a single POSIX_Error
exception and a task-specific variable to tell one kind of error
from the other.  The other possibility would have been to use one
exception per error, but this would make exception handlers very
elaborated (they would have to handle quite a lot of them).  I wish I
could create a hierarchy of exceptions in Ada (so that, for example,
handling POSIX_Error catches Broken_Pipe_Error, too)...

Re: Help Me Please :)

[Mats Weber]

Robert A Duff wrote:
> 
> Richard D Riehle <laoXhai@ix.netcom.com> writes:
> 
> > In some languages, exceptions are first class objects.  Ada exceptions are
> > not first class objects for very good reasons.
>                               ^^^^^^^^^^^^^^^^^
> 
> I beg to differ.  I think this is one of the few cases where those other
> languages got it right, and Ada got it wrong.

I think the designers of Modula-3 got it just right. You can have a look
at http://www.m3.org/

Re: Help Me Please :)

[Robert A Duff]

Mats Weber <matsw@mail.com> writes:

> Robert A Duff wrote:
> > 
> > Richard D Riehle <laoXhai@ix.netcom.com> writes:
> > 
> > > In some languages, exceptions are first class objects.  Ada exceptions are
> > > not first class objects for very good reasons.
> >                               ^^^^^^^^^^^^^^^^^
> > 
> > I beg to differ.  I think this is one of the few cases where those other
> > languages got it right, and Ada got it wrong.
> 
> I think the designers of Modula-3 got it just right. You can have a look
> at http://www.m3.org/

I beg to differ, again.  ;-)

I see several problems with Modula-3's exception mechanism, some of
which are shared by Ada.  (My knowledge of the language comes from
Harbison's book, "Modula-3".  I've never written a Modula-3 program.)

There's no hierarchy of exceptions.  This means that the designer of
some code that raises exceptions must decide on the granularity of
exception handling; it would be better for the handler to make that
decision.  For example, one handler might want to handle all "I/O
errors", whereas another handler might want to handle just "disk-full
error".  Making exceptions first-class objects (which they are not, in
Ada and Modula-3) would solve this problem, at no cost in language
complexity.

An exception takes just one parameter.  Why not two or three or however
many I like?  Again, making exceptions extensible object types would
solve the problem.

The behavior in the presense of "checked run-time errors" (things like
divide by zero, arithmetic overflow, array index out of bounds) is not
defined by the language.  So an array index out of bounds might raise
Array_Index_Error on one implementation, and Constraint_Error on another
implementation, and simply stop the program dead in its tracks on a
third implementation.  I don't like that non-portability.

(On the other hand, Ada *pretends* that it's OK to raise and handle
Constraint_Error, but if you read RM-11.6, you'll find that's not quite
true -- and I doubt if any Ada programmer other than Tucker Taft
actually *understands* 11.6.  So in practise, 11.6 says, "Do not handle
predefined exceptions.")

The "raises set" of a procedure defines what exceptions it can raise.
The problem is that this rule is checked at run time.  Java is closer to
the right solution -- it checks that rule at compile time.  However,
Java suffers from the "cry wolf" problem.  I think it's possible to
avoid the "cry wolf" problem, and still do most of that checking at
compile time.

The parameter of an exception occurrence (in Ada terms) is a variable.
Why not a constant?

There is no re-raise statement (spelled "raise;" in Ada), so a "when
others" handler (Ada spelling again) can't propagate the same exception.
You can't raise the same exception occurrence, because the thing
available in the handler is not the occurrence, but just its parameter,
and then only if you named a particular exception.

Return and exit statements are defined in terms of raising a RETURN or
EXIT exception.  That seems kludgy to me, because exceptions are for
cases where the target of the jump is determined dynamically, whereas
return and exit are jumping to a statically-known place.  So it's sort
of overkill.  In practical terms, it means that a "when others" will
handle a RETURN or EXIT, and you can't re-raise it, so the return
doesn't actually return, and the exit doesn't actually exit the loop.

All exceptions must be declared at top level.  This solves the
kludginess of Ada, where they can be declared anywhere, but act *as if*
they were declared at top level.  But I think there are better solutions
to that problem, based on the "procedure declares what exceptions it can
raise" idea of Modula-3, Java, etc.

There's nothing like Eiffel's preconditions, postconditions, and
invariants, which tie exceptions to the conditions that cause them.  In
Modula-3, you can say "this thing might raise Stack_Full", whereas in
Eiffel you can say, "this thing will raise Stack_Full if Full(S) is
True."

So, I think CLOS, Clu, and Eiffel (and to some small extent, C++) all
have better ideas about exceptions than Modula-3 (or Ada).

- Bob

Re: Help Me Please :)

[Hyman Rosen]

Robert A Duff <bobduff@world.std.com> writes:
> The "raises set" of a procedure defines what exceptions it can raise.
> The problem is that this rule is checked at run time.  Java is closer to
> the right solution -- it checks that rule at compile time.  However,
> Java suffers from the "cry wolf" problem.  I think it's possible to
> avoid the "cry wolf" problem, and still do most of that checking at
> compile time.

Most people on comp.lang.c++.moderated have concluded that C++ throw
specifications are useless, except for the throw() spec which says
that a function will throw no exceptions at all. It would be interesting
to see a design which works well.

Re: Help Me Please :)

[reason67]

In article <wccya74m18e.fsf@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:

> (On the other hand, Ada *pretends* that it's OK to raise and handle
> Constraint_Error, but if you read RM-11.6, you'll find that's not
quite
> true -- and I doubt if any Ada programmer other than Tucker Taft
> actually *understands* 11.6. So in practise, 11.6 says, "Do not handle
> predefined exceptions.")

"Ladies and Gentlemen, Thank you for flying on the Boeing 777 Flight
633. Unfortunately, due to a minor bug in the flight control software
raising a predefined exception and Ada RM section 11.6, the flight
control software has crashed. We are now heading towards the ground at
700 miles per hour. Estimated time of arrival 10 seconds. Have a nice
day."
---
Jeffrey S. Blatt
      "If the truth will kill them, let them die."
             -- Immanuel Kant


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[Robert Dewar]

In article <8bqcu2$s0p$1@nnrp1.deja.com>,
  reason67@my-deja.com wrote:
> In article <wccya74m18e.fsf@world.std.com>,
> Robert A Duff <bobduff@world.std.com> wrote:
>
> > (On the other hand, Ada *pretends* that it's OK to raise and
handle
> > Constraint_Error, but if you read RM-11.6, you'll find
that's not
> quite
> > true -- and I doubt if any Ada programmer other than Tucker
Taft
> > actually *understands* 11.6. So in practise, 11.6 says, "Do
not handle
> > predefined exceptions.")
>
> "Ladies and Gentlemen, Thank you for flying on the Boeing 777
Flight
> 633. Unfortunately, due to a minor bug in the flight control
software
> raising a predefined exception and Ada RM section 11.6, the
flight
> control software has crashed. We are now heading towards the
ground at
> 700 miles per hour. Estimated time of arrival 10 seconds. Have
a nice
> day."


Well there was no smiley there, so let's assume the (rather
hard to believe) point is being made seriously.

In that case it is way way off base. Any safety critical
software is validated and verified at the object level. You
never depend on the correctness of the compiler, or the
correctness of understanding of the high level language
semantics.

Furthermore, in most safety critical software, one would never
have such a handler? Why not because it might typically be the
case that the handler code is deactivated, and deactivated code
is not permitted in many SC protocols.

Finally, 11.6 is about optimization, it is almost always the
case that you want *no* optimization for SC code. Why? Because
you want the best possible correspondence between source code
and object code.

So in short, the scenario above is triply unlikely!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[reason67]

In article <8brgcd$5kp$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:

> Well there was no smiley there, so let's assume the (rather
> hard to believe) point is being made seriously.
>
> In that case it is way way off base. Any safety critical
> software is validated and verified at the object level. You
> never depend on the correctness of the compiler, or the
> correctness of understanding of the high level language
> semantics.

Not the point I was making and also not always the case. I have seen
safty critical systems that wrote their SRS's such that they did not
have to do V&V on the Object level. And they did not. I agree that they
should, but should and do are not always the same.

> Furthermore, in most safety critical software, one would never
> have such a handler? Why not because it might typically be the
> case that the handler code is deactivated, and deactivated code
> is not permitted in many SC protocols.

Since I have worked in Safty Critical software for 11 years with several
Aerospace Companies (I am a contract engineer), I can safely say that
while you may have reason to think that what you are saying is true, in
reality, it is not the way the code is delivered. In fact, one aircraft
that I worked on required that all exceptions be caught at the lowest
levels and propagated out of subprograms as status.

I expect you can quote more reasons why this is an incorrect way to do
Safty Critical software. I can state that your discription is inaccurate
for code I have seen and the code I have written for several aircraft
(military and otherwise).

Now where I have seen the kind of thing you are talking about is when
doing hard real-time embedded stuff (Greater that 256 MHz cycle time
with limited memory with no OS, but where I did that was in a simulator
which is definitely not safty critical).

> Finally, 11.6 is about optimization, it is almost always the
> case that you want *no* optimization for SC code. Why? Because
> you want the best possible correspondence between source code
> and object code.

That I agree with. The same is true with hard real-time (which on first
glace seems backwards).
---
Jeffrey S. Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[Simon Wright]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In that case it is way way off base. Any safety critical
> software is validated and verified at the object level. You
> never depend on the correctness of the compiler, or the
> correctness of understanding of the high level language
> semantics.

That may well be true of SIL4 software, but I believe not normally so
for SIL(n<4).  In any case it all depends on the safety case and the
independent safety authority ..

Re: Help Me Please :)

[Simon Pilgrim]

Robert Dewar wrote:
> 
> In article <8bqcu2$s0p$1@nnrp1.deja.com>,
>   reason67@my-deja.com wrote:

> > "Ladies and Gentlemen, Thank you for flying on the Boeing 777
> Flight
> > 633. Unfortunately, due to a minor bug in the flight control
> software
> > raising a predefined exception and Ada RM section 11.6, the
> flight
> > control software has crashed. We are now heading towards the
> ground at
> > 700 miles per hour. Estimated time of arrival 10 seconds. Have
> a nice
> > day."

As one of the many engineers who have worked on the Boeing 777 Primary
Flight Computer, I'd like to respond to that.

> Well there was no smiley there, so let's assume the (rather
> hard to believe) point is being made seriously.
> 
> In that case it is way way off base. Any safety critical
> software is validated and verified at the object level. You
> never depend on the correctness of the compiler, or the
> correctness of understanding of the high level language
> semantics.

Correct.  The PFC code was module tested at object level.

> Furthermore, in most safety critical software, one would never
> have such a handler? Why not because it might typically be the
> case that the handler code is deactivated, and deactivated code
> is not permitted in many SC protocols.

Right again.
 
> Finally, 11.6 is about optimization, it is almost always the
> case that you want *no* optimization for SC code. Why? Because
> you want the best possible correspondence between source code
> and object code.

Not true for the PFC.  We have a lot of code to squeeze into that frame.
 
> So in short, the scenario above is triply unlikely!

More than that.  We have a triple redundant system, with three PFCs per
airplane.  Within each PFC are three lanes each with a different type of
processor.  The same source code is compiled to the three different
targets with three different compilers.

-- 
Regards,
Simon Pilgrim
Senior Systems Engineer
Avionic Systems Division
BAE SYSTEMS, Rochester, UK

Views expressed above are not necessarily shared by my employer.

Re: Help Me Please :)

[Robert Dewar]

In article <38ECEB56.8FD7596E@gecm.com>,
  Simon Pilgrim <simon.pilgrim@gecm.com> wrote:

> > Finally, 11.6 is about optimization, it is almost always the
> > case that you want *no* optimization for SC code. Why?
> > Because
> > you want the best possible correspondence between source
> > code and object code.
>
> Not true for the PFC.  We have a lot of code to squeeze into
> that frame.

Well "no optimization" is a relative term here, none of the
compilers you used had particularly strong optimizers by
modern standards. Certainly none of them took full
advantage of 11.6, which was the specific point of
this discussion.

Actually when the safety-critical crowd asks for no
optimization, they are making the usual mistake of
specifying a solution to their problem, rather than
stating the problem.

The problem is to make the examination of the object code
as easy as possible.

Certain types of optimization assist in this goal. For example,
with gnat, we usually find that -O1 assembly code is far easier
to follow than -O0 code, simply because there is so much less
of it.

On the other hand, if you have really fierce optimization,
involving high level algorithm substitution, propagation
of information all around the place, including erroneous
situations, massive restructuring of code, etc, then the
resulting object code can become quite complex to read.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[r_c_chapman]

> Certain types of optimization assist in this goal. For example,
> with gnat, we usually find that -O1 assembly code is far easier
> to follow than -O0 code, simply because there is so much less
> of it.

I concur - results from our paper in Ada Europe 99 confirm this.

Brief summary:

On the original SHOLIS project, we had SPARK83 targetting 68040,
and we found the optimizer made very little difference to run-time
and/or object-code understandability, but the Alsys compiler
has hand-written code selection which makes the "unoptimized" code
quite reasonable in those terms.

I ported SHOLIS to SPARK95, and used GNAT/68k to recompile.
At -O0, GNAT produces more code than Alsys, and it's actually
harder to understand, since there are so many redundant loads
and stored littered about the place.  At -O1, the GNAT code
is far smaller and easier reading.  This is no surprise, since
GCC's code selection is table-driven.

Interestingly, we did not do full-scale object-code verification
(OCV) on SHOLIS, owing to the long track-record and stability
of the Alsys compiler.  (well..and the simplicity of SPARK...)

On more recent targets (e.g. PowerPC), it's really important
to have _some_ optimizations on (particularly decent
register allocation) since the difference between
a register, a cache hit, and a main-memory access is so
much more pronounced on these targets.  We tried
running code from VADSCross/PowerPC with -O0 on another project -
the results were disappointing, so we reverted to the _default_
level of -O4 for that compiler, which proved fine (this was also
a SIL4 project.)

High-level optimization that perform large-scale reorganisation
of code are definitely a no-no, but I can live with local improvements.

Overall, I recommend you simply avoid having to do full-on
OCV - it's very hard work!
 - Rod Chapman
   Praxis Critical Systems
   rod@praxis-cs.co.uk




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[Robert Dewar]

In article <wccya74m18e.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> There's no hierarchy of exceptions.

I dislike complexification of exception handling. Many Ada
programmers greatly overuse exceptions, and in particular
define far too many separate exceptions. When it comes to
exception handling, the rule should be keep it very simple.

> (On the other hand, Ada *pretends* that it's OK to raise and
> handle Constraint_Error, but if you read RM-11.6, you'll find
> that's not quite true -- and I doubt if any Ada programmer
> other than Tucker Taft actually *understands* 11.6.  So in
> practise, 11.6 says, "Do not handle predefined exceptions.")

Now now, that's completely disconnected from the real world :-)
"In practice", 11.6 says nothing of the sort at all.

It is often useful to be able to handle constraint error.
For example here is the implementation of one of the plus
operators in Calendar in GNAT:

   function "+" (Left : Time; Right : Duration) return Time is
      pragma Unsuppress (Overflow_Check);
   begin
      return (Left + Time (Right));
   exception
      when Constraint_Error =>
         raise Time_Error;
   end "+";

If you don't understand 11.6, at least don't make claims about
it that are excessive :-) Sure, the formulation of 11.6 is
complex, but you have to approach this with a pragmatist's hat
on, not a theoretician's viewpoint.

In practice many many Ada 95 programs have CE handlers and are
in practice perfectly portable. Even if in some cases a
theoretician could prove that it was possible to have an
implementation of Ada 95 that conformed to the RM under
which the handler is "wrong", that is irrelevant if no such
implementations exist or are likely to exist. In other cases,
even the theoretician's will not find any fault with the CE
handler :-)

Yes, Bob, I know you like to have the hope that the Ada RM is
a formal definition which precisely defines what you can and
cannot do. It is nowhere near that for many reasons, and a
pragmatic viewpoint always has to be in effect.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[Mats Weber]

Robert Dewar wrote:

> I dislike complexification of exception handling. Many Ada
> programmers greatly overuse exceptions, and in particular
> define far too many separate exceptions. When it comes to
> exception handling, the rule should be keep it very simple.

Maybe the ability to pass a paramter when raising an exception would
make programmers define less exceptions ?

Re: Exceptions (was: Help Me Please :)

[Wes Groleau]

Maybe the ability to pass a parameter when raising an exception would
make programmers define less exceptions ?

You mean you wish it were possible to do something like:

  Ada.Exceptions.Raise_Exception
     (E       => Constraint_Error'Identity,
      Message => "Array Index Out Of Bounds" );

??

          
-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: Exceptions (was: Help Me Please :)

[Mats Weber]

Wes Groleau wrote:

> You mean you wish it were possible to do something like:
> 
>   Ada.Exceptions.Raise_Exception
>      (E       => Constraint_Error'Identity,
>       Message => "Array Index Out Of Bounds" );

No. I would like something like this:

http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html#RTFToC99

I do not want a single string parameter, but parameters of types I
choose, and I want the mechanism to be strongly typed.

Re: Help Me Please :)

[Richard D Riehle]

In article <wccya74m18e.fsf@world.std.com>,
	Robert A Duff <bobduff@world.std.com> wrote:

>Mats Weber <matsw@mail.com> writes:
>
>> I think the designers of Modula-3 got it just right. You can have a look
>> at http://www.m3.org/
>
>I beg to differ, again.  ;-)
>
>I see several problems with Modula-3's exception mechanism, some of
>which are shared by Ada.  (My knowledge of the language comes from
>Harbison's book, "Modula-3".  I've never written a Modula-3 program.)

I agree with you about the Modula-3 problems.  Do not entirely agree with
you about Ada.  There could be some benefits to the paramterized 
exception, but these would be small and are already adequately covered
by the features of Ada.Exceptions.   Dr. Dewar and I do not usually
agree on the benefits of the functions in Ada.Exceptions, but we do
agree that exceptions are overused in most applications.

>There's no hierarchy of exceptions.  This means that the designer of
>some code that raises exceptions must decide on the granularity of
>exception handling; it would be better for the handler to make that
>decision.  For example, one handler might want to handle all "I/O
>errors", whereas another handler might want to handle just "disk-full
>error".  Making exceptions first-class objects (which they are not, in
>Ada and Modula-3) would solve this problem, at no cost in language
>complexity.

There would certainly be an increase in complexity in the creation
of hierarchical exceptions.  

>An exception takes just one parameter.  Why not two or three or however
>many I like?  Again, making exceptions extensible object types would
>solve the problem.

And what would be the parameter type(s)?  Are you suggesting an
exception defined with parameters in the same way one defines 
subprograms?  That would seem to increase complexity of both the
compiler design and the resulting applications.  It is an increase
in complexity that seems unnecessary under any but the most unusual
circumstances.    

>The behavior in the presense of "checked run-time errors" (things like
>divide by zero, arithmetic overflow, array index out of bounds) is not
>defined by the language.  So an array index out of bounds might raise
>Array_Index_Error on one implementation, and Constraint_Error on another
>implementation, and simply stop the program dead in its tracks on a
>third implementation.  I don't like that non-portability.

I agree it is useful to track such things.  That is why I like the
addition of Exception_Occurrence to the language in Ada.Exceptions.

      when Some_Nasty_Error : Constraint_Error =>
        Error_Manager.Log(Ada.Exceptions.
                         Exception_Information(Some_Nasty_Error));

This is where Dr. Dewar and I differ.  I see this feature as important
for applications such as command and control systems.  He sees it, as
of our last discussion of the subject, as less important than I.

>(On the other hand, Ada *pretends* that it's OK to raise and handle
>Constraint_Error, but if you read RM-11.6, you'll find that's not quite
>true -- and I doubt if any Ada programmer other than Tucker Taft
>actually *understands* 11.6.  So in practise, 11.6 says, "Do not handle
>predefined exceptions.")

ALRM 11.6 rarely presents a problem to the applications programmer. It
behaves according to a set of rules that has no deleterious effect on
the underlying application.  It is, as I read it, as set of permissions,
not a license to destroy source code intent.

>The "raises set" of a procedure defines what exceptions it can raise.
>The problem is that this rule is checked at run time.  Java is closer to
>the right solution -- it checks that rule at compile time.  However,
>Java suffers from the "cry wolf" problem.  I think it's possible to
>avoid the "cry wolf" problem, and still do most of that checking at
>compile time.

The entire C-family of languages, especially C++, is somewhat problematic
when examining exception handling.  This is another of the "devil is in 
the details" issues.  I don't think Java exception handling measures
up in those circumstances that Ada does well.  Ada is simpler to 
understand and probably a little more efficient.  Also, Java exception
handling seems to lead people to depend too much on exception handling
when they ought to be writing programs to check conditions instead. Ada
95 has added the 'Valid attribute for such checking and it can be used
nicely in circumstances where one might otherwise raise an exception.

I am reminded of C.A.R. Hoare's Turing Award Lecture in which he criticized
Ada for having exception as part of the language.  Now every language
has some kind of exception handling.  Ada looks downright conservative
when compared to more recent offerings for exception management.

>There is no re-raise statement (spelled "raise;" in Ada), so a "when
>others" handler (Ada spelling again) can't propagate the same exception.
>You can't raise the same exception occurrence, because the thing
>available in the handler is not the occurrence, but just its parameter,
>and then only if you named a particular exception.

A Reraise_Occurrence is included in Ada.Exceptions.  It is not very
difficult to invoke this routine when one declares a limited type of
Exception_Occurrence and attaches it to some Exception_ID.  In fact,
one may save an Exception_Occurrence and raise it again at some other
point in the program.  


>Return and exit statements are defined in terms of raising a RETURN or
>EXIT exception.  That seems kludgy to me, because exceptions are for
>cases where the target of the jump is determined dynamically, whereas
>return and exit are jumping to a statically-known place.  So it's sort
>of overkill.  In practical terms, it means that a "when others" will
>handle a RETURN or EXIT, and you can't re-raise it, so the return
>doesn't actually return, and the exit doesn't actually exit the loop.

As mentioned above, it is possible to save and Exception_Occurrence
and ReRaise it.  As to return types, it is also useful to use a 'Base
value for certain return types and check those on return.  Of course,
you know this feature better than I.  You also understand the 
excellent arguments against doing it this way.

>All exceptions must be declared at top level.  This solves the
>kludginess of Ada, where they can be declared anywhere, but act *as if*
>they were declared at top level.  But I think there are better solutions
>to that problem, based on the "procedure declares what exceptions it can
>raise" idea of Modula-3, Java, etc.

Agree that exceptions should be declared at a very high ("top") level.
This is done quite nicely using child library units where the top level
of a hierarchy is the declaration of the exceptions one will use
throughout that hierarchy.  In this case, they are also in scope for 
any clients.   

>There's nothing like Eiffel's preconditions, postconditions, and
>invariants, which tie exceptions to the conditions that cause them.  In
>Modula-3, you can say "this thing might raise Stack_Full", whereas in
>Eiffel you can say, "this thing will raise Stack_Full if Full(S) is
>True."

No argument with your ideas about Eiffel.  I would like to have some
model for pre-, post-, and invariants in the next version of Ada.  At
that time, it would be appropriate to revisit some of the capabilities
of exception handling.  

That being said, as you know, most safety-critical software will avoid
exceptions entirely.  Another reason why the new 'Valid attribute is
becoming useful.  

>So, I think CLOS, Clu, and Eiffel (and to some small extent, C++) all
>have better ideas about exceptions than Modula-3 (or Ada).

Agree about Eiffel.  Not sure about CLOS or Clu.  Definitely disagree
about C++.  The exception handling in C++ can only be described as scary.

Richard Riehle
 

Re: Help Me Please :)

[Robert Dewar]

In article <8brm79$jm3$1@slb6.atl.mindspring.net>,
  Richard D Riehle <laoXhai@ix.netcom.com> wrote:
> I agree it is useful to track such things.  That is why I like
> the addition of Exception_Occurrence to the language in
> Ada.Exceptions.
>
>       when Some_Nasty_Error : Constraint_Error =>
>         Error_Manager.Log(Ada.Exceptions.
>           Exception_Information(Some_Nasty_Error));
>
> This is where Dr. Dewar and I differ.  I see this feature as
> important for applications such as command and control
> systems.  He sees it, as of our last discussion of the
> subject, as less important than I.

Well I am not quite sure what the disagreement is, but let
me make a couple of comments on the above code.

It is highly implementation dependent, on some implementations
it may give a useful symbolic traceback, on another, no output
at all, and on a third, may generate a complete core dump. The
output is "implementation defined", which means you know
absolutely nothing about what the above code does from a
portable point of view.

On a given compiler it may do something useful to you, but you
have to examine any such logging code wrt the implementation
you are using, and adjust the code accordingly. But in practice
most Ada 83 implementations provided facilities like this in
any case (actually many Ada 83 implementations provided much
more extensive capabilities, and the Ada 95 facilities are not
sufficient, we have had to add quite a bit to GNAT here, see
for example, GNAT.Exceptions.

Also, you hope that compilers have extended capabilities like
dumping the results of an exception EVEN if there are dependent
tasks that prevent propagation. Or dump exceptions that
otherwise terminate tasks silently.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[Richard D Riehle]

In article <8brs96$ikp$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:

>In article <8brm79$jm3$1@slb6.atl.mindspring.net>,
>  Richard D Riehle <laoXhai@ix.netcom.com> wrote:
>> I agree it is useful to track such things.  That is why I like
>> the addition of Exception_Occurrence to the language in
>> Ada.Exceptions.
>>
>>       when Some_Nasty_Error : Constraint_Error =>
>>         Error_Manager.Log(Ada.Exceptions.
>>           Exception_Information(Some_Nasty_Error));
>>
>> This is where Dr. Dewar and I differ.  I see this feature as
>> important for applications such as command and control
>> systems.  He sees it, as of our last discussion of the
>> subject, as less important than I.
>
>Well I am not quite sure what the disagreement is, but let
>me make a couple of comments on the above code.

You and I have had a discussion about this and we see its value
for applications a little differently, as reflected in your
note, below.

>It is highly implementation dependent, on some implementations
>it may give a useful symbolic traceback, on another, no output
>at all, and on a third, may generate a complete core dump. The
>output is "implementation defined", which means you know
>absolutely nothing about what the above code does from a
>portable point of view.

It is certainly implementation dependent.  It is also not very useful
for for what Joyce Tokar calls, "deeply embedded" software since we
do not want to be passing strings all over the place.  

That being said, if Exceptions.Exception_Information does return
useful information for a given compiler when used in something such
as a command and control application, this could be a nice feature
of the implementation.  

>On a given compiler it may do something useful to you, but you
>have to examine any such logging code wrt the implementation
>you are using, and adjust the code accordingly. But in practice
>most Ada 83 implementations provided facilities like this in
>any case (actually many Ada 83 implementations provided much
>more extensive capabilities, and the Ada 95 facilities are not
>sufficient, we have had to add quite a bit to GNAT here, see
>for example, GNAT.Exceptions.

Certainly one has the issue of implementation dependency.  However,
I am not sure I like the idea of parameterizing the exception itself.
I do like the Ada 95 addition of, optionally, adding an exception
occurrence for certain exceptions.  Also, we can provide a parameter
in the form of a message for given exceptions.  That allows us to
call the Exception_Message function where this is deemed useful.
That feature is not implementation dependent since we raise the
exception with a clear message.

A when others becomes problematic.  That is one place where the 
exception occurrence becomes important.  Of course we can either
Raise a new exception at the place of a _when others_ or label
it with an exception occurrence.  In either case, we have preserved
the efficiency of the exception model while allowing some kind
of parameter or access to other useful information.

>Also, you hope that compilers have extended capabilities like
>dumping the results of an exception EVEN if there are dependent
>tasks that prevent propagation. Or dump exceptions that
>otherwise terminate tasks silently.

Well, yes, that would be nice.  On the other hand, if we can target
our exception messages with message parameters,  these can be quite
useful as part of the overall design.  Also, the string message could
be designed to permit conversion to some other data type using the
features of Ada.Text_IO.  This is up to the designer, but it does
imply a fairly high level of flexibility when one really needs this
sort of thing.  In this case, there is no dependency on the underlying
implementation.  We get the general capability of the parameterized
exception when we need it. 

I think the Ada.Exceptions package is greatly underrated by a lot of
people.  As mentioned above, it is not appropriate for every kind of
system, but is quite useful when one applies some creativity to its
usages.  

Richard Riehle 

Re: Help Me Please :)

[Jean-Pierre Rosen]

[long discussions about the value of parameterized exceptions snipped]

My 2 Euro-cents:
Exceptions are a programming tool, not a high level error-handling
mechanism.
In any project, you must define a policy for handling errors. Exceptions are
a powerful tool for unwinding the call stack, and without them, there are
many error handling policies that you could not define. They do NOT free you
from defining the policy for a project!

If you need to store more information when an error occurs, call some Error
procedure, and define it the way you like; there you can store the context
in a global variable, or if you need to make it tasking safe, in a task
attribute.

For those who can read french, there is a chapter in my book detailing these
issues (shameless plug: http://pro.wanadoo.fr/adalog/livrejpr.htm).

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Help Me Please :)

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]


Jean-Pierre Rosen a �crit dans le message <8c20ps$995$1@wanadoo.fr>...
>[long discussions about the value of parameterized exceptions snipped]
>
>For those who can read french, there is a chapter in my book detailing
these
>issues (shameless plug: http://pro.wanadoo.fr/adalog/livrejpr.htm).
>


I would even add that you should learn french to at least be able to read
this book :)

It is definitly a very good one!

Pascal.

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Help Me Please :)

[Mats Weber]

Richard D Riehle wrote:

> And what would be the parameter type(s)?  Are you suggesting an
> exception defined with parameters in the same way one defines
> subprograms?  That would seem to increase complexity of both the
> compiler design and the resulting applications.  It is an increase
> in complexity that seems unnecessary under any but the most unusual
> circumstances.

I think the increase in complexity is already present in Ada.Exceptions.
Implementations have to reserve space for and pass that string around,
so I don't see why one could not pass other types.

I made a proposal for this in my thesis, you can have a look at it at:
http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html#RTFToC99
it's really not that complicated.

Without this mechanism, it is quite hard to interface systems like POSIX
in a clean way, where there is a single exception + an error code. With
parameterized exceptions, it is very easy.

Re: Help Me Please :)

[Richard D Riehle]

In article <38E389D7.5CD82114@mail.com>,
	Mats Weber <matsw@mail.com> wrote:

>I think the increase in complexity is already present in Ada.Exceptions.
>Implementations have to reserve space for and pass that string around,
>so I don't see why one could not pass other types.

As I mentioned in my earlier reply to Robert Dewar, one can Raise
and exception with the procedure in Ada.Exceptions where the string
variable is nothing more than some numeric value(s) in string format.
Strings are rather portable across many different platforms.  These
can be decomposed into their constituent numeric values and used for
communicating with various operating systems.  

>Without this mechanism, it is quite hard to interface systems like POSIX
>in a clean way, where there is a single exception + an error code. With
>parameterized exceptions, it is very easy.

As mentioned above, the Ada.Exceptions.Raise_Exception procedure
allows us to link an exception identity to a message in the form
of a string and Ada.Text_IO allows us to convert that string into
an integer value for those exceptions where that might be appropriate.
This is not implementation dependent and provides the very capability
we are discussing.

Richard Riehle
 

Re: Help Me Please :)

[Wes Groleau]

>       when Some_Nasty_Error : Constraint_Error =>
>         Error_Manager.Log(Ada.Exceptions.
>                          Exception_Information(Some_Nasty_Error));
> 
> This is where Dr. Dewar and I differ.  I see this feature as important
> for applications such as command and control systems.  He sees it, as
> of our last discussion of the subject, as less important than I.

I see it as valuable for debugging when you have a million SLOC 
you didn't write!  Unfortunately, some compiler vendors do not 
see its value and hence take advantage of the laxity of the RM
in that area.

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: Help Me Please :)

[Mats Weber]

Robert A Duff wrote:
> 
> Mats Weber <matsw@mail.com> writes:

> > I think the designers of Modula-3 got it just right. 

> I beg to differ, again.  ;-)

I agree with you on most points. What I meant is that the idea of being
able to pass a parameter (even if only one) when raising an exception is
much better than Ada's current approach where the only thing you can
pass is a string.

This would have been a very simple change to the language (almost as
simple as including a string parameter in an exception occurence), and
the mechanism can be used to simulate a hierarchy of exceptions, using a
single exception with a tagged type as a paramter.

Re: Help Me Please :)

[Tucker Taft]

Robert A Duff wrote:
> ... 
> (On the other hand, Ada *pretends* that it's OK to raise and handle
> Constraint_Error, but if you read RM-11.6, you'll find that's not quite
> true -- and I doubt if any Ada programmer other than Tucker Taft
> actually *understands* 11.6.  So in practise, 11.6 says, "Do not handle
> predefined exceptions.")

This sounds like a request for a quick tutorial on 11.6 ;-).
Here is my nickel tour:

  RM95 11.6(5) says, effectively, that you can remove dead code,
  even if it might raise an exception due to failing a language-defined check.

  RM95 11.6(6) says that the compiler (or hardware) can do 
  instruction scheduling (i.e. reordering) even 
  if there are language-defined checks among
  the instructions, meaning that if you handle an exception raised
  by the failure of a language-defined check, it might be "imprecise."
  However, it won't be so imprecise as to disrupt some
  separately compiled "abstraction" in the middle of an
  operation, presuming the check failed outside of the abstraction.

Or for the one-cent summary: dead code removal and instruction
reordering can be performed without worrying too much 
about language-defined checks, so long as you don't use
any "undefined" results (i.e., the result of an operation that failed
a language-defined check) and you don't screw up external
abstractions.

> ...
> - Bob

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Help Me Please :)

[Will Mann]

Can some one help me with my Ada.. my lecturer has given me code that
doesn't work... the compiler says that it can't handle "A".."Z" the
error message is :

 Inappropriate operands for "DOT_DOT" operation, continuing

Thanks

--

:\        /   |   |           ALL DONE BYE BYE!
: \  /\  /  * |   |
:  \/  \/   | |__ |__

Re: Help Me Please :)

[Stanley R. Allen]

Will Mann wrote:
> 
> Can some one help me with my Ada.. my lecturer has given me code that
> doesn't work... the compiler says that it can't handle "A".."Z" the
> error message is :
> 
>  Inappropriate operands for "DOT_DOT" operation, continuing

What hourly rates do you offer?

-- 
Stanley Allen
mailto:Stanley_R_Allen@raytheon.com

Re: Help Me Please :)

[Al Johnston]

> What hourly rates do you offer?

boy... that was not nice...

I am new to this stuff too, and i cant run my compiler and do email at the
same time...
so i am not sure... but those '"' look funny to me.  I beleive double
quotes denote ada
strings, while single quotes refer to characters so you were asking (i
think) ada
to use a RANGE of strings from the string A to the string.  I think it
should be
'A'..'Z'
then again, I said I was new to this stuff... I want my c back!

Re: Help Me Please :)

[Robert Dewar]

In article <38BC7A6E.EC5DE68B@mindspring.com>,
  Al Johnston <sofeise@mindspring.com> wrote:
> I think it should be

> 'A'..'Z'

> then again, I said I was new to this stuff... I want my c
> back!

Well if you are so narrow in your exposure to languages that
you know only C, it will be *really* good experience to learn
another language. Any competent programmer should be able to
acquire the *syntax* of another programming language almost
immediately.

Ironically, this particular point is one where Ada and C are
identical, and if you used "x" instead of 'x' in C you would
get equally mysterious (actually probably more mysterious
messages, something like:

   warning: comparison between pointer and integer

(at least that's what gcc gives for the equivalent C mistake:

   if ("a" <= q && q <= "z") ...







Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[Stanley R. Allen]

Al Johnston wrote:
> 
> > What hourly rates do you offer?
> 
> boy... that was not nice...

Can e-mail & newsgroup humor be dry?

-- 
Stanley Allen
mailto:Stanley_R_Allen@raytheon.com

Re: Help Me Please :)

[Robert Dewar]

In article <38BC7A6E.EC5DE68B@mindspring.com>,
  Al Johnston <sofeise@mindspring.com> wrote:
> I think it should be

> 'A'..'Z'

> then again, I said I was new to this stuff... I want my c
> back!

Well if you are so narrow in your exposure to languages that
you know only C, it will be *really* good experience to learn
another language. Any competent programmer should be able to
acquire the *syntax* of another programming language almost
immediately.

Ironically, this particular point is one where Ada and C are
identical, and if you used "x" instead of 'x' in C you would
get equally mysterious (actually probably more mysterious
messages, something like:

   warning: comparison between pointer and integer

(at least that's what gcc gives for the equivalent C mistake:

   if ("a" <= q && q <= "z") ...







Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help Me Please :)

[Al Johnston]

> Well if you are so narrow in your exposure to languages that
> you know only C, it will be *really* good experience to learn

Well, there he goes again... (g)... but you did post a very helpful
reply to the originator of this thread... so we will think nice thoughts

about you for a while...

My first language was fortran 4. back in 76.  My first love was
pascal (I know you will have fun with that one); I have been doing
c for the last 5 years, although most of my time has been spent
debugging c/ada83 interfaces...  You would think I would like
ada.  I dont.

> another language. Any competent programmer should be able to
> acquire the *syntax* of another programming language almost

Although stated in an unkind way, I have to agree with you.  But
I guess I am just getting old.  I have spent to many hrs in the RM
and cohen's book the last two weeks for it to be laziness.

> Ironically, this particular point is one where Ada and C are
> identical, and if you used "x" instead of 'x' in C you would

Very ironic.  I did not catch this... at first glance I thought
it would work okay... but i didn't pay enough attention...

Re: Help Me Please :)

[tmoran]

In <38BC7A6E.EC5DE68B@mindspring.com> Al Johnston said:
>to use a RANGE of strings from the string A to the string.  I think it
>should be
>'A'..'Z'
  Correct.

>then again, I said I was new to this stuff... I want my c back!
Would you really prefer a language in which
  for(i="A";i<"Z";i++)printf("%c",i);
is not caught at compile time, but instead gives you exciting debugging
opportunities?  ;)

Re: Help Me Please :)

[Al Johnston]

> Would you really prefer a language in which
>   for(i="A";i<"Z";i++)printf("%c",i);
> is not caught at compile time, but instead gives you exciting debugging
> opportunities?  ;)

Hey, its call job security!  And yes I would... I am a libertarian... or
maybe
that should be sadist... I get those confused. (g)

Re: Help Me Please :)

[Aidan Skinner]

tmoran@bix.com writes:

> Would you really prefer a language in which
>   for(i="A";i<"Z";i++)printf("%c",i);
> is not caught at compile time, but instead gives you exciting debugging
> opportunities?  ;)

#define EVIL 1;
#define NOT_EVIL 0;

C int;

if (C = EVIL) {
 printf ("C is Evil");
}
else {
 printf ("C isn't Evil");
}

- Aidan
-- 
http://www.skinner.demon.co.uk/aidan/
Currently looking for work: CV available on request.

Re: Help Me Please :)

[tmoran]

> doesn't work... the compiler says that it can't handle "A".."Z" the
The doublequote " is for a string, use the singlequote ' for a
character.  ie   'A' .. 'Z'

> my lecturer has given me code that doesn't work
  Perhaps you should help him - after taking Stanley Allen's advice to ask
"What hourly rates do you offer?"

Re: Help Me Please :)

[James Bean]

Will Mann wrote:
> 
> Can some one help me with my Ada.. my lecturer has given me code that
> doesn't work... the compiler says that it can't handle "A".."Z" the
> error message is :
> 
>  Inappropriate operands for "DOT_DOT" operation, continuing
> 
> Thanks
> 
> --
> 
> :\        /   |   |           ALL DONE BYE BYE!
> : \  /\  /  * |   |
> :  \/  \/   | |__ |__

"A" is a sring. 'A' is a character. Dot_dot's can't separate strings.

Jim Bean

Re: help me please!

[Ken Garlington]

[cross-posted to comp.lang.ada]

"Emmanuel Gustin" <Emmanuel.Gustin@skynet.be> wrote in message
news:9gb1uu$87u7o$1@ID-52877.news.dfncis.de...

: "Jamal Bengeloun" <jakb@caramail.com> wrote in message
: news:df481109.0106140310.5d923746@posting.google.com...
:
: > I am doing a graduate end of term research on the use of java in
: > avionics systems, on the certification issues regarding those systems
: > and finally on the viability of java in avionics (well why not Ada by
: > the way? From what I've read here java is regarded as cooler, but is
: > it safe?).

First, on the current use of Java in avionics: I haven't personally seen any
"safety-critical" (Level A, or SIL 4  if you prefer) real-time embedded
avionics projects announced to date that use the Java language. I suspect
this is due to a combination of issues: the complexity of certifying the
system (including the JVM), the potential impact of garbage collection on
run-time schedulability analysis, efficiency issues, and availability on
certain platforms. However, particularly since not all avionics applications
are necessarily safety-critical, this doesn't rule out Java implementations
for lower criticality levels.

With respect to certification issues, it depends on the certification
scheme. Trying to certify a Java implementation against MoD 00-55, for
example, would probably be much more difficult than with DO-178, which in
turn would be probably more difficult than MIL-STD-882 (although in
practice, it also depends a lot on the specific people granting the
certification). Part of the problem is defining what is really meant by a
"Java" implementation. If you're referring to Java targeted to the JVM,
that's going to be significantly more difficult than Java compiled as
"native" code. Conversely, using Ada as the source language, but with JVM as
the target (such compilers do exist), might also be easier than Java + JVM.
Again, it depends upon the certification criteria. For the sake of
discussion, let's assume we're taking about a "traditional" Java
implementation using a JVM, certified along the lines described in DO-178. I
would suspect the only way this could be certified is through the use of
some (probably all) of the following approaches:

-- The Java/JVM vendor would need to provide sufficient data to certify both
the Java toolset and the JVM implementation, including configuration
management and verification records. For a Level A implementation, this
would be significantly more information than you would normally expect a
commercial vendor to generate, although some embedded OS vendors (Aonix,
WindRiver, etc.) have such packages. As others have noted, the license
agreements normally included with Java products don't encourage me that many
Java vendors are working on this, but it's possible.

- The avionics developer (or a third party) would have to generate a
sufficiently robust verification scheme for both the toolset and JVM to
independently show that both components are acceptable when integrated into
the total system. AFAIK, RTCA has not yet bought off on the idea of
independently certifying individual software components, so such integrated
proof would be important.

- Some use of product service history (i.e., the lack of defects
attributable to the toolset/JVM when used in other applications) could be
helpful; however, RTCA's position as I understand it places a number of
limitations on how much faith can be placed on past experience. (Some DERs,
on the other hand, seem to put a lot of faith in it.)

Bottom line? I wouldn't want to be the first guy to go through this process.
However, it might be technically feasible. It wouldn't seem to be
economically desirable vs. other languages at this time, though.

In terms of the general viability/safety of Java (and Ada) vs. C++, a recent
column by Peter Coffee may be of some interest:

http://www.zdnet.com/eweek/stories/general/0,11011,2769111,00.html

I don't know if anyone has generated a specific guide for application of
Java to safety-critical systems, as exists for C and Ada. I'd be surprised
if one exists. One brief analysis is available at

http://www.adaic.com/docs/reports/lawlis/p.htm

It appears that the J Consortium's High Integrity Profile Task Group is
working on a better analysis; more information is available at
http://www.j-consortium.org and
http://www.aonix.com/content/news/pr_9.28.99_2.html. There's a presentation
on the first site that outlines some of the issues.

Moving on to the side-issue of Ada:

: Ada is widely regarded as a language designed by a committee,
: on a par with FORTRAN-99, and handicapped by an excessive
: number of features. I don't know; I never used it.

As someone who _has_ actually used Ada in avionics applications (unlike Mr.
Gustin, who was honest about his own lack of experience, and Mr. Tarver, who
failed to note that he is unqualified to give an educated opinion), I
believe this is an extremely inaccurate characterization of Ada. It
continues to be used in a number of areas, e.g. for MoD 00-55 SIL 4
applications. There are non-technical factors that adversely affect its use,
particularly in the U.S. marketplace. See the National Academy of Sciences
study "Ada and Beyond: Software Policies for the Department of Defense,"
available at http://www.nap.edu/catalog/5463.html for more information on
this subject. General information on Ada is available at
http://www.acm.org/sigada and other sources.

Re: help me please!

[C.D.Damron]

Wow, thanks for such an effort!
Ken Garlington wrote in message <3ezX6.311

Re: help me please!

[John Keeney]

Ken Garlington <Ken.Garlington@computer.org> wrote in message
news:3ezX6.311$kV6.181850212@newssvr17.news.prodigy.com...
> [cross-posted to comp.lang.ada]
>
> "Emmanuel Gustin" <Emmanuel.Gustin@skynet.be> wrote in message
> : Ada is widely regarded as a language designed by a committee,
> : on a par with FORTRAN-99, and handicapped by an excessive
> : number of features. I don't know; I never used it.
>
> As someone who _has_ actually used Ada in avionics applications (unlike
Mr.
> Gustin, who was honest about his own lack of experience, and Mr. Tarver,
who
> failed to note that he is unqualified to give an educated opinion), I
> believe this is an extremely inaccurate characterization of Ada. It
> continues to be used in a number of areas, e.g. for MoD 00-55 SIL 4
> applications. There are non-technical factors that adversely affect its
use,
> particularly in the U.S. marketplace. See the National Academy of Sciences
> study "Ada and Beyond: Software Policies for the Department of Defense,"
> available at http://www.nap.edu/catalog/5463.html for more information on
> this subject. General information on Ada is available at
> http://www.acm.org/sigada and other sources.

While I've never "used" Ada I did attend a class (while teaching others)
where it and C++ were two of the four languages "introduced" during
the semester.
While I was already an active C programmer I found Ada much more
to my liking than C++. Ada was coherent while C++ -in trying to be an
advanced C- lost C's wonderfull one man design singularity of style.
C++ seems to me to be well on its way to joining the Lots of Insidiously
Stupid Parenthesis crowd of computer languages.