Ada exception block does NOT work?

Ada exception block does NOT work?

[bubble]

dear All:

I am writing some application about stock trade.
my program will fetch data from database and start some work.
in a extreame case.my program crash.
I feel very strange, and write a test code to test.
I found Ada can not re-enter the exception block twice.(oh! my god)
It should be work.


of course!,I could do some check before really job.
I just want to know what cause the exception problem.


my test evnironment is win2k and win xp.
they are not work well.
I have try those compiler:
Gnat 3.15 p / mingw 3.42 / mingw 4.1

does any one have idea to fix the exception block problem?
or give me some guide to avoid the problem?
thanks.

--the test code is
With Ada.Text_Io;
Procedure Trading Is
   Type Price Is Delta 0.01 Digits 18;
   Type PriceArray Is Array (Positive Range <>) Of price;
   Procedure Avg (Data : In PriceArray) Is
      Avg, Sum : Price'Base := 0.0;
   Begin
      Ada.Text_Io.Put ("average:"   );
      For Index In Data'Range Loop
         Sum := Sum + Data (Index);
      End Loop;
      Avg := Sum / Data'Length;
      Ada.Text_Io.Put (Price'Image (Avg));
      Ada.Text_Io.New_Line;
   Exception
      When Others =>
         Ada.Text_Io.Put_Line ("error here!");
   End;
Begin
   For Index In Reverse 0 .. 9 Loop
      For Step In 1 .. 3 Loop
         Declare
            Mydata : Pricearray (1 .. Index) :=  (Others => 10.0);
         Begin
            Avg (Mydata);
         End;
      End Loop;
   End Loop;
end Trading;
----end the test code 

Re: Ada exception block does NOT work?

[Georg Bauhaus]

bubble wrote:

> I found Ada can not re-enter the exception block twice.(oh! my god)
> It should be work.

It does :-). Reentering means to loop, so you could write,
in your procedure's body

   loop
      begin
         some_computation(data);
         exit retrying;
      exception
         when Some_Exception =>
            report;
            make_adjustments;
      end;
   end loop;

or

   retry: loop
      begin
         some_computation(data);
         exit retry;
      exception
         when Some_Exception =>
            report;
            make_adjustments;
      end;
   end loop retry;

Re: Ada exception block does NOT work?

[bubble]

dear Georg:
thank to your reply so quickly.
and the problem still not be sloved.

you can test "test code".
you will find some thing interesting.


the statement ,  Avg := Sum / Data'Length;
should be throw a exception signal when Data'length is 0 (empty array)
and then the exception block handler should catch the signal, and do some 
recovery process.

in the test case, it doesn't work
in first exceptin case, Ada throw a exception and transfer the control to 
exception handler (greater).
in 2nd exception case,Ada "should" throw exception and do control transfer.
Unfortunately, it does not do.



> bubble wrote:
>
>> I found Ada can not re-enter the exception block twice.(oh! my god)
>> It should be work.
>
> It does :-). Reentering means to loop, so you could write,
> in your procedure's body
>
>   loop
>      begin
>         some_computation(data);
>         exit retrying;
>      exception
>         when Some_Exception =>
>            report;
>            make_adjustments;
>      end;
>   end loop;
>
> or
>
>   retry: loop
>      begin
>         some_computation(data);
>         exit retry;
>      exception
>         when Some_Exception =>
>            report;
>            make_adjustments;
>      end;
>   end loop retry; 

Re: Ada exception block does NOT work?

[gautier_niouzes]

It looks like a GNAT bug:
1st time with denominator 0 the division raises an exception, 2nd times
it
seems to enter an infinite loop. See the enhanced test.
Did you try with ObjectAda (you can download it). Good (too) for
cross-testing.
HTH
About stocks: here a series of Ada-generated Web pages :-)
---> http://homepage.sunrise.ch/mysunrise/gdm/ind1dlog.htm
______________________________________________________________
Gautier     --     http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

--the test code is
with Ada.Text_Io;
procedure Trading is
  type Price is delta 0.01 digits 18;
  type Pricearray is array (Positive range <>) of Price;
  procedure Avg (Data : in Pricearray) is
    Avg, Sum : Price'Base := 0.0;
  begin
    Ada.Text_Io.Put ("average:"   );
    for Index in Data'Range loop
      Sum := Sum + Data (Index);
    end loop;
    Ada.Text_Io.Put("#a");
    Avg := Sum / Data'Length; -- <- blocking there on the 2nd try with
denominator 0
    Ada.Text_Io.Put("#b");
    Ada.Text_Io.Put (Price'Image (Avg));
    Ada.Text_Io.New_Line;
  exception
    when others =>
      Ada.Text_Io.Put_Line ("error here!");
  end;
begin
  for Index in reverse 0 .. 9 loop
    Ada.Text_Io.Put_Line ("Main index " & Natural'Image (Index));
    for Step in 1 .. 3 loop
      Ada.Text_Io.Put_Line ("Step " & Natural'Image (Step));
      declare
        Mydata : Pricearray (1 .. Index) :=  (others => 10.0);
      begin
        Avg (Mydata);
      end;
    end loop;
  end loop;
end Trading;
----end the test code

Re: Ada exception block does NOT work?

[Georg Bauhaus]

bubble wrote:
> dear Georg:
> thank to your reply so quickly.
> and the problem still not be sloved.

right, no wonder, I have missed the point.
 
> you can test "test code".
> you will find some thing interesting.

This looks like a bug really.
It goes away in Gautier's programme when you change one line
of the reversed for loop to read:

  for Index in reverse 10 .. 19 loop

(Not that this helps.)
Can you send a bug report to GCC's bugzilla?


-- Georg 

Re: Ada exception block does NOT work?

[Frank J. Lhota]

I tried this program with ObjectAda, and found that ObjectAda did not 
have this problem.

I also tried the following variant of this program, where I replaced all 
of the fixed decimal arithmetic with integer arithmetic. This version 
does compile and execute properly, so it appears that the problem is 
related to how GNAT handles fixed point arithmetic errors.

--the test code is
with Ada.Text_Io;
procedure Trading is
   type Price is range -16#8000_0000# .. 16#7FFF_FFFF#;
   type Pricearray is array (Positive range <>) of Price;
   procedure Avg (Data : in Pricearray) is
     Avg, Sum : Price'Base := 0;
   begin
     Ada.Text_Io.Put ("average:"   );
     for Index in Data'Range loop
       Sum := Sum + Data (Index);
     end loop;
     Ada.Text_Io.Put("#a");
     Avg := Sum / Data'Length; -- <- blocking there on the 2nd try with 
denominator 0
     Ada.Text_Io.Put("#b");
     Ada.Text_Io.Put (Price'Image (Avg));
     Ada.Text_Io.New_Line;
   exception
     when others =>
       Ada.Text_Io.Put_Line ("error here!");
   end;
begin
   for Index in reverse 0 .. 9 loop
     Ada.Text_Io.Put_Line ("Main index " & Natural'Image (Index));
     for Step in 1 .. 3 loop
       Ada.Text_Io.Put_Line ("Step " & Natural'Image (Step));
       declare
         Mydata : Pricearray (1 .. Index) :=  (others => 10);
       begin
         Avg (Mydata);
       end;
     end loop;
   end loop;
end Trading;
----end the test code


-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Ada exception block does NOT work?

[Svesse]

Tried both of the programs with GCC 4.0.1 and they
compiled and executed fine.

-- Svesse

Re: Ada exception block does NOT work?

[Björn Persson]

Georg Bauhaus wrote:

> It goes away in Gautier's programme when you change one line
> of the reversed for loop to read:
> 
>   for Index in reverse 10 .. 19 loop

Of course, because then the division by zero never happens.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Ada exception block does NOT work?

[Björn Persson]

Svesse wrote:
> Tried both of the programs with GCC 4.0.1 and they
> compiled and executed fine.

Confirmed. GCC 4.0.1 for GNU/Linux does not have this bug. I tested it 
on Fedora Core 4. Svesse, your user agent string says you're running 
Windows. Did you test this on Windows?

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada exception block does NOT work?

[Svesse]

No I tested it on GNU/Linux, forgot to mention that..
Bj�rn Persson wrote:
> Svesse wrote:
> 
>> Tried both of the programs with GCC 4.0.1 and they
>> compiled and executed fine.
> 
> 
> Confirmed. GCC 4.0.1 for GNU/Linux does not have this bug. I tested it
> on Fedora Core 4. Svesse, your user agent string says you're running
> Windows. Did you test this on Windows?
> 

Re: Ada exception block does NOT work?

[Frank J. Lhota]

Svesse wrote:
> Tried both of the programs with GCC 4.0.1 and they
> compiled and executed fine.
> 
> -- Svesse

I should have specified that I used the Cygwin version of gcc, version 
3.4.4-1. Apparently the problem has been fixed in later versions.

If only I could convince my clients to migrate to Linux, I could upgrade 
the version of gcc that I use :(.

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Ada exception block does NOT work?

[Georg Bauhaus]

Björn Persson wrote:
> Georg Bauhaus wrote:
> 
> 
>>It goes away
> 
> 
> Of course, because then the division by zero never happens.

ouch  >-/

Re: Ada exception block does NOT work?

[Jeffrey R. Carter]

bubble wrote:
> 
> the statement ,  Avg := Sum / Data'Length;
> should be throw a exception signal when Data'length is 0 (empty array)
> and then the exception block handler should catch the signal, and do some 
> recovery process.

In Ada, exceptions are raised and handled, not thrown and caught. 
They're also better integrated into the language than in the languages 
that throw and catch them; there are no "try" statements in Ada.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63

Re: Ada exception block does NOT work?

[Maciej Sobczak]

Jeffrey R. Carter wrote:

> In Ada, exceptions are raised and handled, not thrown and caught.

Interesting distinction. Would you please elaborate a little bit?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Ada exception block does NOT work?

[Ludovic Brenta]

I tried to reduce the test case, but it works for me; the exception is
raised and handled as many times as I want, and there is no infinite
loop.

with Ada.Exceptions;
with Ada.Text_IO;
procedure G is
   type T is delta 0.01 digits 18;
   type T_Array is array (Positive range <>) of T;
   procedure P (N : in T_Array) is
      A : T'Base;
   begin
      A := 10.0 / N'Length;
   exception
      when E: others =>
         Ada.Text_IO.Put_Line ("Exception handled");
         Ada.Text_IO.Put_Line (Ada.Exceptions.Exception_Information (E));
   end P;
begin
   P ((1 .. 0 => 10.0));
   P ((1 .. 0 => 10.0));
end G;


$ gnatmake -g -gnatafno -gnatVa g -bargs -E
cd /home/lbrenta/src/ada/
gnatmake -g -gnatafno -gnatVa trading -bargs -E
gnatgcc -c -g -gnatafno -gnatVa trading.adb
gnatbind -aO./ -E -I- -x trading.ali
gnatlink -g trading.ali

Compilation finished at Wed Aug 17 12:42:11

$ ./g
Exception handled
Exception name: CONSTRAINT_ERROR
Message: SIGFPE

Exception handled
Exception name: CONSTRAINT_ERROR
Message: SIGFPE

Gautier's sample also shows no problem for me, the exception is indeed
raised and handled three times, and there is no infinite loop.  I used
the same compiler options for both test cases.

This is (you guessed it) on Debian GNU/Linux with gnat 3.15p-14; but
as far back as 3.15p-7 it still works.  I even tried AdaCore's binary
distribution of GNAT, and it still works, even without any options.

-- 
Ludovic Brenta.

Re: Ada exception block does NOT work?

[Anders Wirzenius]

Ludovic Brenta <ludovic.brenta@tiscali.be> writes:

> I tried to reduce the test case, but it works for me; the exception is
> raised and handled as many times as I want, and there is no infinite
> loop.
> 

I modified Ludovic's example to use attributes:

with Ada.Exceptions;
with Ada.Text_IO;
procedure G is
   type T is delta 0.01 digits 18;
   --  type T is new Integer range 1..10;

   type T_Array is array (Positive range <>) of T;
   procedure P (N : in T_Array) is
      A : T'Base;
   begin
      A := T (10) / N'Length;
      Ada.Text_IO.Put_Line ("no problem: " & T'Base'Image (A));
   exception
      when E: others =>
         Ada.Text_IO.Put_Line ("Exception handled");
         Ada.Text_IO.Put_Line (Ada.Exceptions.Exception_Information (E));
   end P;
begin
   P ((1 .. 3 => T (10)));
   P ((1 .. 0 => T (10)));
   P ((1 .. 0 => T (10)));
end G;

... and got on a Cygwin/Windows XP:

$ gnat
GNAT 3.15p  (20020523) Copyright 1996-2002 Free Software Foundation, Inc.

List of available commands

GNAT BIND               gnatbind
GNAT CHOP               gnatchop
GNAT COMPILE            gnatmake -f -u
GNAT ELIM               gnatelim
GNAT FIND               gnatfind
GNAT KRUNCH             gnatkr
GNAT LINK               gnatlink
GNAT LIST               gnatls
GNAT MAKE               gnatmake
GNAT NAME               gnatname
GNAT PREPROCESS         gnatprep
GNAT STANDARD           gnatpsta
GNAT STUB               gnatstub
GNAT XREF               gnatxref

Commands FIND, LIST and XREF accept project file switches -vPx, -Pprj and -Xnam=val


AWI003@fiw9430 /cygdrive/c/a/ada/investigate/trading
$ gnatmake g
gcc -c g.adb
gnatbind -x g.ali
gnatlink g.ali

AWI003@fiw9430 /cygdrive/c/a/ada/investigate/trading
$ ./g.exe
no problem:  3.33
Exception handled
Exception name: CONSTRAINT_ERROR
Message: EXCEPTION_INT_DIVIDE_BY_ZERO

... stopped using ctrl-C

AWI003@fiw9430 /cygdrive/c/a/ada/investigate/trading
$

-- 
Anders

Re: Ada exception block does NOT work?

[Björn Persson]

This is starting to look very much like a Windows-specific bug.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada exception block does NOT work?

[Randy Brukardt]

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

"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
news:42LMe.31725$d5.185379@newsb.telia.net...
> This is starting to look very much like a Windows-specific bug.

That wouldn't surprise me. Integer divide-by-zero is a hardware trap on the
x86 (unlike overflow and the floating point cases), so its very OS-specific
as to how it is handled. So a bug in the handling on one target is unlikely
to be repeated in other targets - the code is likely to be very different.

In this specific case, Windows presents Integer divide-by-zero as a Windows
exception (which probably isn't the same as an Ada exception). OTOH,
Unix-like systems usually present this as a signal. So the code involved is
going to be different. From the looks of it, there was a problem in
resetting the handler after the first exception was detected. As I recall,
there was something tricky about getting that to work (but I don't remember
the details).

                                   Randy.

Re: Ada exception block does NOT work?

[Simon Wright]

With GCC 4.0.0 on powerpc-apple-darwin7.9.0, this outputs

...
average: 10.00
average: 10.00
average: 10.00
average: 0.00
average: 0.00
average: 0.00
$ 

which is of course a different bug!

Re: Ada exception block does NOT work?

[Jeffrey R. Carter]

Maciej Sobczak wrote:

> Jeffrey R. Carter wrote:
> 
>> In Ada, exceptions are raised and handled, not thrown and caught.
> 
> Interesting distinction. Would you please elaborate a little bit?

Ada has had exceptions, well integrated with the rest of the language, 
since Ada 80. Ada's terminology is that exceptions are raised and 
handled. If you use other terminology in an Ada context, you run the 
risk of "failure to communicate". The throw/catch/try kludge came when 
exceptions were grafted onto C++, which did not originally have them (or 
several other Ada features later grafted on) in 1982.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

Re: Ada exception block does NOT work?

[Maciej Sobczak]

Jeffrey R. Carter wrote:

> Ada has had exceptions, well integrated with the rest of the language, 
> since Ada 80. Ada's terminology is that exceptions are raised and 
> handled.

OK, but the question is not about terminology, really.

If you claim that exceptions were "patched" on to the C++ language that 
did not have them originally, then let's switch the context to other 
language that has no history issue like this.

I don't know the full history of Java, but I suppose that it had 
exceptions from the very beginning. If not, let's take C#. Whether those 
languages tried to mimic the syntax from C++ does not matter at all when 
it comes to discussion how well the mechanism is integrated into the 
language.

Why do you claim that Ada's exceptions are "better integrated into the 
language than in the languages that throw and catch them"?

Note that those other languages can throw regular objects as exceptions, 
thus enabling polymorphism when they are handled. One could say that 
*this* is the point of good integration and that Ada's exceptions are a 
conceptual patch that did not integrate with the rest of the object 
model, leading to two separate spaces of language entities instead of 
only one.

Note that I'm learning Ada and I'm likely to misunderstand things. But 
I'm curious about your way of reasoning and I want to better understand 
the differences between languages (and that's why I'm provoking you with 
the above inverted claim ;) ).


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Ada exception block does NOT work?

[Jean-Pierre Rosen]

Maciej Sobczak a �crit :
> Jeffrey R. Carter wrote:
> 
>> Ada has had exceptions, well integrated with the rest of the language, 
>> since Ada 80. Ada's terminology is that exceptions are raised and 
>> handled.
> 
> 
> OK, but the question is not about terminology, really.
> 
> If you claim that exceptions were "patched" on to the C++ language that 
> did not have them originally, then let's switch the context to other 
> language that has no history issue like this.
There are no predefined exceptions in C++, therefore things like 
arithmetic overflow have undefined semantics, rather than raising an 
exception

[...]
> Why do you claim that Ada's exceptions are "better integrated into the 
> language than in the languages that throw and catch them"?
Every sequence of statements can have an exception handler in Ada, while 
in C++/Java/C# you must add an extra level of nesting. This gives the 
feeling that dealing with exceptions is something you just put in very 
special places, while in Ada you are more inclined to considering 
exceptions everywhere.

> Note that those other languages can throw regular objects as exceptions, 
> thus enabling polymorphism when they are handled. One could say that 
> *this* is the point of good integration and that Ada's exceptions are a 
> conceptual patch that did not integrate with the rest of the object 
> model, leading to two separate spaces of language entities instead of 
> only one.
This boils down to the (controversial) question of how much information 
should be associated to an exception. It could be the programmer's 
responsibility to store the context when an exception is raised, rather 
than propagating it with the exception. In Ada83, an exception had just 
an identity, and Jean Ichbiah (the father of Ada) claimed that he 
regretted having more than one exception. In Ada95, a string can be 
associated to an exception. In C++, any object can be thrown, while in 
Java only an object belonging to the throwable class. Note also that 
augmenting the quantity of information associated to an exception has a 
performance cost, which may be important for a real-time oriented 
language like Ada. So, you see the question is quite open...

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

Re: Ada exception block does NOT work?

[Maciej Sobczak]

Jean-Pierre Rosen wrote:

> There are no predefined exceptions in C++

There are.
In particular, creating a new object on the free store can result in 
failure due to inability of the system to allocate memory. This is how 
you create new object on the free store:

int *p1 = new int;
MyType *p2 = new MyType();

etc.

In case of memory allocation error, the above will result in the 
std::bad_alloc exception being thrown.
This is predefined and standard exception in C++.

> therefore things like 
> arithmetic overflow have undefined semantics

The "therefore" part above is not correct. Since there *are* predefined 
exceptions in C++, dealing with arithmetic anomalies certainly was based 
on other, unrelated policies.
Whether this is good or bad in any particular context is another issue.


>> Why do you claim that Ada's exceptions are "better integrated into the 
>> language than in the languages that throw and catch them"?
> 
> Every sequence of statements can have an exception handler in Ada, while 
> in C++/Java/C# you must add an extra level of nesting.

You add the nesting if you want to handle the exception. If you don't 
want to handle it, you don't add the nesting. This is rather the result 
of having a *pair* of parentheses to denote a block, with no sensible 
way of extending this punctuation. In Ada, "begin" and "end" are not a 
closed pair and are easier to extend with any other keyword, thus making 
a "comb" of arbitrary length. But this is a syntax issue.

I treat Ada's "begin" as having implicit "try" if there is any handler 
downstream. Is there anything inherently wrong in this?

> This gives the 
> feeling that dealing with exceptions is something you just put in very 
> special places, while in Ada you are more inclined to considering 
> exceptions everywhere.

But then we will drift to discuss whether it makes sense to deal with 
exceptions everywhere or maybe only where the actual handler has 
something to do. I haven't seen enough real Ada code to have any opinion 
what is good in the Ada context.
Don't you do this:

begin
     -- ...
     Some_Procedure_That_Might_Raise;
     -- ...
end;

and just let the exception (if any) travel up the chain to where there 
is enough context to actually *do* somethng with the exception?


>> Note that those other languages can throw regular objects as 
>> exceptions
> 
> This boils down to the (controversial) question of how much information 
> should be associated to an exception.
[...]
> So, you see the question is quite open...

Yes, it is and I understand the concerns you mention. But I'm still not 
sure about the "integration with the language" issue. In what way the 
Ada exceptions are more integrated with the language than the C++ 
exceptions (or take any other language from the "throwing" family)?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Ada exception block does NOT work?

[Alex R. Mosteo]

Jean-Pierre Rosen wrote:
> Maciej Sobczak a �crit :

>> Note that those other languages can throw regular objects as 
>> exceptions, thus enabling polymorphism when they are handled. One 
>> could say that *this* is the point of good integration and that Ada's 
>> exceptions are a conceptual patch that did not integrate with the rest 
>> of the object model, leading to two separate spaces of language 
>> entities instead of only one.
> 
> This boils down to the (controversial) question of how much information 
> should be associated to an exception. It could be the programmer's 
> responsibility to store the context when an exception is raised, rather 
> than propagating it with the exception. In Ada83, an exception had just 
> an identity, and Jean Ichbiah (the father of Ada) claimed that he 
> regretted having more than one exception. In Ada95, a string can be 
> associated to an exception. In C++, any object can be thrown, while in 
> Java only an object belonging to the throwable class. Note also that 
> augmenting the quantity of information associated to an exception has a 
> performance cost, which may be important for a real-time oriented 
> language like Ada. So, you see the question is quite open...

I think the crux in this last point: you don't want that, once an 
exception is being raised, you fail to propagate it because it can't be 
allocated due to exhausted memory, for example. I suppose this can 
happen in any language which allows propagation of arbitrary objects, 
though I don't have experience in this scenary and its side effects. In 
Ada, one can argue that being the exception a special feature with known 
and limited form, can't have this kind of failure (which is important 
since exceptions are raised mostly when error conditions arise). I see 
in the RM that there's a permission for an implementation to truncate 
the message associated with any exception, could be this the reason?

I suppose this can be mitigated if some "raw" exception is always 
propagable when everything else fails. In that case, failing to allocate 
the proper exception could raise this "raw" other, and we would be in 
equal terms (almost) with Ada. Well, I'm speculating but would be 
definitely interested in hearing more from someone more informed.

-- 
Take the Snape polls: http://snape.mosteo.com [Updated 16/05]

Re: Ada exception block does NOT work?

[Jean-Pierre Rosen]

Maciej Sobczak a �crit :
> Jean-Pierre Rosen wrote:
> 
>> There are no predefined exceptions in C++
> 
> 
> There are.
Certainly depends on which version of C++. I am happy to learn that they 
eventually made it, but still the language hasn't been designed with 
exceptions in mind.

>> therefore things like arithmetic overflow have undefined semantics
> 
> 
> The "therefore" part above is not correct. Since there *are* predefined 
> exceptions in C++, dealing with arithmetic anomalies certainly was based 
> on other, unrelated policies.
At the time where this policy was decided, there was no exceptions at 
all. I guess that changing this to raising exceptions would have been 
too incompatible.

>> Every sequence of statements can have an exception handler in Ada, 
>> while in C++/Java/C# you must add an extra level of nesting.
> 
> 
> You add the nesting if you want to handle the exception. If you don't 
> want to handle it, you don't add the nesting. This is rather the result 
> of having a *pair* of parentheses to denote a block, with no sensible 
> way of extending this punctuation. In Ada, "begin" and "end" are not a 
> closed pair and are easier to extend with any other keyword, thus making 
> a "comb" of arbitrary length. But this is a syntax issue.
> 
> I treat Ada's "begin" as having implicit "try" if there is any handler 
> downstream. Is there anything inherently wrong in this?
Well, in C++ you pretty well need to know precisely what code will raise 
which exception. That's what the syntax says; "try" means: I know that 
the following code may fail (and conversely, without a "try", I assume 
it may not fail). Ada is more oriented towards "expecting the 
unexpected". That's what I meant with the sentence below:

>> This gives the feeling that dealing with exceptions is something you 
>> just put in very special places, while in Ada you are more inclined to 
>> considering exceptions everywhere.
> 
> 
> But then we will drift to discuss whether it makes sense to deal with 
> exceptions everywhere or maybe only where the actual handler has 
> something to do. I haven't seen enough real Ada code to have any opinion 
> what is good in the Ada context.
> Don't you do this:
> 
> begin
>     -- ...
>     Some_Procedure_That_Might_Raise;
>     -- ...
> end;
> 
> and just let the exception (if any) travel up the chain to where there 
> is enough context to actually *do* somethng with the exception?
Of course.

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

Re: Ada exception block does NOT work?

[Dmitry A. Kazakov]

On Thu, 18 Aug 2005 15:15:14 +0200, Alex R. Mosteo wrote:

> Jean-Pierre Rosen wrote:
>> Maciej Sobczak a �crit :
> 
>>> Note that those other languages can throw regular objects as 
>>> exceptions, thus enabling polymorphism when they are handled. One 
>>> could say that *this* is the point of good integration and that Ada's 
>>> exceptions are a conceptual patch that did not integrate with the rest 
>>> of the object model, leading to two separate spaces of language 
>>> entities instead of only one.
>> 
>> This boils down to the (controversial) question of how much information 
>> should be associated to an exception. It could be the programmer's 
>> responsibility to store the context when an exception is raised, rather 
>> than propagating it with the exception. In Ada83, an exception had just 
>> an identity, and Jean Ichbiah (the father of Ada) claimed that he 
>> regretted having more than one exception. In Ada95, a string can be 
>> associated to an exception. In C++, any object can be thrown, while in 
>> Java only an object belonging to the throwable class. Note also that 
>> augmenting the quantity of information associated to an exception has a 
>> performance cost, which may be important for a real-time oriented 
>> language like Ada. So, you see the question is quite open...
> 
> I think the crux in this last point: you don't want that, once an 
> exception is being raised, you fail to propagate it because it can't be 
> allocated due to exhausted memory, for example.

Another problem is that the type of the exception object may leave its
scope while exception propagation. It might not be the case in C++ which
has it global, but it is in Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada exception block does NOT work?

[Georg Bauhaus]

Björn Persson wrote:
> This is starting to look very much like a Windows-specific bug.
> 

$ gnatmake -v -gnato trading.adb

GNATMAKE 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) Copyright 1995-2004 Free Software Foundation, Inc.
  "trading.ali" being checked ...
  -> "trading.ali" missing.
gcc-3.4 -c -gnato trading.adb
End of compilation
gnatbind -x trading.ali
gnatlink trading.ali

$ ./trading 
average: 10.00
...
average: 10.00
average:error here!
average:error here!
average:error here!
$

Same with GNATMAKE 4.0.1 20050609 (prerelease), and a GCC 4.1
snapshot.

AMD Duron, and PIIIs, Debian stable.

Re: Ada exception block does NOT work?

[Jeffrey Carter]

Maciej Sobczak wrote:
> 
> Why do you claim that Ada's exceptions are "better integrated into the 
> language than in the languages that throw and catch them"?

The core of C++ was designed before exceptions were added to the 
language, so the main part of the language is not designed with 
exceptions in mind. Ada's design included exceptions from the beginning, 
and exceptions are part of the definition of the semantics of all parts 
of the language. That's the basis of the claim.

This appears in different ways, which considered independently may not 
be sufficiently compelling as support for the claim. The try/catch block 
is one such symptom. That the C++ core language tends to have 
undefined/implementation-defined semantics where Ada has semantics 
defined in terms of exceptions is another.

Other C descendants seem to have adopted C++'s exception handling syntax 
and semantics, with varying degrees of back fitting to the core language.

> Note that those other languages can throw regular objects as exceptions, 
> thus enabling polymorphism when they are handled. One could say that 
> *this* is the point of good integration and that Ada's exceptions are a 
> conceptual patch that did not integrate with the rest of the object 
> model, leading to two separate spaces of language entities instead of 
> only one.

The idea that disparate concepts should be implemented using a single 
mechanism is generally a poor one. Not everything should be viewed as a 
number; not everything should be viewed as an object; not everything 
should be implemented with inheritance and dispatching; not everything 
should be implemented with tasks and protected objects.

On a more concrete level, Ada's was initially intended for critical, 
real-time, embedded SW. Allowing an arbitrary object to be used 
as/associated with an exception in such systems may not be a good idea.

Additionally, Ada allows nested scopes, which C and its descendants do 
not. This allows the existence of anonymous exceptions, exceptions that 
have propagated out of the scope of their definitions. Allowing 
arbitrary objects as/associated with exceptions gives rise to a similar 
set of problems as allowing type extensions at a deeper scope than the 
parent.

-- 
Jeffrey Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail
E-mail: jeffrey_r_carter-nr [commercial-at]
         raytheon [period | full stop] com

Re: Ada exception block does NOT work?

[Hyman Rosen]

Jeffrey Carter wrote:
> The try/catch block is one such symptom.

No. It would have been perfectly possible to not have
'try' at all, and simply allow a sequence of catch
clauses to follow any statement. Bjarne Stroustrup
addresses this explicitly in _The Design and Evolution
of C++_. The problem was that the resulting code looked
ambiguous and difficult to understand. Having explicit
try and a brace-enclosed section enhanced readability.

> That the C++ core language tends to have undefined/
> implementation-defined semantics where Ada has semantics
> defined in terms of exceptions is another.

The designers of C++ simply followed the lead of their
parent language in not checking certain core operations.
The choice was made not to check, so debating which
mechanism would not be used to not report the error is
silly. Where C++ does require checks, generally exceptions
are raised on failure. (Formatted I/O allows the choice to
silently fail subsequent operations once one fails, and
then to check once for failure at the end.)

> On a more concrete level, Ada's was initially intended for critical,
> real-time, embedded SW. Allowing an arbitrary object to be used
> as/associated with an exception in such systems may not be a good idea.

But as we know from SPARK, use of Ada in such environments
generally involves throwing away much of the existing language.
Therefore I do not find this to be a valid argument.

> Additionally, Ada allows nested scopes, which C and its descendants do
> not. This allows the existence of anonymous exceptions, exceptions that
> have propagated out of the scope of their definitions. Allowing
> arbitrary objects as/associated with exceptions gives rise to a similar
> set of problems as allowing type extensions at a deeper scope than the
> parent.

Yes, that's a much better argument. It puts the cause squarely on
other aspects of Ada's design rather than harrumphing and handwaving.
By the way, it's not correct to say that Ada allows nested scopes and
C-like languages do not. The problem here is that in Ada types are
dynamic while in C-like languages all types are static regardless of
the scope in which they are defined. So in those languages, there is
no concept of an object being able to outlive its type, and thus no
problem with throwing it out of the scope in which the type was defined.

Re: Ada exception block does NOT work?

[Martin Krischik]

Maciej Sobczak wrote:

> Note that those other languages can throw regular objects as exceptions,
> thus enabling polymorphism when they are handled.

It is interesting to note that Java and C# has reversed from C++ not
allowing any object to be thrown - but only object which are "Throwable".

Besides: can you throw C++/Java/C# exception across Threads, Processes or
Distributed (from on computer to the next over a network). You can with
Ada.

> One could say that 
> this is the point of good integration and that Ada's exceptions are a
> conceptual patch that did not integrate with the rest of the object
> model, leading to two separate spaces of language entities instead of
> only one.

Well Ada 83 had exceptions but not objects with dispatching so exceptions
could not be objects.

In fact this is one point you should remember: Ada 83 hat exceptions,
generics, well defined type system with type extension for primitive (int,
emum, etc. pp) types and a concept for "private".

The only thing which was missing and was added with Ada 95 where objects as
a C++ would see then.

C++ programmers often see Ada object as something bolted on - and I too had
some problems - but once you understand how it works you will see that it
is far better integrated into the language then in C++.

Surprised? Well Ada 95 had a concept of "RTTI" right from the beginning - in
C++ RTTI was bolted on later. And because Ada had "RTTI" right from the
beginning Ada does not need those "clone ()" functions often suggested in
C++ and Java tutorials. In Ada can clone any object without the aid of
clone () or Clonable.

How it works? Read:

http://en.wikibooks.org/wiki/Ada_Programming/Subtypes#Indefinite_subtype
http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation#The_class-wide_type

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[Martin Krischik]

Alex R. Mosteo wrote:

>  I see
> in the RM that there's a permission for an implementation to truncate
> the message associated with any exception, could be this the reason?

In Ada an exception may need to be send over the network to another
computer. Read the dreaded Annex E for details:

http://www.adaic.com/standards/95lrm/html/RM-E.html

But even without Annex E - exceptions inside a rendezvous need to be raised
in both threads and exceptions raised inside the thread initialisation is
transfered from the newly created thread to the creating thread - a thread
which failed to initialise can't handle an exception and somebody has to.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[Martin Krischik]

Maciej Sobczak wrote:

> In case of memory allocation error, the above will result in the
> std::bad_alloc exception being thrown.
> This is predefined and standard exception in C++.

True but again: In C++ bolted on later  (even after exceptions have been
bolted on) in Ada it had been there from day 1.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[jimmaureenrogers]

Hyman Rosen wrote:
> Yes, that's a much better argument. It puts the cause squarely on
> other aspects of Ada's design rather than harrumphing and handwaving.
> By the way, it's not correct to say that Ada allows nested scopes and
> C-like languages do not. The problem here is that in Ada types are
> dynamic while in C-like languages all types are static regardless of
> the scope in which they are defined. So in those languages, there is
> no concept of an object being able to outlive its type, and thus no
> problem with throwing it out of the scope in which the type was defined.

Please describe how you believe that Ada types are dynamic. I am not
clear
that I understand your use of the term.

Jim Rogers

Re: Ada exception block does NOT work?

[Hyman Rosen]

jimmaureenrogers@worldnet.att.net wrote:
> Please describe how you believe that Ada types are dynamic.

Ada types incorporate values that depend upon runtime values.
Array size is probably the simplest example - you can declare
an array inside a procedure whose size is determined by a
parameter to that procedure. I don't know Ada, but I'm pretty
sure that you can also have types whose discriminants are set
using values determined at runtime. As such, Ada types require
local storage (in principle) for their representation, and it
makes sense to free that storage once the scope in which the
type is declared is exited. C++ types never depend on runtime
values - they are always fully determined at compile time.

Re: Ada exception block does NOT work?

[Björn Persson]

Simon Wright wrote:
> With GCC 4.0.0 on powerpc-apple-darwin7.9.0, this outputs
> 
> ....
> average: 10.00
> average: 10.00
> average: 10.00
> average: 0.00
> average: 0.00
> average: 0.00
> $ 
> 
> which is of course a different bug!

Thou shalt not divide by zero – unless thou hast a Macintosh. ;-)

Out of curiosity: What happens if you initialize Sum with some other 
number? Can you divide any number by zero without getting an exception, 
or is it just 0/x=0 taking precedence over x/0=∞?

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada exception block does NOT work?

[Frank J. Lhota]

Hyman Rosen wrote:
> Ada types incorporate values that depend upon runtime values.
> Array size is probably the simplest example - you can declare
> an array inside a procedure whose size is determined by a
> parameter to that procedure. I don't know Ada, but I'm pretty
> sure that you can also have types whose discriminants are set
> using values determined at runtime. As such, Ada types require
> local storage (in principle) for their representation, and it
> makes sense to free that storage once the scope in which the
> type is declared is exited. C++ types never depend on runtime
> values - they are always fully determined at compile time.
>

It is true that C++ types are static, but it is still possible to have 
scope problems with C++ exceptions, for example:

class CBadException
    {
    public:
       int& m_Count;
       CBadException (int& Count) : m_Count (Count) {}
    };

void foo ()
    {
    int Count;
    CBadException Expt (Count);

    throw Expt;	// Expt now references Count,
                 // which is going out of scope
    }

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Ada exception block does NOT work?

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Jeffrey R. Carter wrote:
> 
> > Ada has had exceptions, well integrated with the rest of the language,
> > since Ada 80. Ada's terminology is that exceptions are raised and
> > handled.
> 
> OK, but the question is not about terminology, really.

It is unfortunate that different programming languages use different
terminology for what is essentially the same concept.  "Raise" and
"handle" mean essentially the same thing as "throw" and "catch".
There are important differences in syntax and semantics among different
languages, but terminology differences just get in the way of
understanding the "real" differences.  And the differences between C++
and Java are just as important as the differences between C++ and Ada,
even though C++ and Java use more-similar terminology.

Anyway, if you say "throw" in an Ada newsgroup, folks ought to know what
you're talking about.

> If you claim that exceptions were "patched" on to the C++ language that
> did not have them originally, then let's switch the context to other
> language that has no history issue like this.
> 
> I don't know the full history of Java, but I suppose that it had
> exceptions from the very beginning.

Yes, it did.

>... If not, let's take C#. Whether those
> languages tried to mimic the syntax from C++ does not matter at all when
> it comes to discussion how well the mechanism is integrated into the
> language.

Agreed.

> Why do you claim that Ada's exceptions are "better integrated into the
> language than in the languages that throw and catch them"?

Well, given something that ought to be considered an "error", the
language designer has to decide how to deal with it: make it raise/throw
an exception, or make it return a well-defined but likely-wrong answer,
or make the behavior "unpredictable", or restrict things so it can be
detected at compile time, or ....

The raise/throw exception choice was not available to Stroustrup when he
designed C++, since C++ at that time had no exception facility, and
since he intended to be compatible with C.  This has nothing to do with
whether you call it "raise" or "throw".  But it does mean that
exceptions are not well-integrated, since certain run-time errors that
really ought to cause exceptions do not.  For example, overflow on
signed integer arithmetic.  On this point, I agree with Jeff Carter.

On the other hand, the Java designers were not trying to be compatible
with C, and could well have made signed integer overflow throw an
exception.  But they chose instead to make it return a probably-wrong
answer; that is, they unwisely chose wraparound arithmetic.

On the third hand, *unsigned* integer arithmetic is wrap-around in C,
C++, Java, *and* Ada.

----------------

As to the syntax: I think the try/catch statement or whatever is
*better* than the Ada syntax, because it makes it quite clear which
region of code is protected by the handler.  In Ada:

    procedure P(...) is
        ... -- (1)
    begin
        ... -- (2)
    exception
        when Some_Error =>
            Do_Something;
    end P;

An exception at (2) is handled by the handler, whereas an exception at
(1) is not.  But it *looks* like both should be handled, from the
syntax, and the usual indentation.  More importantly, one moves code
above/below the "begin" line based on criteria having nothing to do with
exceptions -- whether it's needed to initialize or constrain things, for
example.

There are, of course, good reasons why exceptions at (1) are not handled
by the above handler.  But I think the try/catch syntax deals with these
issues more neatly.

> Note that those other languages can throw regular objects as exceptions,
> thus enabling polymorphism when they are handled. One could say that
> *this* is the point of good integration and that Ada's exceptions are a
> conceptual patch that did not integrate with the rest of the object
> model, leading to two separate spaces of language entities instead of
> only one.

I agree.  If you want to attach information to an exception in Java, you
do it in the same way you attach information to any other sort of object
-- you declare record fields in a type extension (i.e. in a class in the
exception hierarchy).  In Ada, you have to use a special gizmo.  The
Java way is clearly more well-integrated with the rest of the language.

Besides, the Java way is type safe at compile time, whereas the Ada
gizmo is not.

On the other hand, in C++, an exception can be *anything* -- you can
throw a string, or an int.  I don't like that.

> Note that I'm learning Ada and I'm likely to misunderstand things.

Perhaps, but you seem to understand the exception-related issues just
fine.  ;-)

>... But
> I'm curious about your way of reasoning and I want to better understand
> the differences between languages (and that's why I'm provoking you with
> the above inverted claim ;) ).

- Bob

Re: Ada exception block does NOT work?

[Simon Wright]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 366 bytes --]

Bj^[.A^[Nvrn Persson <spam-away@nowhere.nil> writes:

> Simon Wright wrote:
>> With GCC 4.0.0 on powerpc-apple-darwin7.9.0, this outputs

> Out of curiosity: What happens if you initialize Sum with some other
> number? Can you divide any number by zero without getting an
> exception, or is it just 0/x=0 taking precedence over x/0=^[$B!g^[(B?

2.0 / 0 -> 0.0 :-(

-S

Re: Ada exception block does NOT work?

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Jeffrey R. Carter wrote:
> 
> > Ada has had exceptions, well integrated with the rest of the language,
> > since Ada 80. Ada's terminology is that exceptions are raised and
> > handled.
> 
> OK, but the question is not about terminology, really.

By the way, here's a more subtle terminology difference:

What Ada calls "an exception" is what some other languages call "an
exception type" or "an exception class".  What Ada calls "an exception
occurrence" is what other languages call "an exception" (i.e. "an object
of an exception type/class").

And by the by the way, here's an analogy:

In very-early versions of Ada (the Green language), tasks were a
separate gizmo.  The designers of Ada 83 wisely chose to make tasks be
more integrated with the rest of the language -- to create a task, you
declare an object of a task type, or create a heap object of a task type
using "new", just like other sorts of objects are created.

In Green, there was something called a "task family", indexed by
integers.  In Ada, you simply create an array of tasks.  This is both
simpler (no need for a separate "task family" concept) and more general
(you can create any other sort of data structure using tasks -- arrays
of pointers to variant records containing tasks, etc).

I wish exceptions were treated the same way, with first-class exception
types and exception objects.  This would be both simpler and more
general.

- Bob

P.S. Regarding tasks, they didn't go quite far enough.  For example, why
do we say "task type T is..." instead of "type T is task..." like all
the other kinds of types?

Re: Ada exception block does NOT work?

[Hyman Rosen]

Robert A Duff wrote:
> But it does mean that exceptions are not well-integrated,
> since certain run-time errors that really ought to cause
> exceptions do not.  For example, overflow on signed integer
> arithmetic.

This argument is flawed. It would make sense only if C++
detected signed overflow and reported the error other than
by raising an exception. C++ merely follows the lead of
its parent language and does no checking for this condition.
It's not because exceptions were unavailable, it's because
requiring the check was conceived to be potentially too
costly and would have served as a barrier to adoption because
it would have slowed down the equivalent code in C++ with
respect to C.

Actually, since signed overflow is undefined behavior, an
implementation is free to check for it and raise an exception
if it wants to.

The checked vector accessor reports a bad index through
exceptions. The memory allocator reports failure through
exceptions. The formatted I/O system can report failure
through exceptions (although it's normally more convenient
to check for errors at the end).

Re: Ada exception block does NOT work?

[jimmaureenrogers]

Hyman Rosen wrote:
> jimmaureenrogers@worldnet.att.net wrote:
> > Please describe how you believe that Ada types are dynamic.
>
> Ada types incorporate values that depend upon runtime values.
> Array size is probably the simplest example - you can declare
> an array inside a procedure whose size is determined by a
> parameter to that procedure. I don't know Ada, but I'm pretty
> sure that you can also have types whose discriminants are set
> using values determined at runtime. As such, Ada types require
> local storage (in principle) for their representation, and it
> makes sense to free that storage once the scope in which the
> type is declared is exited. C++ types never depend on runtime
> values - they are always fully determined at compile time.

Ada types are also fully determined at compile time.
An unconstrained array type may have instances of different
lengths, but the type does not change. Likewise, a discriminant
type can have separate instances with different structures, but the
type is fixed at compile time.

C++ does not allow the definition of an array type in the sense
that it is defined in Ada. The typedef reserved word does not
create or designate a unique type. It only provides an alias or
alternate name for a type.

Ada types do not require any storage. Instances of types require
storage. In C++ a class with no static members requires no storage.
Each instance of that class requires its own separate storage. C++
variables may have scoping rules. Ada variables have scoping rules.
The rules are somewhat different, but the concepts are similar.

In C++ you can use a pointer to pass an array instance by reference.
The size of the array passed is determined at run-time. Ada allows
the definition of an unconstrained array type. Such a type can be
used as the parameter for a procedure or function. Each instance
of an unconstrained type must be constrained. The size of the
instance passed to an function or procedure may be determined at
run-time.

Ada also allows the definition of constrained array types. All
instances on a constrained array type have the same number of elements.
The size of all such instances is determined at compile time.

Except for classes, the C++ type system is relatively weak, and
is very similar to the C type system. Both C, and C++ provide a
wealth of implicit conversions between primitive types. This
makes the type system to appear much more dynamic than the Ada
type system. Ada provides no implicit conversions between types.
Ada's type system is both very strong and static.

You can declare local Ada types in internal blocks, according to
the values of variables:

procedure New_Type(Min, Max : Integer) is
   type Local_Type is range Min..Max;
begin
   for I in Local_Type'range loop
      Put_Line(Local_type'Image(I));
   end loop;
end New_Type;

Each time the procedure New_Type is executed Local_Type is
redefined. Local_Type has a scope only within the procedure
New_Type. If Min is greater than Max Local_Type will have a
null value range. This is not a case of a dynamic type.
It is an example of Ada elaboration. The declarative part of
the procedure New_Type is elaborated each time the procedure
is called, before execution of the body of the procedure
occurs.

Quoting from the Ada Language Reference Manual section 3.2.1:

The elaboration of a full_type_declaration consists of the elaboration
of the full type definition. Each elaboration of a full type definition
creates a distinct type and its first subtype.

This means that the type does not mutate from one call of the
procedure to another. Separate, distinct types are declared with
a lifetime controlled by the scope of their definition.

Jim Rogers

Re: Ada exception block does NOT work?

[Jeffrey R. Carter]

Robert A Duff wrote:

> It is unfortunate that different programming languages use different
> terminology for what is essentially the same concept.  "Raise" and
> "handle" mean essentially the same thing as "throw" and "catch".
> There are important differences in syntax and semantics among different
> languages, but terminology differences just get in the way of
> understanding the "real" differences.  And the differences between C++
> and Java are just as important as the differences between C++ and Ada,
> even though C++ and Java use more-similar terminology.

The point is that Ada was there first, so Ada terminology must be the "Right" 
terminology.

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31

Re: Ada exception block does NOT work?

[Dmitry A. Kazakov]

On 18 Aug 2005 17:57:47 -0700, jimmaureenrogers@worldnet.att.net wrote:

> Quoting from the Ada Language Reference Manual section 3.2.1:
> 
> The elaboration of a full_type_declaration consists of the elaboration
> of the full type definition. Each elaboration of a full type definition
> creates a distinct type and its first subtype.

Which means exactly that types in Ada are dynamic.

> This means that the type does not mutate from one call of the
> procedure to another. Separate, distinct types are declared with
> a lifetime controlled by the scope of their definition.

Which was the point. Types in Ada have scopes, this is why they are
dynamic.

[ Mutability is an independent issue. First Ada does not have types as
first-class objects, so it is not very accurate to talk about them in the
context of mutable or not "types variables". Though because they are not
objects, there is also no way no change any "types variable". If they were
objects then highly probably limited ones. ]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada exception block does NOT work?

[Dmitry A. Kazakov]

On 18 Aug 2005 17:15:05 -0400, Robert A Duff wrote:

> I wish exceptions were treated the same way, with first-class exception
> types and exception objects.  This would be both simpler and more
> general.

It should be easy. Let's remove "exception" from the list of reserved words
and add to Ada.Exceptions:

subtype Exception_Occurrence is exception;

(:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada exception block does NOT work?

[Dr. Adrian Wrigley]

On Thu, 18 Aug 2005 16:56:35 -0400, Robert A Duff wrote:

> On the third hand, *unsigned* integer arithmetic is wrap-around in C,
> C++, Java, *and* Ada.

err... doesn't Ada raise exceptions on overflow for unsigned types?
presumably you are talking of Ada's modular types(?) which are
(obviously) wrap-around, exactly as users want from such a type(!)
-- 
Adrian

Re: Ada exception block does NOT work?

[Robert A Duff]

"jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes:

> Ada types do not require any storage. Instances of types require
> storage.

Well, *subtypes* require storage, which is really what matters for
Hymen's point.

> Ada also allows the definition of constrained array types. All
> instances on a constrained array type have the same number of elements.
> The size of all such instances is determined at compile time.

No, actually, it can be determined at run time.  For example:

    type Index is new Integer range 1..F(X);
    type T is array(Index) of Character;

where F(X) is a function call that reads from the keyboard.
All objects of type T have the same length, but that length
is not known at compile time.

Actually, there is one obscure exception:

    X: T := ...;
    Mid: Index := ...;
    X := X(Mid+1..X'Last) & X(X'First..Mid);

There are two intermediate results that have other lengths.
OK, OK, that's a nit.  ;-)

> ...Ada provides no implicit conversions between types.

It does, but they're less error prone than those of C++.

> Ada's type system is both very strong and static.

Well, Ada does lots of checks at run time.  They're not called "type
checks", but if they were, would that make the language less safe?
Would it mean Ada does dynamic type checking?

> You can declare local Ada types in internal blocks, according to
> the values of variables:
> 
> procedure New_Type(Min, Max : Integer) is
>    type Local_Type is range Min..Max;

That's illegal.  Min and Max must be static.  However, you could
say:

    type Local_Type is new Integer range Min..Max;

- Bob

Re: Ada exception block does NOT work?

[Robert A Duff]

"Hyman Rosen" <hyman.rosen@gmail.com> writes:

> Jeffrey Carter wrote:
> > The try/catch block is one such symptom.
> 
> No. It would have been perfectly possible to not have
> 'try' at all, and simply allow a sequence of catch
> clauses to follow any statement. Bjarne Stroustrup
> addresses this explicitly in _The Design and Evolution
> of C++_. The problem was that the resulting code looked
> ambiguous and difficult to understand. Having explicit
> try and a brace-enclosed section enhanced readability.

I agree with Hyman Rosen here (and with Bjarne Stroustrup!).

Not only is it more readable to have a separate statement for handled
regions, it simplifies the language.  And it obviates the need for
extraneous block_statements.

On the other hand, it's not that big of a deal, either way.

> > That the C++ core language tends to have undefined/
> > implementation-defined semantics where Ada has semantics
> > defined in terms of exceptions is another.
> 
> The designers of C++ simply followed the lead of their
> parent language in not checking certain core operations.
> The choice was made not to check, so debating which
> mechanism would not be used to not report the error is
> silly. Where C++ does require checks, generally exceptions
> are raised on failure. (Formatted I/O allows the choice to
> silently fail subsequent operations once one fails, and
> then to check once for failure at the end.)

OK, fair enough.  But I still think allowing the programmer to choose
whether to do overflow checking or not is a far superior language design
than one that doesn't allow that choice.  The programmer, not the
language designer, is the only one in a position to make that choice.

> > On a more concrete level, Ada's was initially intended for critical,
> > real-time, embedded SW. Allowing an arbitrary object to be used
> > as/associated with an exception in such systems may not be a good idea.
> 
> But as we know from SPARK, use of Ada in such environments
> generally involves throwing away much of the existing language.
> Therefore I do not find this to be a valid argument.

I don't find it to be valid, either.  But I think your point about SPARK
is invalid, too, because many real-time embedded systems use much larger
subsets of Ada than SPARK.

The real issue is whether exception (occurrences) can have non-static
size.  If that's bad for your real-time system, then don't use that
feature; it's not a good reason to leave the feature out of the
language.  Another case where the programmer, not the language design,
should make the decision.

> > Additionally, Ada allows nested scopes, which C and its descendants do
> > not. This allows the existence of anonymous exceptions, exceptions that
> > have propagated out of the scope of their definitions. Allowing
> > arbitrary objects as/associated with exceptions gives rise to a similar
> > set of problems as allowing type extensions at a deeper scope than the
> > parent.
> 
> Yes, that's a much better argument. It puts the cause squarely on
> other aspects of Ada's design rather than harrumphing and handwaving.
> By the way, it's not correct to say that Ada allows nested scopes and
> C-like languages do not. The problem here is that in Ada types are
> dynamic while in C-like languages all types are static regardless of
> the scope in which they are defined. So in those languages, there is
> no concept of an object being able to outlive its type, and thus no
> problem with throwing it out of the scope in which the type was
> defined.

But in both C++ and Ada, types have type descriptors (or method dispatch
tables, or whatever you want to call them).  These point at procedures.
And if those procedures can be nested, those procedures can depend on
(and modify) the stack-allocated data.

In other words, I agree with Jeff here, that the issue is nesting (not
staticness of types).

- Bob

Re: Ada exception block does NOT work?

[Martin Krischik]

Dr. Adrian Wrigley wrote:

> On Thu, 18 Aug 2005 16:56:35 -0400, Robert A Duff wrote:
> 
>> On the third hand, *unsigned* integer arithmetic is wrap-around in C,
>> C++, Java, *and* Ada.
> 
> err... doesn't Ada raise exceptions on overflow for unsigned types?
> presumably you are talking of Ada's modular types(?) which are
> (obviously) wrap-around, exactly as users want from such a type(!)

Well, the very first C did not have "unsigned int" there was just int.
That's why unix has a 2GB limit on files and not a 4 GB limit. (There is a
new set of file IO which can deal with larger files).

I think Java is still without "unsigned".

And last not least Ada "mod" type in not only unsigned it also has warp
around as extra - which you might not actually want.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[Martin Krischik]

jimmaureenrogers@worldnet.att.net wrote:


> Please describe how you believe that Ada types are dynamic. I am not
> clear
> that I understand your use of the term.

Just a few examples:

http://en.wikibooks.org/wiki/Ada_Programming/Types/array#With_unknown_subrange
http://en.wikibooks.org/wiki/Ada_Programming/Strings#Fixed-length_string_handling


Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[Frank J. Lhota]

Martin Krischik wrote:
> Well, the very first C did not have "unsigned int" there was just int.
> That's why unix has a 2GB limit on files and not a 4 GB limit. (There is a
> new set of file IO which can deal with larger files).

The standard of the Vanilla, K&R C language "The C Programming Language" 
first edition, does include unsigned integer types. The old Unix file 
size limit is probably due to other reasons.

> I think Java is still without "unsigned".

That is true, but Java does provide the common bit twiddling operations 
for its signed integers.

> And last not least Ada "mod" type in not only unsigned it also has warp
> around as extra - which you might not actually want.

Or it might be exactly what you want. It depends on the application.

> Martin
> 

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Ada exception block does NOT work?

[Robert A Duff]

"Jeffrey R. Carter" <spam@spam.com> writes:

> Robert A Duff wrote:
> 
> > It is unfortunate that different programming languages use different
> > terminology for what is essentially the same concept.  "Raise" and
> > "handle" mean essentially the same thing as "throw" and "catch".
> > There are important differences in syntax and semantics among different
> > languages, but terminology differences just get in the way of
> > understanding the "real" differences.  And the differences between C++
> > and Java are just as important as the differences between C++ and Ada,
> > even though C++ and Java use more-similar terminology.
> 
> The point is that Ada was there first, so Ada terminology must be the
> "Right" terminology.

Ada was certainly not the first language with exceptions.
Does anybody know which one was?  And were they called "exceptions"
and were they "raised" and "handled"?

I believe Symbolics Lisp predates Ada.  True?  And I believe it had
exceptions, which were called "conditions".  (Symbolics Lisp was
the predecessor of Common Lisp.)

Anyway, terminology of programming language concepts is such a mess that
it's hard to say what the "right" terminology is.  Too bad.

Besides, there's an element of "pot calling kettle black" here.
Ada misuses quite a few terms.  For example, pointers should be called
"pointers" or "references", not "accesses".  And it's an abomination to
use the term "integer" for a meager subset of the integers.  I believe
the term "integer" to refer to the infinite set predates Ada somewhat.
;-)

- Bob

Re: Ada exception block does NOT work?

[Jeffrey R. Carter]

Robert A Duff wrote:

> 
> Ada was certainly not the first language with exceptions.
> Does anybody know which one was?  And were they called "exceptions"
> and were they "raised" and "handled"?

Perhaps I should have added a smiley in there. But between Ada and those using 
the C++ notation, Ada was certainly first.

> Besides, there's an element of "pot calling kettle black" here.
> Ada misuses quite a few terms.  For example, pointers should be called
> "pointers" or "references", not "accesses".  And it's an abomination to
> use the term "integer" for a meager subset of the integers.  I believe
> the term "integer" to refer to the infinite set predates Ada somewhat.

I always thought the whole point of "access" was to not (seem to) require them 
to just be "pointers". Bounds information and the like can be part of an access 
value.

As for Integer, you're quite right, but it's also quite natural to use that name 
(or a shortened form of it) for such a subset. Such a usage is quite common in 
computer languages; see FORTRAN (1955?) for an example. What would be a better 
name for such a type?

-- 
Jeff Carter
"If I could find a sheriff who so offends the citizens of Rock
Ridge that his very appearance would drive them out of town ...
but where would I find such a man? Why am I asking you?"
Blazing Saddles
37

Re: Ada exception block does NOT work?

[Robert A Duff]

"Jeffrey R. Carter" <spam@spam.com> writes:

> Robert A Duff wrote:
> 
> > Ada was certainly not the first language with exceptions.
> > Does anybody know which one was?  And were they called "exceptions"
> > and were they "raised" and "handled"?
> 
> Perhaps I should have added a smiley in there.

;-)

>... But between Ada and those
> using the C++ notation, Ada was certainly first.

Indeed.  I do prefer "raise/handle" to "throw/catch", but maybe because
that's what I'm used to.

There are also exceptions in the hardware world, variously called
"exceptions", "traps", and "synchronous interrupts".  I'm talking about
divide-by-zero, overflow, and the like.  Surely the software concept
came from that?

> > Besides, there's an element of "pot calling kettle black" here.
> > Ada misuses quite a few terms.  For example, pointers should be called
> > "pointers" or "references", not "accesses".  And it's an abomination to
> > use the term "integer" for a meager subset of the integers.  I believe
> > the term "integer" to refer to the infinite set predates Ada somewhat.
> 
> I always thought the whole point of "access" was to not (seem to)
> require them to just be "pointers". Bounds information and the like can
> be part of an access value.

Perhaps also to distinguish them from C-style pointers, which are rather
lower level.

To me, "pointer" does not imply "a single machine address".
To me, "pointer" means something that can point at things,
and that includes fat pointers, pointers containing array
dope, pointers represented as offsets instead of addresses, 
double indirections, &c.
To me, "pointer" and "reference" are synonymous.
And "address" or "machine address" can be used for the hardware-level
concept.

An index into an array can be used as a pointer to a particular
array element.

Ada evolved from Pascal, and Pascal called them pointers.
In Pascal, there was no requirement or implication that
they must be a single machine address.  There is no need
for array dope in Pascal, but adding array dope doesn't seem
like it requires renaming the whole concept.

> As for Integer, you're quite right, but it's also quite natural to use
> that name (or a shortened form of it) for such a subset. Such a usage is
> quite common in computer languages; see FORTRAN (1955?) for an
> example. What would be a better name for such a type?

I'd use "Integer" for what Lisp calls "bignums" -- integers that can
grow without bound (except of course you can run out of memory,
but that's true of Strings and whatnot, too.  I'd call the integer type
that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".
And I wouldn't put it in a package called "Standard" and I wouldn't
make it automatically visible everywhere.

I think one ought to be allowed to say:

    type T is range 1..10**100;

Portably.

- Bob

Re: Ada exception block does NOT work?

[Frank J. Lhota]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccslx4gumc.fsf@shell01.TheWorld.com...
> ...
> To me, "pointer" does not imply "a single machine address".
> To me, "pointer" means something that can point at things,
> and that includes fat pointers, pointers containing array
> dope, pointers represented as offsets instead of addresses,
> double indirections, &c.

Thats fine, but also understand that to many others, "pointer" does mean "a 
single machine address". It certainly does not hurt to introduce a new term 
to avoid potential misunderstandings.

> To me, "pointer" and "reference" are synonymous.

OK, but just be aware that in C++, "pointer" and "reference" are not 
synonyms.

> And "address" or "machine address" can be used for the hardware-level
> concept.
>
> An index into an array can be used as a pointer to a particular
> array element.

So the number 3 can be thought of as a pointer into any array indexed by a 
integer. An interesting concept, but this is certainly a non-standard use of 
the term "pointer".

> Ada evolved from Pascal, and Pascal called them pointers.
> In Pascal, there was no requirement or implication that
> they must be a single machine address.  There is no need
> for array dope in Pascal, but adding array dope doesn't seem
> like it requires renaming the whole concept.

For the record, I know of no Pascal compiler that implements a pointer as 
anything other than a machine address.

>> As for Integer, you're quite right, but it's also quite natural to use
>> that name (or a shortened form of it) for such a subset. Such a usage is
>> quite common in computer languages; see FORTRAN (1955?) for an
>> example. What would be a better name for such a type?
>
> I'd use "Integer" for what Lisp calls "bignums" -- integers that can
> grow without bound (except of course you can run out of memory,
> but that's true of Strings and whatnot, too.  I'd call the integer type
> that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".
> And I wouldn't put it in a package called "Standard" and I wouldn't
> make it automatically visible everywhere.
>
> I think one ought to be allowed to say:
>
>    type T is range 1..10**100;
>
> Portably.

Now that is an interesting concept. I am fond of divorcing the language from 
platform constrains when practical. There are, however, some practical 
concerns about this proposal. An Ada 'bignum' type would undoubtedly be a 
controlled type, introducing more overhead than one would expect in a scalar 
type.

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Ada exception block does NOT work?

[Robert A Duff]

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccslx4gumc.fsf@shell01.TheWorld.com...
> > ...
> > To me, "pointer" does not imply "a single machine address".
> > To me, "pointer" means something that can point at things,
> > and that includes fat pointers, pointers containing array
> > dope, pointers represented as offsets instead of addresses,
> > double indirections, &c.
> 
> Thats fine, but also understand that to many others, "pointer" does mean "a 
> single machine address".

Agreed.  And to some folks, "pointer" implies "you can do arithmetic on
it" (i.e. C-style pointers).

There's no uniform terminology across programming languages.
That's not surprising, given that programming language design
is such a new art.

>... It certainly does not hurt to introduce a new term 
> to avoid potential misunderstandings.

I think it does hurt to introduce new terms -- we end up with 37
different ways of referring to the same thing (and folks who talk about
"methods" have trouble communicating with folks who talk about
"procedures" and so on).

> > To me, "pointer" and "reference" are synonymous.
> 
> OK, but just be aware that in C++, "pointer" and "reference" are not 
> synonyms.

True.  But they're pretty close.  The both "point at" or "refer to"
things.  There are differences in which ones you can copy and whether
dereferencing is explicit or implicit and so on.

Interesting that we "dereference" pointers.  ;-)
As opposed to "depointering" them.

> > And "address" or "machine address" can be used for the hardware-level
> > concept.
> >
> > An index into an array can be used as a pointer to a particular
> > array element.
> 
> So the number 3 can be thought of as a pointer into any array indexed by a 
> integer. An interesting concept, but this is certainly a non-standard use of 
> the term "pointer".

Really?  I sometimes write code something like this:

    type Stack_Index is range 1..whatever;
    subtype Stack_Count is Stack_Index'Base range 0..whatever;
    type Stack(Max: ...) is limited
        record
            Top: Stack_Count := 0; -- points to the top element of the stack
            Elements: Element_Array(1..Max);
        end record;

Do you think "points to" is confusing in the above comment?

> > Ada evolved from Pascal, and Pascal called them pointers.
> > In Pascal, there was no requirement or implication that
> > they must be a single machine address.  There is no need
> > for array dope in Pascal, but adding array dope doesn't seem
> > like it requires renaming the whole concept.
> 
> For the record, I know of no Pascal compiler that implements a pointer as 
> anything other than a machine address.

That's true.  And almost all Ada compilers use single-machine-address
to represent almost-all access types.

> >> As for Integer, you're quite right, but it's also quite natural to use
> >> that name (or a shortened form of it) for such a subset. Such a usage is
> >> quite common in computer languages; see FORTRAN (1955?) for an
> >> example. What would be a better name for such a type?
> >
> > I'd use "Integer" for what Lisp calls "bignums" -- integers that can
> > grow without bound (except of course you can run out of memory,
> > but that's true of Strings and whatnot, too.  I'd call the integer type
> > that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".
> > And I wouldn't put it in a package called "Standard" and I wouldn't
> > make it automatically visible everywhere.
> >
> > I think one ought to be allowed to say:
> >
> >    type T is range 1..10**100;
> >
> > Portably.
> 
> Now that is an interesting concept. I am fond of divorcing the language from 
> platform constrains when practical. There are, however, some practical 
> concerns about this proposal. An Ada 'bignum' type would undoubtedly be a 
> controlled type, introducing more overhead than one would expect in a scalar 
> type.

Well, one has to learn what to "expect" in terms of efficiency.

In a garbage-collected implementation of Ada, bignum would not need to
be a controlled type.

If I said "1..2**80", I would "expect" 3 words to be allocated typically
on the stack, with no heap usage, and no need for either controlled
types or GC.  If I said "1..2**1000", I would expect heap usage, and
consequent controlled types or GC.  If I'm writing a hard real-time
embedded system, I probably won't say "1..2**1000".

But I'm not even allowedd to say "1..2**80" in any Ada compiler I know
of, and I can't even count on "1..2**35" portably.  Sigh.

- Bob

Re: Ada exception block does NOT work?

[Björn Persson]

Robert A Duff wrote:
> I do prefer "raise/handle" to "throw/catch", but maybe because
> that's what I'm used to.

Personally I think "catch" is a more descriptive term than "handle". To 
"handle" an exception seems to imply that you do something about it. If 
you write an exception handler that just contains a null statement, to 
ignore exceptions that you really ought to react to, it's doubtful if 
that can be called handling them. Or take an exception handler that 
doesn't do anything about the exception itself, but only deallocates 
some memory or something and then re-raises the exception. Does that 
constitute handling the exception? If the re-raised exception propagates 
out of the program it will be called an unhandled exception.

So exception handlers ought to be called exception catchers. The 
exception catcher catches the exception, and then it's up to the code 
inside the exception catcher to handle the exception, ignore it or pass 
it on.

And if you say that you catch exceptions it's of course natural to also 
say that you throw them.

But this is not in any way important to me. Besides, it would be 
unreasonable to expect that people who invent new concepts will always 
come up with perfect names for them

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada exception block does NOT work?

[Larry Kilgallen]

In article <wccslx4gumc.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> "Jeffrey R. Carter" <spam@spam.com> writes:
> 
>> Robert A Duff wrote:
>> 
>> > Ada was certainly not the first language with exceptions.
>> > Does anybody know which one was?  And were they called "exceptions"
>> > and were they "raised" and "handled"?
>> 
>> Perhaps I should have added a smiley in there.
> 
> ;-)
> 
>>... But between Ada and those
>> using the C++ notation, Ada was certainly first.
> 
> Indeed.  I do prefer "raise/handle" to "throw/catch", but maybe because
> that's what I'm used to.
> 
> There are also exceptions in the hardware world, variously called
> "exceptions", "traps", and "synchronous interrupts".  I'm talking about
> divide-by-zero, overflow, and the like.  Surely the software concept
> came from that?

VMS had exception handlers/signal handlers in 1978 with most languages
establishing handlers by calls to runtime routines.

Re: Ada exception block does NOT work?

[Dmitry A. Kazakov]

On 20 Aug 2005 17:34:51 -0400, Robert A Duff wrote:

> I'd use "Integer" for what Lisp calls "bignums" -- integers that can
> grow without bound (except of course you can run out of memory,
> but that's true of Strings and whatnot, too.  I'd call the integer type
> that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".
> And I wouldn't put it in a package called "Standard" and I wouldn't
> make it automatically visible everywhere.
> 
> I think one ought to be allowed to say:
> 
>     type T is range 1..10**100;

But that wouldn't be an "integer" you have described! What you want seems
to me rather the Universal_Integer:

X : Universal_Integer;
   -- No overflows, ever. Storage_Error instead

subtype T is Universal_Integer range 1..10**100;
   -- No overflows in any numerical operations, only when value is stored

> Portably.

Sure!

I think it wouldn't be that difficult to do, I mean to expose
Universal_Integer. However range checks might be tricky to do without
overhead. The memory required to keep bounds might be bigger than all
actual values! Though it is unlikely that somebody would really need to
constrain Universal_Integer by 10**100 instead of using the base type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada exception block does NOT work?

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>     type Stack_Index is range 1..whatever;
>     subtype Stack_Count is Stack_Index'Base range 0..whatever;

Now I see it this idiom is obvious .. thanks!

>     type Stack(Max: ...) is limited
>         record
>             Top: Stack_Count := 0; -- points to the top element of the stack
>             Elements: Element_Array(1..Max);
>         end record;
>
> Do you think "points to" is confusing in the above comment?

Yes, a bit (sorry)

Re: Ada exception block does NOT work?

[Martin Krischik]

Frank J. Lhota wrote:

> Martin Krischik wrote:
>> Well, the very first C did not have "unsigned int" there was just int.
>> That's why unix has a 2GB limit on files and not a 4 GB limit. (There is
>> a new set of file IO which can deal with larger files).
> 
> The standard of the Vanilla, K&R C language "The C Programming Language"
> first edition, does include unsigned integer types. The old Unix file
> size limit is probably due to other reasons.

It's because they used "signed int" for all file operations. Personally I
consider that damm stupid - after all: have you ever seen a file with a
negative size?

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[Frank J. Lhota]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcck6ig89oz.fsf@shell01.TheWorld.com...
> ...
>
> Agreed.  And to some folks, "pointer" implies "you can do arithmetic on
> it" (i.e. C-style pointers).
>
> There's no uniform terminology across programming languages.
> That's not surprising, given that programming language design
> is such a new art.

This lack of uniform terminology can cause confusion. For example, what does 
"package" mean? In some languages, a package is little more than a name 
space. In Ada, it is something far more substantial.

>>... It certainly does not hurt to introduce a new term
>> to avoid potential misunderstandings.
>
> I think it does hurt to introduce new terms -- we end up with 37
> different ways of referring to the same thing (and folks who talk about
> "methods" have trouble communicating with folks who talk about
> "procedures" and so on).

I'm in full agreement with the notion that new terms should not be 
introduced unless they represent new concepts. The arguments over "throw" 
versus "raise", "catch" versus "handle" are silly, and divert attention from 
the real issues.

> True.  But they're pretty close.  The both "point at" or "refer to"
> things.  There are differences in which ones you can copy and whether
> dereferencing is explicit or implicit and so on.
>
> Interesting that we "dereference" pointers.  ;-)
> As opposed to "depointering" them.

The English language is full of such quirks, even outside of programming. 
Why do we drive on the parkway and park on the driveway?

> ...
>> For the record, I know of no Pascal compiler that implements a pointer as
>> anything other than a machine address.
>
> That's true.  And almost all Ada compilers use single-machine-address
> to represent almost-all access types.

At least major Ada compiler, GNAT, does use "fat" pointers for accessing 
unconstrained arrays unless forbidden by representation clauses.

> ...
>> Now that is an interesting concept. I am fond of divorcing the language 
>> from
>> platform constrains when practical. There are, however, some practical
>> concerns about this proposal. An Ada 'bignum' type would undoubtedly be a
>> controlled type, introducing more overhead than one would expect in a 
>> scalar
>> type.
>
> Well, one has to learn what to "expect" in terms of efficiency.
>
> In a garbage-collected implementation of Ada, bignum would not need to
> be a controlled type.
>
> If I said "1..2**80", I would "expect" 3 words to be allocated typically
> on the stack, with no heap usage, and no need for either controlled
> types or GC.  If I said "1..2**1000", I would expect heap usage, and
> consequent controlled types or GC.  If I'm writing a hard real-time
> embedded system, I probably won't say "1..2**1000".
>
> But I'm not even allowedd to say "1..2**80" in any Ada compiler I know
> of, and I can't even count on "1..2**35" portably.  Sigh.

Good point. I like the idea of being able to create a new integer type 
without concern over details such as machine representation.

> - Bob 

Re: Ada exception block does NOT work?

[Martin Krischik]

Robert A Duff wrote:

> I'd use "Integer" for what Lisp calls "bignums" -- integers that can
> grow without bound (except of course you can run out of memory,
> but that's true of Strings and whatnot, too.  I'd call the integer type
> that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".

That's a universal integer in Ada - and indeed the universal integer is not
visible anywhere in Ada.

And integer ranges that can grow without bound are not disallowed in Ada. If
you want you can create an Ada implementation that works that way.

It's like the garbage collector - the Ada vendors didn't think its needed,

> And I wouldn't put it in a package called "Standard" and I wouldn't
> make it automatically visible everywhere.

Standard.Integer  is needed for Standard.String - There is no need to
support Strings which are larger then available memory.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[Martin Krischik]

Robert A Duff wrote:

> But I'm not even allowedd to say "1..2**80" in any Ada compiler I know
> of, and I can't even count on "1..2**35" portably.  Sigh.

Well GNAT allows 2*63. But the limits are indeed very low. I started with
8bit CPUs and one of the fist things you learn with 8bit CPUs is how to add
and subtract 16, 24, 32 etc pp values using the "carry bit". 

I don't think there is a real reason to restrict integers ranges.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[Frank J. Lhota]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message 
news:1227518.U5hWOOGjT8@linux1.krischik.com...
> It's because they used "signed int" for all file operations. Personally I
> consider that damm stupid - after all: have you ever seen a file with a
> negative size?
>
> Martin

There is some utility to a negative file offset, for example fseek. The real 
mistake was not using a typedef for the file sizes and file offsets.

> -- 
> mailto://krischik@users.sourceforge.net
> Ada programming at: http://ada.krischik.com 

Re: Ada exception block does NOT work?

[tmoran]

>     type Stack_Index is range 1..whatever;
>     subtype Stack_Count is Stack_Index'Base range 0..whatever;
Or
      type Stack_Count is range 0..whatever;
      subtype Stack_Index is Stack_Count range 1..Stack_Count'last;
which only has a single instance of "whatever".

Re: Ada exception block does NOT work?

[Simon Wright]

tmoran@acm.org writes:

>>     type Stack_Index is range 1..whatever;
>>     subtype Stack_Count is Stack_Index'Base range 0..whatever;
> Or
>       type Stack_Count is range 0..whatever;
>       subtype Stack_Index is Stack_Count range 1..Stack_Count'last;
> which only has a single instance of "whatever".

Well, Bob's could have been phrased that way too .. what I
particularly liked was the means of _extending_ the range.

Re: Ada exception block does NOT work?

[Hyman Rosen]

Frank J. Lhota wrote:
> The standard of the Vanilla, K&R C language "The C Programming Language" 
> first edition, does include unsigned integer types.

But the earliest C compilers didn't. I know, because I used one around
1979. My college was running a verly early version of UNIX on a PDP-11/45.
We had terminals that printed out on rolls of paper, upper-case only. In
addition to not having unsigned arithmetic, the compiler was primitive in
many other ways. For instance, no two structures (records, for you Ada
folks) could have a field with the same name if they were at different
offsets from the beginning. It didn't have unions either. It was quite
the occasion a couple of years later when we got a full K&R compiler
(and video display terminals, which even supported both cases!)

Re: Ada exception block does NOT work?

[bubble]

dear all :
I have commit the bug to GCC Bugzilla.
hope them to fix to problem in next release

I have test in objectAda 7.2.2 ,It is OK.
in objectAda , the max digits of price type must limit to 9.
and I do the same limit to GCC 4.1, the GCC pass the test.

Mmmm~   Interesting!....

Re: Ada exception block does NOT work?

[Martin Krischik]

Frank J. Lhota wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:1227518.U5hWOOGjT8@linux1.krischik.com...
>> It's because they used "signed int" for all file operations. Personally I
>> consider that damm stupid - after all: have you ever seen a file with a
>> negative size?
>>
>> Martin
> 
> There is some utility to a negative file offset, for example fseek.

I know - It was also a mistake to make a "do it all" fseek - There should
have been a fabsseek and frelseek - then there wouldn't have been a problem
with using unsigned long for file positions. But that's all water under the
bridge now.

> The 
> real mistake was not using a typedef for the file sizes and file offsets.

Well they have it now with fgetpos and fsetpos.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[Larry Elmore]

Martin Krischik wrote:
> Frank J. Lhota wrote:
> 
> 
>>Martin Krischik wrote:
>>
>>>Well, the very first C did not have "unsigned int" there was just int.
>>>That's why unix has a 2GB limit on files and not a 4 GB limit. (There is
>>>a new set of file IO which can deal with larger files).
>>
>>The standard of the Vanilla, K&R C language "The C Programming Language"
>>first edition, does include unsigned integer types. The old Unix file
>>size limit is probably due to other reasons.

I'm not sure that's necessarily the case.  After all, Unix predates K&R
and K&R C was certainly not the first version of C.

> It's because they used "signed int" for all file operations. Personally I
> consider that damm stupid - after all: have you ever seen a file with a
> negative size?
> 
> Martin

Re: Ada exception block does NOT work?

[Martin Krischik]

Dennis Lee Bieber wrote:

> On Mon, 22 Aug 2005 19:32:01 -0500, Larry Elmore <ljelmore_@comcast.net>
> declaimed the following in comp.lang.ada:
> 
>> 
>> I'm not sure that's necessarily the case.  After all, Unix predates K&R
>> and K&R C was certainly not the first version of C.
>>
> Pardon?
> 
> As I recall, Kernighan and Ritchie /defined/ the original C
> language... The original UNIX was Ritchie and Thompson (and some
> others)...

Well, K&R where programmers - so they likely first wrote the program (C
compiler) and and then the book. If you go to Amazon now they will offer
you the 2nd edition with ANSI-C.

So I guess that looking at he book won't tell you about the very first C.

The one without function prototypes - you just had to hope the parameters
are right (or use lint).

Just to remind you, main looked like this at the time

main (argn, argv, env)
  int argn,
  char** argv,
  char** env
  {
  puts ("Hello World");
  }

And yes: no include, the compiler would guess for you how to call puts.

> One would think Ritchie, at least, might have had some insights into
> the potential access problems <G> Even if there was a time-gap between
> the two roles.

No he would not. Otherwise he would not have added:

* implicit type conversion.
* implicit declaration of external functions.
* implicit convertion from array to pointer.
* implicit convertion from ponter to array.

And he might have added:

* an optimiser

K&R probably where good assember programmers but they where lousy compiler
builders. There was better (Algol, PL/1 etc. pp.) at the time.

Don't belive me. Well I have 5 years of C and 10 years of C++ experience and
now  I am an Ada advocate. I have an Ada job at the swiss post and I am
just loving it. It's just great! I hope I never have to code another line
of C/C++ code in my live. It can't remember the last time I started the
debugger. I might have tomorrow - there is some CONSTRAINT_ERROR to hunt
down. But hey - that's an event now: I might have to start the debugger -
uhh - huu - ;-). When I was doing C/C++ work I could not imagine a single
day without debugger.

Don't tell me that K&R know anything when they where creating C. They where
just feature geil (don't know any English word which translates geil
properly) adding features which should never have been added.

(sorry guys - just had my 5 minutes of irelevant ranting)

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: C history

[Björn Persson]

Martin Krischik wrote:
> Dennis Lee Bieber wrote:
> 
> 
>>On Mon, 22 Aug 2005 19:32:01 -0500, Larry Elmore <ljelmore_@comcast.net>
>>declaimed the following in comp.lang.ada:
>>
>>
>>>I'm not sure that's necessarily the case.  After all, Unix predates K&R
>>>and K&R C was certainly not the first version of C.
>>>
>>
>>Pardon?
>>
>>As I recall, Kernighan and Ritchie /defined/ the original C
>>language... The original UNIX was Ritchie and Thompson (and some
>>others)...
> 
> 
> Well, K&R where programmers - so they likely first wrote the program (C
> compiler) and and then the book. If you go to Amazon now they will offer
> you the 2nd edition with ANSI-C.
> 
> So I guess that looking at he book won't tell you about the very first C.

The Development of the C Language, by Dennis M. Ritchie:

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

A few points from that article which are relevant to this thread:

� Ritchie turned B into C during 1971 to 1973.
� The book was written in 1978 and includes a lot that wasn't in the 
language in 1973.
� The primary requirement on B seems to have been that the compiler had 
to fit in 8 KiB of memory.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada exception block does NOT work?

[Larry Elmore]

Dennis Lee Bieber wrote:
> On Mon, 22 Aug 2005 19:32:01 -0500, Larry Elmore <ljelmore_@comcast.net>
> declaimed the following in comp.lang.ada:
> 
> 
>>I'm not sure that's necessarily the case.  After all, Unix predates K&R
>>and K&R C was certainly not the first version of C.
>>
> 
> 	Pardon?
> 
> 	As I recall, Kernighan and Ritchie /defined/ the original C
> language... The original UNIX was Ritchie and Thompson (and some
> others)...

K&R C is generally accepted as the C described in the K&R book "The C
Programming Language" (the first edition, printed in 1978), which was
referenced in a section you snipped.  This was NOT the first version of
C, not by a long shot, and certainly not the C that the first several
versions of Unix were written in.

> 	One would think Ritchie, at least, might have had some insights into
> the potential access problems <G> Even if there was a time-gap between
> the two roles.

Please take a look at:
http://cm.bell-labs.com/cm/cs/who/dmr/primevalC.html

> 	As for C? Before K&R there was B.... And B was spawned from BCPL <G>

If you want to get picky, before B there was NB (New B), but its life
was extremely short.

--Larry

Re: Ada exception block does NOT work?

[Jeffrey R. Carter]

Larry Elmore wrote:

> If you want to get picky, before B there was NB (New B), but its life
> was extremely short.

No, NB was after B and before C.

-- 
Jeff Carter
"Crucifixion's a doddle."
Monty Python's Life of Brian
82

Re: Ada exception block does NOT work?

[Martin Krischik]

Larry Elmore wrote:

> Please take a look at:
> http://cm.bell-labs.com/cm/cs/who/dmr/primevalC.html

Great reading. And don't forget to have a look at the sources.

C had not only been hounded by patched-on-features right from the beginning
- it was a patched-on-feature itself ;-) .

Martin 

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada exception block does NOT work?

[Larry Elmore]

Jeffrey R. Carter wrote:
> Larry Elmore wrote:
> 
>> If you want to get picky, before B there was NB (New B), but its life
>> was extremely short.
> 
> 
> No, NB was after B and before C.

Yeah, that's what I meant to write.  Damn fingers...

Re: Ada exception block does NOT work?

[Jeffrey R. Carter]

Larry Elmore wrote:

> Yeah, that's what I meant to write.  Damn fingers...

That's what I figured, but accuracy is important in this business. Luckily you 
use a language whose compiler can detect these kinds of errors.

-- 
Jeff Carter
"Saving keystrokes is the job of the text editor,
not the programming language."
Preben Randhol
64

Re: Ada exception block does NOT work?

[Dave Thompson]

On Tue, 23 Aug 2005 20:09:06 +0200, Martin Krischik
<krischik@users.sourceforge.net> wrote:

> Dennis Lee Bieber wrote:
> 
> > On Mon, 22 Aug 2005 19:32:01 -0500, Larry Elmore <ljelmore_@comcast.net>
> > declaimed the following in comp.lang.ada:
> > 
> >> 
> >> I'm not sure that's necessarily the case.  After all, Unix predates K&R
> >> and K&R C was certainly not the first version of C.
> >>
> > Pardon?
> > 
> > As I recall, Kernighan and Ritchie /defined/ the original C
> > language... The original UNIX was Ritchie and Thompson (and some
> > others)...
> 
> Well, K&R where programmers - so they likely first wrote the program (C
> compiler) and and then the book. If you go to Amazon now they will offer
> you the 2nd edition with ANSI-C.
> 
> So I guess that looking at he book won't tell you about the very first C.
> 
AIUI Kernighan was a tech writer then, although I believe by the time
of awk he moved into programming, and AFAICT had nothing to do with
the first compilers.  It's true K&R1-thebook was several years after C
was created; others have already pointed to the HOPL2 article
available along with other historical information on dmr's website.

> The one without function prototypes - you just had to hope the parameters
> are right (or use lint).
> 
> Just to remind you, main looked like this at the time
> 
> main (argn, argv, env)
>   int argn,
>   char** argv,
>   char** env
>   {
>   puts ("Hello World");
>   }
> 
Not quite. The parameter/formal declarations are (and were) like
normal variable declarations terminated by semicolon not separated by
comma; the default int could be used for argc which I believe was the
conventional (though not mandatory) spelling even back to the
beginning; and I'm pretty sure env was never mandatory:
[int] main (argc, argv [,env] )
  [int argc;] char **argv; [char **env;]
  /* or (yuckier?) char **argv, **env; */
  /* change spacing to taste */
{ body }

And I believe even the first Unix C had main() returning an exit code,
for which the (accidental) return value of puts() would not be
suitable, so a 'return 0;' is necessary. 

> And yes: no include, the compiler would guess for you how to call puts.
> 
True the preprocessor was not as early as the first compiler, but it
was by the first outside Unix distributions (well before the book) and
thus I believe before stdio, so there were declarations to #include if
you wanted. If not, the compiler doesn't guess, it takes fixed and
simple defaults, and most of the standard library routines including
puts() were not so accidentally designed so this default was correct.

> > One would think Ritchie, at least, might have had some insights into
> > the potential access problems <G> Even if there was a time-gap between
> > the two roles.
> 
> No he would not. Otherwise he would not have added:
> 
> * implicit type conversion.

Most other languages of the time convert numeric types at least as
freely as C -- FORTRAN and COBOL definitely; PL/I even more so; I
don't recall for algol. Pascal some but less, and I don't think there
were yet BASICs that distinguished integer from float. Pascal did have
enums distinct from integers. C was unusual, AFAIK unique still, in
treating char as just a small integer, and string as just a char array
with sentinel, which allows some conversions other languages don't.

> * implicit declaration of external functions.
> * implicit convertion from array to pointer.

That third was not really added, it was effectively carried forward
from BCPL and never removed.  Implicit int and implicit function
declaration were also apparently driven by BCPL-B-NB compatibility.
(AFAICT they don't simplify the compiler at all, if anything the
reverse, and don't simplify learning or using the language.)

> * implicit convertion from ponter to array.
> 
That doesn't exist. Unless you mean access from a pointer to an array
_element_.

> And he might have added:
> 
> * an optimiser
> 
> K&R probably where good assember programmers but they where lousy compiler
> builders. There was better (Algol, PL/1 etc. pp.) at the time.
> 
Not on machines the size (and cost) of a PDP-11, I don't think. Pascal
with fairly minor restrictions was done on -11 (UCSD) but AIR not
until some years later. (Original Pascal, and later the standard,
don't include all the low-level bit-bashing stuff C needed as a SIL,
but that could easily enough have been added; heck, there were
Fortrans with enough extensions for that.)

- David.Thompson1 at worldnet.att.net