Typing in Ada

Typing in Ada

[Empit]

From typing point of view, how strong is Ada than C?

or

Which is the most strongly typed language.

Responses appreciated

Re: Typing in Ada

[Poul-Erik Andreasen]

On 31 May 2004 06:32:39 -0700
empit@rediffmail.com (Empit) wrote:

> From typing point of view, how strong is Ada than C?
> 
> or
> 
> Which is the most strongly typed language.

Ada. C is weak typed langauge. 


-- 
Poul-Erik Andreasen

http://www.linux-service.dk
http://www.pea.dk 

Re: Typing in Ada

[Jeffrey Carter]

Empit wrote:
> From typing point of view, how strong is Ada than C?
> 
> or
> 
> Which is the most strongly typed language.

Why not try them and see?

procedure Strongly_Typed is
    type I1 is new Integer;
    type I2 is new Integer;
    type I3 is range -100 .. 100;

    V1 : I1 := 3;
    V2 : I2 := 4;
    V3 : I3;
begin -- Strongly_Typed
    V3 := V1 + V2;
end Strongly_Typed;

C:\Code>gcc -c strongly_typed.adb
strongly_typed.adb:10:13: invalid operand types for operator "+"
strongly_typed.adb:10:13: left operand has type "I1" defined at line 2
strongly_typed.adb:10:13: right operand has type "I2" defined at line 3

int main () { /* I cannot call this Strongly_Typed */
    typedef int   I1;
    typedef int   I2;
    typedef short I3;

    I1 V1 = 3;
    I2 V2 = 4;
    I3 V3;

    V3 = V1 + V2;
    return 0;
}

C:\Code>gcc -c strongly_typed.c
[no messages]

Which do you think is more strongly typed?

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17

Re: Typing in Ada

[Peter C. Chapin]

Jeffrey Carter <spam@spam.com> wrote in news:mxJuc.18113$be.10152
@newsread2.news.pas.earthlink.net:

> procedure Strongly_Typed is
>     type I1 is new Integer;
>     type I2 is new Integer;
>     type I3 is range -100 .. 100;
[snip]
> 
> int main () { /* I cannot call this Strongly_Typed */
>     typedef int   I1;
>     typedef int   I2;
>     typedef short I3;

This isn't an entirely fair comparison because in C, typedef doesn't 
introduce a new type it simply creates a new name for an existing type. In 
Ada, it would be more similar to using a subtype, perhaps. Something like

     subtype I1 is Integer;

In any event to create a new type in C you need to introduce a structure. In 
fact, different structures do have different types:

typedef struct {
  int x;
} A;

typedef struct {
  int x;
} B;

int main()
{
  A a;
  B b;

  a = b;  // Error. A and B are different types.

  ...

I'm not sure if there is a formal definition of strong typing or not. I've 
always thought that it had to do with the property of every expression and 
variable having a well defined type. If so, that is as true of C as it is of 
Ada (in some ways its even more true of C because in C literal numbers have 
specific types... there is no "universal integer" type used, for example, for 
integer literals). The real difference is that C does a bunch of automatic 
type conversions and, furthermore, normally performs these conversions 
without checking if the converted value will fit into the target type. I'm 
not sure that's a strong typing issue, however.

Peter

Re: Typing in Ada

[tmoran]

>In any event to create a new type in C you need to introduce a structure. In
>fact, different structures do have different types:
  How would you do in C the equivalent of

  type Vars is (x,y);
  function Image(Var : Vars) return String is ...
  package Polys is new Multinom(Vars, Image);
  use Polys;

  A : Polys.Multinomials
        := X**4 + 2.0*x**3*y**1 + 3.0*x**2*y**2 + 4.0*x**1*y**3 + 5.0*y**4;
  B : Polys.Multinomials := x**2 - 2.0*x**1*y**1 + y**2;
  ...
  Put_Line("Product is " & Image(A*B));

Re: Typing in Ada

[Peter C. Chapin]

tmoran@acm.org wrote in news:_KOuc.24339$IB.6225@attbi_s04:

>   How would you do in C the equivalent of
> 
>   type Vars is (x,y);
>   function Image(Var : Vars) return String is ...
>   package Polys is new Multinom(Vars, Image);
>   use Polys;
> 
>   A : Polys.Multinomials
>         := X**4 + 2.0*x**3*y**1 + 3.0*x**2*y**2 + 4.0*x**1*y**3 + 5.0
*y**4;
>   B : Polys.Multinomials := x**2 - 2.0*x**1*y**1 + y**2;
>   ...
>   Put_Line("Product is " & Image(A*B));

Are you asking me to show you symbolic polynomical manipulation code in C? 
I don't understand how that bears on the question of how strongly typed C 
is. In any case your example uses features like generic instantiation and 
operator overloading that could be more directly mapped to C++. Would you 
say that C++ is more strongly typed than C?

Peter

Re: Typing in Ada

[tmoran]

>>   type Vars is (x,y);
>>   A : Polys.Multinomials
>>         := X**4 + 2.0*x**3*y**1 + 3.0*x**2*y**2 + 4.0*x**1*y**3 + 5.0
>Are you asking me to show you symbolic polynomical manipulation code in C?
  You miss the point.  If Vars was an enumeration type in C, an expression
like "X**4 + 2.0*x**3*y**1"...  would result in some floating point value.
Without types, it wouldn't even begin to invoke the necessary operator
overloading function calls.

>In any case your example uses features like generic instantiation and
>operator overloading that could be more directly mapped to C++. Would you
>say that C++ is more strongly typed than C?
  I assumed by "C" you really meant something newer, like "C++".  In "C"
"the only operations that you can perform on a structure are take its
address with &, and access one of its members."  (The C Programming
Language, Kernighan and Ritchie).
  In any case, I'd be curious to see how you would write the above in C++.

Re: Typing in Ada

[Peter C. Chapin]

tmoran@acm.org wrote in news:XMTuc.35148$n_6.31103@attbi_s53:

>   I assumed by "C" you really meant something newer, like "C++".  In "C"
> "the only operations that you can perform on a structure are take its
> address with &, and access one of its members."  (The C Programming
> Language, Kernighan and Ritchie).
>   In any case, I'd be curious to see how you would write the above in C++.

C++ supports operator overloading as applied to enums. It doesn't have an 
exponentiation operator, however, and you can't create new operators so that 
would create a technical inconvenience in this case. Off hand I'm not sure 
how one would create a function template in C++ that could take an 
enumeration type and print the names of the enumerators. I wouldn't want to 
say it's impossible though. In any case I'm not sure how that's related to 
the issue of strong typing.

Peter

Re: Typing in Ada

[Dave Thompson]

On Tue, 01 Jun 2004 11:26:30 GMT, "Peter C. Chapin"
<pchapin@sover.net> wrote:

> tmoran@acm.org wrote in news:XMTuc.35148$n_6.31103@attbi_s53:
> 
> >   I assumed by "C" you really meant something newer, like "C++".  In "C"
> > "the only operations that you can perform on a structure are take its
> > address with &, and access one of its members."  (The C Programming
> > Language, Kernighan and Ritchie).

If you are reading the first edition aka "K&R1", that is out of date.
Since the early '80s and in particular in C89 and later, you can also
assign a (whole, fixed size) struct, and as a logical consequence pass
it as an argument (all arguments are by value in C) or return it as a
function value. But yes only in C++ can you overload on struct types,
or indeed any other.

> >   In any case, I'd be curious to see how you would write the above in C++.
> 
Sorry I'm only online intermittently so I couldn't download the
previous reference in reasonable time. I'm responding on the
assumption it manipulates and displays (representations of)
polynomials in something like the obviously (to me) implied way.

> C++ supports operator overloading as applied to enums. It doesn't have an 
> exponentiation operator, however, and you can't create new operators so that 
> would create a technical inconvenience in this case. Off hand I'm not sure 

You could overload enum varid ^ int exponent, since there would be no
use here for the usual C and C++ meaning as exclusive-or, but it has
rather low precedence with the other bitwise operators (which can't be
changed) hence couldn't be used as conveniently.

> how one would create a function template in C++ that could take an 
> enumeration type and print the names of the enumerators. I wouldn't want to 
> say it's impossible though. In any case I'm not sure how that's related to 
> the issue of strong typing.
> 
You can't; enum names are solely compile time in both C and C++,
except for nonstandard and (very) platform-dependent debugging. What
you can do is a preprocessor trick, something like:

#define Vars_List Var1(X) Var1(Y) Var1(Z)
#define Var1(id) id , /* in enum definition */
enum Vars { Vars_List }; /* note trailing comma allowed in C99, 
in unextended C89 have to hack this slightly or add a dummy name, 
which can actually be useful anyway for idiomatic half-open [0,N) */
#undef Var1
#define Var1(id) # id , /* in table of names */
const char * Vars_names [] = { Vars_List };
#undef Var1
/* now Y=1 and Vars_names[Y] is the string "Y" etc. */

Alternatively, instead of actual enum values, you could in C++ define
and use instances of a class type that collapse into the needed data:

class Term { 
  int varid, expon; double factor;
public:
  /*ctor*/ Term (int varid) 
    : varid (varid), expon (1), factor (1.0) { }
  /* could use a Freevar method that doublechecks varid is in the 
    valid range, known at startup but not compiletime; but if this 
    is made private and the Freevar method a friend, 
    invalid calls are prevented at compile time barring cheating */

  Term& operator^= (int expon) 
    { this->expon *= expon; return *this; }
  Term  operator^  (int expon) 
    { Term that (*this); return that ^= expon; }
  Term& operator*= (double factor) 
    { this->factor *= factor; return *this; }
  Term  operator*  (double factor) 
    { Term that (*this); return that *= factor; }

};

class Freevar {
/*private:*/
typedef std::vector <const char *> var_names_t;
static var_names_t var_names;
  int varid;
public:
  /*ctor*/ Freevar (const char *this_name) 
    /* save name-string and "return" subscript thereto */
    { 
      var_names_t::iterator new_item =
        var_names.insert (var_names.end(), this_name); 
      this->varid = new_item - var_names.begin();
    }
static const char * get_name (int id) 
    { return var_names [id]; /* or safer .at(id) */ }
  /*conversion*/ operator Term () const 
    { return Term (this->varid); }
  /*converting*/ Term operator^ (int expon) const 
    { return Term (*this) ^ expon; }
};
Freevar::var_names_t Freevar::var_names; /* "initialize" */
const Freevar X ("X"); /* gets id 0 */
const Freevar Y ("Y"); /* gets id 1 */
const Freevar Z ("Z"); /* gets id 2 */
/* these particular id values guaranteed only if all (static) 
  definitions in same source file/module; if in separate modules 
  they will be unpredictable but unique, which is enough */

Now Y ^ 3 yields a Term containing an exponent of 3 for id 1, and say
Term::output can use Freevar::get_name (1) to get "Y".

If you want to do this for multiple "enums" I think you can templatize
it but I haven't worked that one out in detail.

Or as a real hack you could make the values (singleton instances of)
classes that inherit with at least one virtual method, thereby
providing RTTI (Run-Time Type Information) whose implementation
dependent values you then decode somehow. Yuck.

It probably should (but won't) go without saying that this is more
work and less simple than built-in compiler support as in Ada.

Additional minor point: in C you can't really return a string as a
function value. You must either store into a caller-provided buffer;
return a pointer to static space (not threadsafe and dubious if used
multiple times); or return a pointer to allocated space (caller must
free). In C++ you can return a std::string; (in practice though not
formally required) this is really a pointer to heap space, but is
managed automatically.

- David.Thompson1 at worldnet.att.net

Re: Typing in Ada

[Dave Thompson]

On Tue, 01 Jun 2004 01:09:41 GMT, "Peter C. Chapin"
<pchapin@sover.net> wrote:

> tmoran@acm.org wrote in news:_KOuc.24339$IB.6225@attbi_s04:
> 
> >   How would you do in C the equivalent of
<snip>
> Are you asking me to show you symbolic polynomical manipulation code in C? 
> I don't understand how that bears on the question of how strongly typed C 
> is. In any case your example uses features like generic instantiation and 
> operator overloading that could be more directly mapped to C++. Would you 
> say that C++ is more strongly typed than C?
> 
Slightly. In C enum types simply are integer types; in C++ they are
distinct, though it will silently convert an enum _to_ an integer (not
the reverse). And C++ makes character literals type char instead of
type int, so overloading on that type has some hope of being usable. 
(Although char still is, and promotes as, an integer type.)

And it does not allow silent conversions _from_ pointer-to-void (which
is the moral equivalent of System.Address) to other (data) pointers.
(This is actually a specific case of not allowing conversions "down"
the class hierarchy, which in general does not apply to C.)

And finally, though people don't always think of it as typing, C++
requires the "new" style declaration of routines/methods with
parameters specified so calls, and pointers-to-function (and pmfs) if
used, can be fully checked*; C supports this but also allows the old
K&R1 FORTRANish function-of-you-must-know-the-args. For that matter,
C++ and C99, unlike C89 and earlier, no longer have implicit
declarations of functions, as taking unspecified arguments and
returning int; this isn't really a typing issue, as an implicitly
declared function actually has the same type, and gets the same
(limited) checking, as an equivalent explicit declaration, but lack of
a visible, checkable, and modifiable declaration makes it seem so.

* except for varargs -- and C++ default arguments and overloading
allow better alternatives in many cases to varargs.

- David.Thompson1 at worldnet.att.net

Re: Typing in Ada

[Nick Roberts]

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns94FAA347BFEA8pchapinsovernet@207.106.93.237...

> ...
> This isn't an entirely fair comparison because in C,
> ...
>
> I'm not sure if there is a formal definition of strong
> typing or not.
> ...

Hehe. I'll think one would find, in practice, that most Ada programs tend to
be far more strongly typed than C programs. That is to say that in most Ada
programs it is typical to have constructions such as:

   type Apples is range 0..100;
   type Oranges is range 0..200;

   A: Apples;
   O: Oranges;

whereas in typical C programs you either get:

   typedef int Apples;
   typedef int Oranges;

   Apples a;
   Oranges o;

or more often than not simply:

   int a;
   int o;

In either case, in Ada, the easy mistake:

   A := O;

will be caught by the compiler, whereas in either of the C constructions:

   a = o;

will not.

I think this is the important point about 'strong' typing. It is one aspect
of the basic principle that the more information you give the compiler, the
more bugs it can catch for you.

One more point. I encourage Ada programmers to use the style, where
appropriate, of declaring the type of a literal by using a qualification.
For example, suppose we know there is an 'Eat' procedure for Apples (but we
are perhaps unsure whether Oranges has an 'Eat' or not). To eat ten apples,
it would be prudent to write:

   Eat( Apples'(10) ); -- (1)

rather than just:

   Eat( 10 ); -- (2)

because if it so happens that there is an 'Eat' for Oranges, and it also so
happens that the Eat for Apples has got hidden or commented out or whatever,
the compiler would catch (1), but it would wrongly eat 10 oranges if we
simply wrote (2). Of course, if boths Eats exist and are directly visible,
the qualification would be one way to disambiguate the call.

-- 
Nick Roberts

Re: Typing in Ada

[Peter C. Chapin]

"Nick Roberts" <nick.roberts@acm.org> wrote in
news:2i1t1lFij4g5U1@uni-berlin.de: 

> Hehe. I'll think one would find, in practice, that most Ada programs
> tend to be far more strongly typed than C programs. That is to say that
> in most Ada programs it is typical to have constructions such as:
> 
>    type Apples is range 0..100;
>    type Oranges is range 0..200;
> 
>    A: Apples;
>    O: Oranges;
> 
> whereas in typical C programs you either get:
> 
>    typedef int Apples;
>    typedef int Oranges;
> 
>    Apples a;
>    Oranges o;

Yes, Ada provides ranges as distinct types without automatic conversions 
and that's a nice feature. In theory you could get some of the same 
benifits in C by introducing an abstract type (as a structure) to hold a 
range. It could be done much more nicely in C++ using templates, 
overloaded operators, and other C++ features. The reality is, though, that 
many C (or C++) programs don't bother. Perhaps they should.

It's not clear to me how all this relates to the concept of strong typing. 
I guess it would be helpful to have a precise definition of that term. It 
sounds like from what we've said here that strong typing more a matter of 
programming style than a language feature... at least where C and Ada are 
concerned. Is that a valid conclusion?

Peter

Re: Typing in Ada

[Nick Roberts]

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns94FAD66E1E08Bpchapinsovernet@207.106.92.237...

> ...
> It's not clear to me how all this relates to the concept of strong
> typing.

I think technically strong typing is about explicit type conversion, so
that:

   A := O;
   ... A+O ...

is not permitted, and one has to write:

   A := Apples(O);
   ... A+Apples(O) ...

instead. I think this is the definition generally adopted in computer
science.

> I guess it would be helpful to have a precise definition of that term.
> It sounds like from what we've said here that strong typing more a
> matter of programming style than a language feature ...

I would certainly say that that is where it matters. It doesn't matter if a
programmer language has some wonderful feature if, in practice, nobody ever
uses it.

> ... at least where C and Ada are concerned. Is that a valid
> conclusion?

It seems reasonable to suppose that if C had always included a convenient
facility for introducing differentiated types, this facility would have been
used in practice. I think you will find the following paper (it's a PDF)
very interesting with regard to the ongoing arguments about introducing such
a facility to SQL:

   http://www.jeffsutherland.com/x3h2/97-094.pdf

-- 
Nick Roberts

Re: Typing in Ada

[Robert I. Eachus]

Peter C. Chapin wrote:

> Yes, Ada provides ranges as distinct types without automatic conversions 
> and that's a nice feature. In theory you could get some of the same 
> benifits in C by introducing an abstract type (as a structure) to hold a 
> range. It could be done much more nicely in C++ using templates, 
> overloaded operators, and other C++ features. The reality is, though, that 
> many C (or C++) programs don't bother. Perhaps they should.
> 
> It's not clear to me how all this relates to the concept of strong typing. 
> I guess it would be helpful to have a precise definition of that term. It 
> sounds like from what we've said here that strong typing more a matter of 
> programming style than a language feature... at least where C and Ada are 
> concerned. Is that a valid conclusion?

I guess the real difference between C (or C++) and Ada is that Ada has 
many features you get "for free" at compile time if you use strong 
typing.  The most visible of these in Ada is overloading and overload 
resolution.  To extend the Apples and Oranges example, if I define

type Apple is (McIntosh, Granny_Smith, Winesap, Golden_Delicious,...);
type Orange is (Valencia, Navel, Mandarin, Seville, Bergamot...);

then

Eat(McIntosh); -- will call the Eat function for Apples, and
Eat(Navel);
  -- will call the Eat function for Oranges, and peel it first. ;-)

The most important benefit of this is that if a procedure or functions 
has a multitude of parameters some possibly with defaults, when 
programming in Ada, you don't have to "validate" the call against the 
function template.  The compiler will do that for you, and detect most 
errors.

Of course, if you write "C := A - B;" when you meant "C := B - A;"  the 
compiler probably won't catch that.  However there are cases where it 
will.  For example, Ada.Calendar defines:

   function "-" (Left : Time;   Right : Duration) return Time;
   function "-" (Left : Time;   Right : Time) return Duration;

But no operation for subtracting Time from Duration.  So Ada would catch 
a call to the first "-" with the parameters in the wrong order, but 
could not detect such an inversion if the parameters were both of type 
Time.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Typing in Ada

[Hyman Rosen]

Robert I. Eachus wrote:
> type Apple is (McIntosh, Granny_Smith, Winesap, Golden_Delicious,...);
> type Orange is (Valencia, Navel, Mandarin, Seville, Bergamot...);
> Eat(McIntosh);
> Eat(Navel);

Actually, if you emulate Ada's notion that enumeration literals
are functions which return their value, this carries over directly
into C++:

enum Apple_e { };
typedef Apple_e Apple(Apple_e);
Apple McIntosh, Granny_Smith, Winesap, Golden_Delicious, Hybrid;
void Eat(Apple);
void EatApple(Apple);

enum Orange_e { };
typedef Orange_e Orange(Orange_e);
Orange Valencia, Navel, Mandarin, Seville, Bergamot, Hybrid;
void Eat(Orange);
void EatOrange(Orange);

int main()
{
     Eat(McIntosh);
     Eat(Navel);
     EatApple(Hybrid);
     EatOrange(Hybrid);
}

Re: Typing in Ada

[Hyman Rosen]

Nick Roberts wrote:
 > That is to say that in most Ada
> programs it is typical to have constructions such as:
>    type Apples is range 0..100;
>    type Oranges is range 0..200;

Is it really? The very fact that you have named these types as
you did suggests that the appplicability of ranged types is quite
limited. In a real program that does something useful, what kinds
of things do you want to count up to 100 but not to 101? To 200
but not to 201? Can you give examples from some of your real code?

> In either case, in Ada, the easy mistake:
>    A := O;
> will be caught by the compiler, whereas in either of the C constructions:
>    a = o;
> will not.

I think it's more likely that a type with a limited number of
values would be represented as an enumeration, in which case
the errant construct would be caught by C as well.

Re: Typing in Ada

[Larry Kilgallen]

In article <9ZRuc.8410$hB2.7017@nwrdny03.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
> Nick Roberts wrote:
>  > That is to say that in most Ada
>> programs it is typical to have constructions such as:
>>    type Apples is range 0..100;
>>    type Oranges is range 0..200;
> 
> Is it really? The very fact that you have named these types as
> you did suggests that the appplicability of ranged types is quite
> limited. In a real program that does something useful, what kinds
> of things do you want to count up to 100 but not to 101? To 200
> but not to 201? Can you give examples from some of your real code?

Apples and Oranges are typically used in discussions, but limiting
the range from 0 to 101 is quite common if you are counting votes
in the US Senate.  Or 0 to 100 and treat the tiebreaker situation
like the special case that it is.

A count of 0 to 435 (437?) House votes likewise has limited range,
and there is no situation in which the two are to be added (unlike
the corresponding Massachusetts State Government votes).

Re: Typing in Ada

[Hyman Rosen]

Larry Kilgallen wrote:
> Apples and Oranges are typically used in discussions, but limiting
> the range from 0 to 101 is quite common if you are counting votes
> in the US Senate.  Or 0 to 100 and treat the tiebreaker situation
> like the special case that it is.

Until Puerto Rico (or Iraq!) becomes a state.

> A count of 0 to 435 (437?) House votes likewise has limited range,
> and there is no situation in which the two are to be added (unlike
> the corresponding Massachusetts State Government votes).

Yes, you're safer there, since that number will not change even if a
new state is added.

Nevertheless, I submit that your examples actually demonstrate my
point more than they do yours.

Re: Typing in Ada

[Wes Groleau]

Dennis Lee Bieber wrote:
> On Tue, 01 Jun 2004 02:36:53 GMT, Hyman Rosen <hyrosen@mail.com>

>>limited. In a real program that does something useful, what kinds
>>of things do you want to count up to 100 but not to 101? To 200
> 
> 
> 	[snip good example]

A person's age; you may not know where to put the limit,
but you know you need to do additional checking if you
see 200.

> 	Angular measurements: 0..360 (though likely you'd want some
> floating point type with an upper bound one "step" below 360.0)

If I wanted all responses to be "normalized," I would override
the operators to make it a "modular" float.

But the point of strong typing is that you can't inadvertently
add an Age to the measure of angle AGE.

More important to me than strong typing is abstraction--the
ability to define types whose properties match what they
represent--instead of just being new names for 'int' or 'float'

When these types are numeric in nature, Ada's deriving and subtyping
mechanisms make this simple.  In C/C++/Java you have to do a lot more
work to get the same behavior.  In Java, you CAN'T get the same behavior
with reasonable syntax, since operators are banned from such types.

-- 
Wes Groleau
Alive and Well
http://freepages.religions.rootsweb.com/~wgroleau/

Re: Typing in Ada

[Niklas Holsti]

Hyman Rosen wrote:
> Nick Roberts wrote:
>  > That is to say that in most Ada
> 
>> programs it is typical to have constructions such as:
>>    type Apples is range 0..100;
>>    type Oranges is range 0..200;
> 
> 
> Is it really? The very fact that you have named these types as
> you did suggests that the appplicability of ranged types is quite
> limited. In a real program that does something useful, what kinds
> of things do you want to count up to 100 but not to 101? To 200
> but not to 201? Can you give examples from some of your real code

I'm not the original poster, but here are some examples from real code. 
I am implementing the mass memory subsystem for a satellite. The mass 
memory is divided into blocks, pages and octets. There are absolute 
address in the range 0 .. (total number of octets - 1), block numbers in 
the range 0 .. (total number of blocks - 1), page numbers likewise, 
octet offsets within a page, etc, etc. Using strong integer typing I can 
make the compiler check that I don't, by mistake, try to add a page 
number to an octet offset or do other equally senseless things.

To return to Nick Robert's example, the numbers 100 and 200 should 
either come from the requirements specification ("The program shall be 
able to count  up to 100 apples and 200 oranges...") or should appear in 
the software user manual ("The program can count up to 100 apples and 
200 oranges"). So then it is clear that the program satisfies its 
requirements (or it won't compile) and satisfies its user manual, 
whatever range Standard.Integer has on the current platform.

Niklas Holsti

Re: Typing in Ada

[Wes Groleau]

Niklas Holsti wrote:
> To return to Nick Robert's example, the numbers 100 and 200 should 
> either come from the requirements specification ("The program shall be 
> able to count  up to 100 apples and 200 oranges...") or should appear in 
> the software user manual ("The program can count up to 100 apples and 
> 200 oranges"). So then it is clear that the program satisfies its 
> requirements (or it won't compile) and satisfies its user manual, 
> whatever range Standard.Integer has on the current platform.

In a way, you are correct.  But why must we put
so much effort into preventing behavior that is
not prohibited just because it is not required?

Does the specification say ... ?
   "The program shall not tolerate apple counts higher than 100"

Did some domain expert persuade the programmers that 101 apples
was not reasonable?

In other words, when a specification says
"A count of 100 must be supported,"  the
programmers should NOT mentally rewrite it
to "Counts larger than 100 must not be supported."

-- 
Wes Groleau
Free Genealogical Lookups:
http://groleau.freeshell.org/ref/lookups.shtml

Re: Typing in Ada

[Robert I. Eachus]

Wes Groleau wrote:

> In a way, you are correct.  But why must we put
> so much effort into preventing behavior that is
> not prohibited just because it is not required?
> 
> Does the specification say ... ?
>   "The program shall not tolerate apple counts higher than 100"
> 
> Did some domain expert persuade the programmers that 101 apples
> was not reasonable?
> 
> In other words, when a specification says
> "A count of 100 must be supported,"  the
> programmers should NOT mentally rewrite it
> to "Counts larger than 100 must not be supported."

There are two issues here.  The first I just posted about.  If the 
requirements document is meaningful and maintained, the question about 
101 Apples needs to get asked, and answered.

Second, when the answer is that it should be read as "Count at least 100 
Apples," then the following coding "trick" is very useful:

type Required_Apples is range 0..100; -- 1..100 was pretty dodgy too...
type Apple is range 0..Required_Apples'Base'Last;

That allows software range checking to be omitted at least on the upper 
bound, and the real upper bound is set to whatever the hardware supports 
for the type chosen by the compiler for Required_Apples.

It also makes clear what the requirement being satisfied is.

Incidently you can vary this technique and make either Required_Apples a 
subtype of some integer type, or make Apples a subtype of 
Required_Apples.  There are cases when one or the other is more appropriate.


-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Typing in Ada

[tmoran]

>Second, when the answer is that it should be read as "Count at least 100
>Apples," then the following coding "trick" is very useful:
>
>type Required_Apples is range 0..100; -- 1..100 was pretty dodgy too...
>type Apple is range 0..Required_Apples'Base'Last;
>
>That allows software range checking to be omitted at least on the upper bound,
  OTOH, it means you don't know what the actual upper bound is.  More than
once during testing I've gotten something like "Constraint_Error,
offending value = 101".  If you used
type Apple_Count is range 0 .. 100;
type Orange_Count is range 0 .. 101;
then you immediately know the problem is an overflowing apple count, not
an orange count.  An "offending value = 256" would be less informative.

Re: Typing in Ada

[Wes Groleau]

Robert I. Eachus wrote:
> Wes Groleau wrote:
> 
>> In a way, you are correct.  But why must we put
>> so much effort into preventing behavior that is
>> not prohibited just because it is not required?
> 
> There are two issues here.  The first I just posted about.  If the 
> requirements document is meaningful and maintained, the question about 
> 101 Apples needs to get asked, and answered.

I wholeheartedly agree that the code should reflect the requirements
documents whenever feasible. (Also that systems engineers should use 
abstractions and stop filling requirements documents with implementation
details, but that's a different soapbox!)

And your "trick" which

> ... allows software range checking to be omitted at least on the upper 
> bound, and the real upper bound is set to whatever the hardware supports 
> for the type chosen by the compiler for Required_Apples.

is excellent and definitely

... makes clear what the requirement being satisfied is.

My side rant was inspired by the number of times I have
fixed defects and/or supported "new" requirements by stripping
out code which had no value beyond preventing the program from
exceeding its perceived requirements.  :-)

-- 
Wes Groleau

    A UNIX signature isn't a return address, it's the ASCII equivalent
    of a black velvet clown painting.  It's a rectangle of carets
    surrounding a quote from a literary giant of weeniedom like
    Heinlein or Dr. Who.
                                 -- Chris Maeda

    Ha, ha, Dr. ..... Who's Chris Maeda?
                                 -- Wes Groleau

Re: Typing in Ada

[Marin David Condic]

Sometimes its an issue for verification. High reliability systems often 
prohibit the inclusion of any code that is not necessary to meet a 
requirement because it presents an opportunity to introduce an error 
that would not need to occur because there is no requirement to do this. 
So a similar argument can be made for restricting the number of apples 
even if the spec doesn't say Thou Shalt Not Count 101 Apples. Kind of a 
case of avoiding building the proverbial brick outhouse - don't make it 
do anything more than is required because you can't then be sure it will 
handle those cases correctly.

But then again, there are few of those sort of systems and far many more 
of the type where this would not be an issue. Then saying "At minimum, 
100 apples must be supported..." is fine and if the programmer gives you 
2**32 apples, it probably doesn't hurt anything.

MDC


Wes Groleau wrote:
> 
> In a way, you are correct.  But why must we put
> so much effort into preventing behavior that is
> not prohibited just because it is not required?
> 
> Does the specification say ... ?
>   "The program shall not tolerate apple counts higher than 100"
> 
> Did some domain expert persuade the programmers that 101 apples
> was not reasonable?
> 
> In other words, when a specification says
> "A count of 100 must be supported,"  the
> programmers should NOT mentally rewrite it
> to "Counts larger than 100 must not be supported."
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: gratuitous restrictions (was:Typing in Ada)

[Wes Groleau]

Marin David Condic wrote:

> Sometimes its an issue for verification. ....
> .... case of avoiding building the proverbial brick outhouse - don't make it 
> do anything more than is required because you can't then be sure it will 
> handle those cases correctly.

Yes, in cases like this, such a construct may be justified.
But here there is a derived requirement to _not_ go over.

What bothers me is wasting time implementing restrictions that
are not required and add no value (not even in readability).

Especially when the restrictions one is implementing include
code complexity, _increasing_ the chance for bugs.

-- 
Wes Groleau
    "Would the prodigal have gone home if
     the elder brother was running the farm?"
                       -- James Jordan

Re: Typing in Ada

[Robert I. Eachus]

Niklas Holsti wrote:

> To return to Nick Robert's example, the numbers 100 and 200 should 
> either come from the requirements specification ("The program shall be 
> able to count  up to 100 apples and 200 oranges...") or should appear in 
> the software user manual ("The program can count up to 100 apples and 
> 200 oranges"). So then it is clear that the program satisfies its 
> requirements (or it won't compile) and satisfies its user manual, 
> whatever range Standard.Integer has on the current platform.

Amen! It would be nice if one tenth the energy that has gone into the 
thread started by a misunderstanding about whether Ada was being used in 
the 7E7 project went into evangelizing simple fundamental points like 
this.  Then no matter what programming language was used, the software 
would have a much better chance of being right.  It is not a selling 
point that Ada makes it easier to trace requirements, unless the person 
you are selling to understands why requirements traceability is important.

Yes, this is an advantage of Ada.  But before you can sell Ada, you need 
people to understand why requirements documents, software development 
plans and software user manuals are important living documents that need 
to be maintained interactively during software development.

Anyone who thinks that the requirements document shouldn't be changed 
during the software development stage hasn't worked on a real project. 
There are going to be some "boilerplate" pages in requirements document. 
  But outside of those, you should expect to add a page or more of 
footnotes to each page in the original requirements document.  These 
should note "derived" requirements which are a consequence of the 
implementation chosen, clarifications of requirements, and any really 
actual changes in requirements agreed to by all parties. I've called 
them footnotes, but only because the requirements document may also be a 
legal contract.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Typing in Ada

[David C. Hoos]

But both examples for C disregard the fact that int, enum,
and char can be freely mixed, something that Ada would
never allow.

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns94FAA347BFEA8pchapinsovernet@207.106.93.237...
> Jeffrey Carter <spam@spam.com> wrote in news:mxJuc.18113$be.10152
> @newsread2.news.pas.earthlink.net:
>
> > procedure Strongly_Typed is
> >     type I1 is new Integer;
> >     type I2 is new Integer;
> >     type I3 is range -100 .. 100;
> [snip]
> >
> > int main () { /* I cannot call this Strongly_Typed */
> >     typedef int   I1;
> >     typedef int   I2;
> >     typedef short I3;
>
> This isn't an entirely fair comparison because in C, typedef doesn't
> introduce a new type it simply creates a new name for an existing type. In
> Ada, it would be more similar to using a subtype, perhaps. Something like
>
>      subtype I1 is Integer;
>
> In any event to create a new type in C you need to introduce a structure.
In
> fact, different structures do have different types:
>
> typedef struct {
>   int x;
> } A;
>
> typedef struct {
>   int x;
> } B;
>
> int main()
> {
>   A a;
>   B b;
>
>   a = b;  // Error. A and B are different types.
>
>   ...
>
> I'm not sure if there is a formal definition of strong typing or not. I've
> always thought that it had to do with the property of every expression and
> variable having a well defined type. If so, that is as true of C as it is
of
> Ada (in some ways its even more true of C because in C literal numbers
have
> specific types... there is no "universal integer" type used, for example,
for
> integer literals). The real difference is that C does a bunch of automatic
> type conversions and, furthermore, normally performs these conversions
> without checking if the converted value will fit into the target type. I'm
> not sure that's a strong typing issue, however.
>
> Peter
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>

Re: Typing in Ada

[Jeffrey Carter]

Peter C. Chapin wrote:

> This isn't an entirely fair comparison because in C, typedef doesn't 
> introduce a new type it simply creates a new name for an existing type. In 
> Ada, it would be more similar to using a subtype, perhaps. Something like

The number of ways in which a language allows errors to be detected at 
compilation time because of erroneous type mixing is the essence of 
strong typing. Ada is more strongly typed than Pascal because of its 
ability to define new numeric types (among other things). The ability to 
define new numeric types is a way that Ada allows the compiler to detect 
errors that C lacks. Thus, the example is a perfectly good example of 
Ada being more strongly typed than C, and a fair comparison of the 
strength of typing in the 2 languages.

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

Re: Typing in Ada

[Peter C. Chapin]

Jeffrey Carter <spam@spam.com> wrote in
news:Q4avc.18446$Tn6.11146@newsread1.news.pas.earthlink.net: 

>> This isn't an entirely fair comparison because in C, typedef doesn't 
>> introduce a new type it simply creates a new name for an existing type.
>> In Ada, it would be more similar to using a subtype, perhaps. Something
>> like 
> 
> The ability to 
> define new numeric types is a way that Ada allows the compiler to detect
> errors that C lacks. Thus, the example is a perfectly good example of 
> Ada being more strongly typed than C, and a fair comparison of the 
> strength of typing in the 2 languages.

I guess my point was that in C typedef does not even attempt to define a 
new type so comparing it to Ada's 'type' declaration seems unfair. For 
example if you replace the type declarations in the OP's example with 
unconstrained subtype declarations, the OP's Ada program compiles with no 
complaints just like the the example C program using typedef does.

Now in C there *is* a mechanism for creating new types... it's just that 
typedef isn't it. Thus it would be more appropriate to compare an Ada 
program that introduces a new type that is a numeric range to a C program 
that implements numeric ranges as structs. There is no doubt that the Ada 
way of creating ranged types is easier and cleaner than any kind of 
"equivalent" solution in plain C might be. On the other hand, I'm sure C++ 
could do a much better job of emulating the Ada solution by using 
templates and overloaded operators.

In any case, the OP's example didn't seem like a good example of how Ada 
is more strongly typed than C. It is certainly true that Ada does not do 
automatic type conversions the way C does, but the OP's example doesn't 
illustrate that point. In contrast, when I think about a weakly typed 
language I think about languages like AWK, the shell scripting languages, 
or perhaps Perl... where the type of a variable shifts around depending on 
how it is used. For example:

#!/bin/bash
COUNT=1
echo "COUNT is now $COUNT"   # Treat COUNT as a string
COUNT=$(($COUNT + 1))        # Treat COUNT as a number
echo "COUNT is now $COUNT"

Peter

Re: Typing in Ada

[Marin David Condic]

You may be right about structs, but making the argument that because C 
can introduce a new type that it is therefore a strongly typed language 
doesn't seem to follow. Ada won't let you assign a character to an 
integer. C will. While a typedef example may not be 100% equivalent to 
an Ada type, that doesn't cause C to be strongly typed - which was the 
original point.

I'd also observe that just because there is a secret handshake that will 
get C to complain about type compatibility doesn't mean much. Following 
that logic, an assembler program can be made to complain about type 
compatibility (at least at runtime) if you want to do enough work. The 
problem is that typedef doesn't do what one who is acustomed to Ada 
would think it should: "type" - "def" - Define a type.

MDC


Peter C. Chapin wrote:
> 
> I guess my point was that in C typedef does not even attempt to define a 
> new type so comparing it to Ada's 'type' declaration seems unfair. For 
> example if you replace the type declarations in the OP's example with 
> unconstrained subtype declarations, the OP's Ada program compiles with no 
> complaints just like the the example C program using typedef does.
> 
> Now in C there *is* a mechanism for creating new types... it's just that 
> typedef isn't it. Thus it would be more appropriate to compare an Ada 
> program that introduces a new type that is a numeric range to a C program 
> that implements numeric ranges as structs. There is no doubt that the Ada 
> way of creating ranged types is easier and cleaner than any kind of 
> "equivalent" solution in plain C might be. On the other hand, I'm sure C++ 
> could do a much better job of emulating the Ada solution by using 
> templates and overloaded operators.
> 
> In any case, the OP's example didn't seem like a good example of how Ada 
> is more strongly typed than C. It is certainly true that Ada does not do 
> automatic type conversions the way C does, but the OP's example doesn't 
> illustrate that point. In contrast, when I think about a weakly typed 
> language I think about languages like AWK, the shell scripting languages, 
> or perhaps Perl... where the type of a variable shifts around depending on 
> how it is used. For example:
> 
> #!/bin/bash
> COUNT=1
> echo "COUNT is now $COUNT"   # Treat COUNT as a string
> COUNT=$(($COUNT + 1))        # Treat COUNT as a number
> echo "COUNT is now $COUNT"
> 
> Peter


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Typing in Ada

[Dave Thompson]

On Wed, 02 Jun 2004 11:38:04 GMT, Marin David Condic
<nobody@noplace.com> wrote:
<snip>
> I'd also observe that just because there is a secret handshake that will 
> get C to complain about type compatibility doesn't mean much. Following 
> that logic, an assembler program can be made to complain about type 
> compatibility (at least at runtime) if you want to do enough work. The 
> problem is that typedef doesn't do what one who is acustomed to Ada 
> would think it should: "type" - "def" - Define a type.
> 
One of the regulars on comp.lang.c, Chris Torek, likes to suggest that
the 'struct' keyword -- which unlike 'typedef' does create a distinct
type as far as the C compiler is concerned -- should be read as an
acronym "STRange spelling for User Constructed Type". :-)

- David.Thompson1 at worldnet.att.net

Re: Typing in Ada

[James Rogers]

Dave Thompson <david.thompson1@worldnet.att.net> wrote in
news:gn12d0pk7e6hhmhr6k87hcj4olebou5hel@4ax.com: 

> One of the regulars on comp.lang.c, Chris Torek, likes to suggest that
> the 'struct' keyword -- which unlike 'typedef' does create a distinct
> type as far as the C compiler is concerned -- should be read as an
> acronym "STRange spelling for User Constructed Type". :-)

Yes, a C struct is the means for creating a user defined type.
It is similar to an Ada record, without all the representation
control or the possibility of discriminants. 

One important difference between Ada records and C structs is
in the creation of incomplete types. A C compiler allows the
creation of incomplete types under the assumption that the
type will be completed through the linking process, while an
Ada compiler must have all types completed at compile time.

Jim Rogers

Re: Typing in Ada

[Hyman Rosen]

James Rogers wrote:
> One important difference between Ada records and C structs is
> in the creation of incomplete types. A C compiler allows the
> creation of incomplete types under the assumption that the
> type will be completed through the linking process, while an
> Ada compiler must have all types completed at compile time.

No, incomplete types in C have nothing to do with linking.
Incomplete types are there for the same reason as in any
other language, so that mutually recursive types may be
declared. Eg.,
     struct A;
     struct B { struct A *my_A; int x; };
     struct A { struct B *my_B; int y; };
For this mutual recursion to be possible, C and C++ must
then identify the places where incomplete types may be used,
such as in declarations of pointers to them, or as function
parameters - basically those places where knowing the innards
of the type is unnecessary.

It is true in C or C++ that if you never have a context in
which you need the complete type, you need not supply it,
even at link time.

Re: Typing in Ada

[James Rogers]

Hyman Rosen <hyrosen@mail.com> wrote in 
news:1087475285.166449@master.nyc.kbcfp.com:

> No, incomplete types in C have nothing to do with linking.
> Incomplete types are there for the same reason as in any
> other language, so that mutually recursive types may be
> declared. Eg.,
>      struct A;
>      struct B { struct A *my_A; int x; };
>      struct A { struct B *my_B; int y; };
> For this mutual recursion to be possible, C and C++ must
> then identify the places where incomplete types may be used,
> such as in declarations of pointers to them, or as function
> parameters - basically those places where knowing the innards
> of the type is unnecessary.
> 
> It is true in C or C++ that if you never have a context in
> which you need the complete type, you need not supply it,
> even at link time.

Perhaps I misspoke. I did not mean that C reserves incomplete
types for link time. I meant to say that the compiler does not
require completion of incomplete types. This effect allows a
C program to define an incomplete type in the global area of
one file and complete the type in another file. The compiler
never knows of the completion, while the linker might.

I agree that the most common use of incomplete types is the
same in C as in Ada; for recursive or self-referential types.
One common example is a singly linked list, where one of the
node data elements is a reference or pointer to the next node.

A common Ada implementation approach is:

package Single_List is
   type List is private
   procedure add(Item : in Item_Type; To : in out List);
   procedure get(Item : out Item_Type; From : in out List);
   function Is_Empty(The_List : List) return Boolean;
private
   type Node;
   type List is Access Node;
   Type Node is record
     Element : Item_Type;
     Next    : List := Null;
   end record;
end Single_List;

The Ada difference is that all incomplete types must be
completed in the same compilation unit.

Jim Rogers

Re: Typing in Ada

[Nick Roberts]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns950BB3B4DBFE6jimmaureenrogers@204.127.36.1...

> ...
> The Ada difference is that all incomplete types must be
> completed in the same compilation unit.

In fact, this restriction is likely be lifted (in a very restricted way ;-)
in the new revision of the Ada language. It has proved to be too
inconvenient.

Whether implementations will join up the dots at (traditional) link time, or
at some pre-linking stage instead, is yet to be seen. I think the latter is
more likely.

-- 
Nick Roberts

Re: new revision ada

[Brian May]

>>>>> "Nick" == Nick Roberts <nick.roberts@acm.org> writes:

    Nick> In fact, this restriction is likely be lifted (in a very
    Nick> restricted way ;-) in the new revision of the Ada
    Nick> language. It has proved to be too inconvenient.

Are the details of this new revision of Ada published anywhere?

Personally I have very happy with Ada95 the way it is, the only
exception being exception handling which tends to look restrictive now
compared with, say Java exceptions (as functions declare what
exceptions they can raise, and can pass more information in the
exception instead of just a string).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: new revision ada

[tmoran]

>... and can pass more information in the
>exception instead of just a string).
  I don't understand why this is considered a problem.  Why not make:
    type data_to_pass is record ...
    function enstring(x : data_to_pass) return string;
    function destring(s : string) return data_to_pass;

Re: new revision ada

[James Rogers]

tmoran@acm.org wrote in news:MxrBc.125243$3x.100303@attbi_s54:

>>... and can pass more information in the
>>exception instead of just a string).
>   I don't understand why this is considered a problem.  Why not make:
>     type data_to_pass is record ...
>     function enstring(x : data_to_pass) return string;
>     function destring(s : string) return data_to_pass;
> 

Why not consider all leaving exception messages as strings.
Any more complex information can be encoded in the string as an
XML message. That message can then be sent by well defined
mechanisms from one subprogram to another, one task to another,
and across distributed systems.

Many systems are currently migrating towards using XML encoding
for inter-process and inter-processor communication. Why not 
provide an Ada built-in mechanism to produce and consume 
exception information as streams of XML messages?

Jim Rogers

Re: new revision ada

[Roland Illig]

James Rogers wrote:
> tmoran@acm.org wrote in news:MxrBc.125243$3x.100303@attbi_s54:
> 
> 
>>>... and can pass more information in the
>>>exception instead of just a string).
>>
>>  I don't understand why this is considered a problem.  Why not make:
>>    type data_to_pass is record ...
>>    function enstring(x : data_to_pass) return string;
>>    function destring(s : string) return data_to_pass;
> 
> Why not consider all leaving exception messages as strings.
> Any more complex information can be encoded in the string as an
> XML message. That message can then be sent by well defined
> mechanisms from one subprogram to another, one task to another,
> and across distributed systems.

11.4.1#18 [Implementation Permissions]
The string returned by Exception_Message may be truncated (to no less 
than 200 characters) by the Save_Occurence procedure (not the function), 
the Reraise_Occurrence procedure and the re-raise statement.

You didn't want to encode an XML message in 200 characters, did you? :)

Roland

Re: new revision ada

[James Rogers]

Roland Illig <roland.illig@gmx.de> wrote in news:2jpj43F12qulvU1@uni-
berlin.de:

> James Rogers wrote:
>> Why not consider all leaving exception messages as strings.
>> Any more complex information can be encoded in the string as an
>> XML message. That message can then be sent by well defined
>> mechanisms from one subprogram to another, one task to another,
>> and across distributed systems.
> 
> 11.4.1#18 [Implementation Permissions]
> The string returned by Exception_Message may be truncated (to no less 
> than 200 characters) by the Save_Occurence procedure (not the function), 
> the Reraise_Occurrence procedure and the re-raise statement.
> 
> You didn't want to encode an XML message in 200 characters, did you? :)

No. I also do not expect that an Ada 95 limit on the length of an
exception message will necessarily be retained for Ada 200X. 
For instance, the definition of Exception_Message may be retained
for compatibility, while another kind of message, such as
Extended_Exception_Message may be implemented a new string type
that includes XML encoding and parsing/decoding capabilities.

IMHO, this could be one area where Ada takes a lead rather than
playing catch-up with other languages. Ada will be able to stake
out some interesting capability by providing a string type that
includes XML handling capabilities and then extending the use
of that type to exceptions. The addition of such XML capabilities,
even if an extension of the distributed systems annex, will allow
Ada to take a vibrant position in modern distributed application
development.

Jim Rogers

Re: new revision ada

[Martin Krischik]

James Rogers wrote:

> Roland Illig <roland.illig@gmx.de> wrote in news:2jpj43F12qulvU1@uni-
> berlin.de:
> 
>> James Rogers wrote:
>>> Why not consider all leaving exception messages as strings.
>>> Any more complex information can be encoded in the string as an
>>> XML message. That message can then be sent by well defined
>>> mechanisms from one subprogram to another, one task to another,
>>> and across distributed systems.
>> 
>> 11.4.1#18 [Implementation Permissions]
>> The string returned by Exception_Message may be truncated (to no less
>> than 200 characters) by the Save_Occurence procedure (not the function),
>> the Reraise_Occurrence procedure and the re-raise statement.
>> 
>> You didn't want to encode an XML message in 200 characters, did you? :)
> 
> No. I also do not expect that an Ada 95 limit on the length of an
> exception message will necessarily be retained for Ada 200X.
> For instance, the definition of Exception_Message may be retained
> for compatibility, while another kind of message, such as
> Extended_Exception_Message may be implemented a new string type
> that includes XML encoding and parsing/decoding capabilities.

If you are planning for an extension then why not use memory streams instead
of strings. For you XML solution you need an XML Parser. 'Input and 'Output
are allready there. And you can stream any type you like without the need
of an extra parser.

The real problem of corse - for both strings and streams is the dynamic
length of such a construct. Remember: C++ has:

catch (Exception An_Exception)

and 

catch (Exception& An_Exception)
catch (Exception* An_Exception)

which work very differently.

Ada does not have such and such not have such an ambiguous exception
handler.

And in Java everything is a pointer anyway.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: new revision ada

[Brian May]

>>>>> "tmoran" == tmoran  <tmoran@acm.org> writes:

    >> ... and can pass more information in the
    >> exception instead of just a string).
    tmoran> I don't understand why this is considered a problem.  Why not make:
    tmoran> type data_to_pass is record ...
    tmoran> function enstring(x : data_to_pass) return string;
    tmoran> function destring(s : string) return data_to_pass;

That seems like a very ugly hack.

Isn't the philosophy behind Ada that you specify what you want to
happen, not how it happens? If you have to mangulate exception
information into a string (whatever encoding you choose to use, you
could use XML or you could use something else) in order to pass it to
an exception, I think it has hardly succeeded. I have always thought
of the text string to be a string to log/show the user, not one for
processing internally by the application.

Thats also a lot of overhead just to pass variables from one part of
the program to another part of the same program, too.

If you want to try to recover from an error condition (as opposed to
simply displaying/logging an error and failing) you often need to have
detailed information on what was going on when the error occurred.

eg. ENGINE_FAILED(Number=>1, RPM=>xxxx,
Occurred=>After_Switching_Fuel_Tanks) is a lot more informative then
ENGINE_FAILURE and allows some sort of recovery process (eg. switch
back to the previous fuel tank) instead of trying to guess information
that was already known. (disclaimer: I haven't written such an
application...)

The solution I have heard of for Ada is to use global variables, but
this is not a thread safe solution, you risk one thread overwriting
the exception information of another thread. eg. in the above example,
multiple threads might detect that multiple engines have failed
simultaneously.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: new revision ada

[Simon Wright]

Brian May <bam@snoopy.apana.org.au> writes:

> If you want to try to recover from an error condition (as opposed to
> simply displaying/logging an error and failing) you often need to
> have detailed information on what was going on when the error
> occurred.
> 
> eg. ENGINE_FAILED(Number=>1, RPM=>xxxx,
> Occurred=>After_Switching_Fuel_Tanks) is a lot more informative then
> ENGINE_FAILURE and allows some sort of recovery process (eg. switch
> back to the previous fuel tank) instead of trying to guess
> information that was already known. (disclaimer: I haven't written
> such an application...)

This is fairly top-of-the-head stuff, but .. if you have an engine
management system, you had better design it to cope with engine
failure too. I just don't believe that a simple out-of-band thing like
an exception (even if decorated like this) can possibly provide a
mechanism for dealing with complex application-level handling of error
conditions.

If the engine fails while you're at the end of the runway, that's one
thing; if it fails mid-Atlantic that's quite another.

-- 
Simon Wright                               100% Ada, no bugs.

Re: new revision ada

[Larry Elmore]

Simon Wright wrote:
> Brian May <bam@snoopy.apana.org.au> writes:
> 
> 
>>If you want to try to recover from an error condition (as opposed to
>>simply displaying/logging an error and failing) you often need to
>>have detailed information on what was going on when the error
>>occurred.
>>
>>eg. ENGINE_FAILED(Number=>1, RPM=>xxxx,
>>Occurred=>After_Switching_Fuel_Tanks) is a lot more informative then
>>ENGINE_FAILURE and allows some sort of recovery process (eg. switch
>>back to the previous fuel tank) instead of trying to guess
>>information that was already known. (disclaimer: I haven't written
>>such an application...)
> 
> 
> This is fairly top-of-the-head stuff, but .. if you have an engine
> management system, you had better design it to cope with engine
> failure too. I just don't believe that a simple out-of-band thing like
> an exception (even if decorated like this) can possibly provide a
> mechanism for dealing with complex application-level handling of error
> conditions.
> 
> If the engine fails while you're at the end of the runway, that's one
> thing; if it fails mid-Atlantic that's quite another.

If it fails at the end of the runway on takeoff, that's probably worse 
than mid-Atlantic!

--Larry

Re: new revision ada

[tmoran]

>     tmoran> I don't understand why this is considered a problem.  Why not make:
>     tmoran> type data_to_pass is record ...
>     tmoran> function enstring(x : data_to_pass) return string;
>     tmoran> function destring(s : string) return data_to_pass;
>
> That seems like a very ugly hack.
   Would you prefer something like:
     package ER is new Exception_With_Record(Record_Type => Data_To_Pass);
     Problem : exception;
   ...
   ER.Raise_Exception(Problem'Identity,
                      Data_To_Pass'(Number=>1, RPM=>4000,
                                    Occurred=>After_Switching_Tanks));
   ...
   exception
     when oops:Problem =>
       declare
         Failure_Data : constant Data_To_Pass := ER.Exception_Message(oops);
       ...
The hidden string should contain a pointer to the data to pass, so there's
no problem about 200 character truncation.  It should also contain an
authentication watermark so ER.Exception_Message can avoid trying to
read data from an Ada.Exceptions.Exception_Message string (in case
"raise Problem" was erroneously used instead of ER.Raise_Exception).
ER.Exception_Message would also do the deallocation so the only way
a memory leak could happen is if you don't properly handle the exception,
in which case a memory leak is probably the least of your problems.

> Isn't the philosophy behind Ada that you specify what you want to
> happen, not how it happens?
   I don't understand: all code is a statement of "how it happens",
more or less hidden inside some convenient syntactic form.  Perhaps
Ada.Exceptions.Raise_Exception(Problem'Identity,
                               Enstring(Data_To_Pass'(Number=>1, RPM=>4000,
                                    Occurred=>After_Switching_Tanks)));
is insufficiently opaque.  The above
   ER.Raise_Exception(Problem'Identity,
                      Data_To_Pass'(Number=>1, RPM=>4000,
                                    Occurred=>After_Switching_Tanks));
doesn't expose any internals.

> Thats also a lot of overhead just to pass variables from one part of
> the program to another part of the same program, too.
   I suspect it compares quite well with a call to Ada.Text_IO.Put_Line.
You shouldn't be raising/handling thousands of exceptions/second anyway.

Re: new revision ada

[Wes Groleau]

Brian May wrote:
> compared with, say Java exceptions (as functions declare what
> exceptions they can raise, and can pass more information in the
> exception instead of just a string).

Well, a String can effectively carry ANY information.
But I agree Java is a little more flexible in exceptions.
However, the "throws" clause seemed like a good idea,
but turns out to be a major pain in large systems sometimes.

one example: Was getting a null pointer exception (can't
remember the Java name for that).  Took a long time to chase
down to two bugs.  When one class was fed the wrong file name,
instead of throwing file not found, it just acted like end-of-file
to another class.  And that class, not finding the item searched
for, returned a null pointer instead of an empty string for the
value.  Fixing the first bug by throwing FileNotFound required
chasing all over the (large) system adding in the throws clause
for it.

In Ada, when you add a raise at a low level, you only have to
add the handler.  You don't have to tweak every unit in the
call chain.

Moral of the story: One guy's relatively minor error
caused a heck of a lot of work for the other guy who
had to fix it.

-- 
Wes Groleau

He that complies against his will is of the same opinion still.
                   -- Samuel Butler, 1612-1680

Re: new revision ada (limited with, excpetion handling)

[Nick Roberts]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4r7s9hkp6.fsf_-_@snoopy.apana.org.au...

>     Nick> In fact, this restriction is likely be lifted (in a very
>     Nick> restricted way ;-) in the new revision of the Ada
>     Nick> language. It has proved to be too inconvenient.
>
> Are the details of this new revision of Ada published anywhere?

   http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-50217.TXT?rev=1.13

> Personally I have very happy with Ada95 the way it is, the only
> exception being exception handling which tends to look restrictive
> now compared with, say Java exceptions (as functions declare
> what exceptions they can raise, and can pass more information in
> the exception instead of just a string).

I'm not sure that it would be appropriate to add such facilities to the Ada
standard. Remember, a key area of Ada usage is embedded systems, for which
(the necessity to support) such facilities would be likely to be unwelcome
shiralee.

It may be appropriate for a secondary or informal standard to agreed upon by
those Ada compiler companies for whom it is appropriate, possibly to add a
procedure allowing a value in the class of a given abstract root tagged type
to be associated with an exception instance, and a function to retrieve this
value. It seems to me that a mechanism of this kind is required to (neatly)
support the current CORBA Ada binding.

-- 
Nick Roberts

Re: new revision ada (limited with, excpetion handling)

[Martin Dowie]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:2jo2i0F13k4obU1@uni-berlin.de...
> I'm not sure that it would be appropriate to add such facilities to the
Ada
> standard. Remember, a key area of Ada usage is embedded systems, for which
> (the necessity to support) such facilities would be likely to be unwelcome
> shiralee.

Not at all, we'd simply look at ways of removing any runtime library support
it incurs from the final runtime image. Just like we do with Ada.Text_IO
now. :-)

Cheers

-- Martin

Re: new revision ada

[Georg Bauhaus]

Brian May <bam@snoopy.apana.org.au> wrote:
: 
: Personally I have very happy with Ada95 the way it is, the only
: exception being exception handling which tends to look restrictive now
: compared with, say Java exceptions (as functions declare what
: exceptions they can raise, and can pass more information in the
: exception instead of just a string).

If you want to handle an exceptional situation with something
more "powerful" than an exception handler, then you might actually
be referring to a different notion of exception.
If it is more like backtracing, why not use a programming construct
that (I think) is closer in spirit to backtracing?  If the exception
is not what is traditionally called an exception but rather a special
program state that is special rather than exceptional in the Ada(?)
sense, an exception handler might be at the wrong level of
abstraction. Just the same name for two different things.

Ada has facilities to implement "trying-out programming". If one
(logical) thread of control fails, and it is important to
collect information about why it failed and in what program
state, than save the relevant pieces of the program state
using the executable statements of a local exception
handler for example.
You can store the information somewhere for lookup, and
use Ada's exceptions, or task communication, or plain
returned values to inform the caller of the failure or
success. The caller can use this information to retrieve
what has been stored for lookup.

Re: new revision ada

[James Rogers]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in 
news:cb927q$332$1@a1-hrz.uni-duisburg.de:

> Ada has facilities to implement "trying-out programming". If one
> (logical) thread of control fails, and it is important to
> collect information about why it failed and in what program
> state, than save the relevant pieces of the program state
> using the executable statements of a local exception
> handler for example.
> You can store the information somewhere for lookup, and
> use Ada's exceptions, or task communication, or plain
> returned values to inform the caller of the failure or
> success. The caller can use this information to retrieve
> what has been stored for lookup.

Your solution detaches the information from the notification.
This detachment causes problems, which are compounded by
concurrency. If two exceptions are raised in a program and
their state information is stored in some buffer such as
a protected object, how will a handler determine which state
belongs to which exception occurrence?

The state information must be directly associated with the
exception occurrence. In Java this is done be creating an
exception object. References to that object are passed
up through the call stack until the exception is handled.
I believe the same concept is used in C++ exceptions.

Ada has a somewhat different view of exceptions. All exceptions
are the same type, and are identified by name. Ada 95 added the
ability to define exception information in a limited length
string. That string is intimately associated with an exception
occurrence. I am proposing that we provide a second kind of
exception information using a variable-width string that
encodes data in XML. XML is capable of encoding any kind of
data including very complex data structures. This new form
of exception information will allow complex exception state
data to be reliably communicated with an exception 
occurrence.

Jim Rogers

Re: new revision ada

[Martin Krischik]

James Rogers wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in
> news:cb927q$332$1@a1-hrz.uni-duisburg.de:
> 
>> Ada has facilities to implement "trying-out programming". If one
>> (logical) thread of control fails, and it is important to
>> collect information about why it failed and in what program
>> state, than save the relevant pieces of the program state
>> using the executable statements of a local exception
>> handler for example.
>> You can store the information somewhere for lookup, and
>> use Ada's exceptions, or task communication, or plain
>> returned values to inform the caller of the failure or
>> success. The caller can use this information to retrieve
>> what has been stored for lookup.
> 
> Your solution detaches the information from the notification.
> This detachment causes problems, which are compounded by
> concurrency. If two exceptions are raised in a program and
> their state information is stored in some buffer such as
> a protected object, how will a handler determine which state
> belongs to which exception occurrence?

Store them in an booch component map indexed by thread id. I do that in
AdaCL.Trace.

> The state information must be directly associated with the
> exception occurrence. In Java this is done be creating an
> exception object. References to that object are passed
> up through the call stack until the exception is handled.

Posible only becase Java throws pointers only.

> I believe the same concept is used in C++ exceptions.

With the usual amount of pitfalls which acomplished every C++ feature - yes.

> Ada has a somewhat different view of exceptions. All exceptions
> are the same type, and are identified by name. Ada 95 added the
> ability to define exception information in a limited length
> string. That string is intimately associated with an exception
> occurrence. I am proposing that we provide a second kind of
> exception information using a variable-width string that
> encodes data in XML. XML is capable of encoding any kind of
> data including very complex data structures. This new form
> of exception information will allow complex exception state
> data to be reliably communicated with an exception
> occurrence.

Again: why XML when Ada has a perfectly usable system to stream out data.
i.E. 'Input and 'Output. Annex E is allready based on it so it could be
used for extended exceptions as well.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: new revision ada (exception handling)

[Nick Roberts]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1774424.VSnnNmZCKX@linux1.krischik.com...

> > Your solution detaches the information from the notification.
> > This detachment causes problems, which are compounded by
> > concurrency. If two exceptions are raised in a program and
> > their state information is stored in some buffer such as
> > a protected object, how will a handler determine which state
> > belongs to which exception occurrence?
>
> Store them in an booch component map indexed by thread id.
> I do that in AdaCL.Trace.

I am intrigued by this technique. It is of importance to me, since I am
currently thinking about how to implement exception handling according to
the current CORBA Ada binding.

There seem to be two problems with the solution you suggest:

(1) Nested exception occurrances. If an exception is raised and handled
within an exception handler, the parameters of the outer occurrance will be
overwritten by those of the inner one. A solution would be for every handler
(that uses parameters) to copy off the parameters before doing anything else
(that could raise and handle an exception). However, this solution causes
extra work, and is not neat; it seems bug-prone to me.

(2) Memory management. The memory used up by the parameters of an exception
will not be reclaimed at an appropriate time (for example, when there is no
longer any possibility of the associated exception being handled). This is
only a memory leakage problem, and may be considered of low significance,
but I don't like it.

In addition, the use of a map structure seems a bit heavyweight.

I'd appreciate your comments.

> Again: why XML when Ada has a perfectly usable system to
> stream out data. i.E. 'Input and 'Output. Annex E is already
> based on it so it could be used for extended exceptions as
> well.

I think a possible answer to this question is that XML is human-readable (or
at least it is pure text), whereas Ada streams are (essentially) binary. I
think the point of providing (only) string data for parametising exceptions
in Ada 95 was to ensure that those parameters could simply be
printed/displayed (by diagnostic software). XML encoded parameters could
also be simply printed out, as well as being interpreted and used by
knowledgeable software.

However, I would not personally advocate this approach. The use of XML seems
extremely heavyweight to me. I think a better idea would be to allow
parameters to be added to an exception occurrance in the machine's internal
format (possibly as a value of a type derived from an abstract root tagged
type), in addition to an appropriate human-readable message being added to
the occurrance's message. This way, diagnostic software can simply print the
message, and knowledgable software can interpret the parameters directly.
There would be no need for any endcoding or decoding software. Surely having
to add an XML generator and parser to a piece of (embedded) software just to
support exception handling would be overkill?

-- 
Nick Roberts

Re: new revision ada (exception handling)

[Pascal Obry]

"Nick Roberts" <nick.roberts@acm.org> writes:

> I think a possible answer to this question is that XML is human-readable (or
> at least it is pure text), whereas Ada streams are (essentially) binary. I
> think the point of providing (only) string data for parametising exceptions
> in Ada 95 was to ensure that those parameters could simply be
> printed/displayed (by diagnostic software). XML encoded parameters could
> also be simply printed out, as well as being interpreted and used by
> knowledgeable software.

There is mixed issues here. The stream does not need to be human readable as
the information is passed between partition, this is really a computer issue
and the most compact representation is better. Now to display the exception
information I agree that we need to kind of human representation.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: new revision ada (exception handling)

[Martin Krischik]

Pascal Obry wrote:

> 
> "Nick Roberts" <nick.roberts@acm.org> writes:
> 
>> I think a possible answer to this question is that XML is human-readable
>> (or at least it is pure text), whereas Ada streams are (essentially)
>> binary. I think the point of providing (only) string data for
>> parametising exceptions in Ada 95 was to ensure that those parameters
>> could simply be printed/displayed (by diagnostic software). XML encoded
>> parameters could also be simply printed out, as well as being interpreted
>> and used by knowledgeable software.
> 
> There is mixed issues here. The stream does not need to be human readable
> as the information is passed between partition, this is really a computer
> issue and the most compact representation is better. Now to display the
> exception information I agree that we need to kind of human
> representation.

In this respect I allways missed the

for My_Type'Image use ...;

feature.

We can say:

for My_Type'Output use ...;

so why not?

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: new revision ada (exception handling)

[Randy Brukardt]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:3596451.WJTNXepdF3@linux1.krischik.com...
> In this respect I allways missed the
>
> for My_Type'Image use ...;
>
> feature.

We considered it briefly, but there are a number of problems with such a
feature. (One example is that Text_IO.Enumeration_IO depends on 'Image. How
will it know what syntax to read for a user-defined image.) Anyway, we
dropped the idea. (You should be able to find that discussion in the meeting
minutes, although I can't tell you in which meeting we discussed it.)

              Randy Brukardt
              ARG Editor

Re: new revision ada (exception handling)

[Martin Krischik]

Randy Brukardt wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:3596451.WJTNXepdF3@linux1.krischik.com...
>> In this respect I allways missed the
>>
>> for My_Type'Image use ...;
>>
>> feature.
> 
> We considered it briefly, but there are a number of problems with such a
> feature. (One example is that Text_IO.Enumeration_IO depends on 'Image.
> How will it know what syntax to read for a user-defined image.) Anyway, we
> dropped the idea.

At least for the first question I know the answer. It is the same as for
'Output:

for My_Type'Value use ...;

If you provide 'Output and want to read the data afterwards you have to
provide an 'Input which fits the bill.

So it would be the same for the 'Image / 'Value pair. 

> (You should be able to find that discussion in the
> meeting minutes, although I can't tell you in which meeting we discussed
> it.)

To difficult to find anything in there.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: new revision ada (exception handling)

[Randy Brukardt]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1602287.U74iaLRb4H@linux1.krischik.com...
> Randy Brukardt wrote:
...
> > We considered it briefly, but there are a number of problems with such a
> > feature. (One example is that Text_IO.Enumeration_IO depends on 'Image.
> > How will it know what syntax to read for a user-defined image.) Anyway,
we
> > dropped the idea.
>
> At least for the first question I know the answer. It is the same as for
> 'Output:

No, that's *not* the question. (That's another question, which also needs to
be answered.)

The issue is that Enumeration_IO.Get needs to know the syntax of a
enumeration literal in order to know when to stop reading. For instance, if
a file has:

Red;Green Blue

and you do a Get, the next character to be read is ';', and "Red" will be
passed to 'Image.

But if you allow a user-defined 'Image, you don't know what to read in order
to pass it to 'Image. Perhaps the semicolon is part of the literal, perhaps
it is not. Perhaps the case matters to the literal, and perhaps not. So
where does reading stop? (And remember, whatever is done has to be
compatible with existing code and files.)

If you just say that the syntax is still that of an identifier, then what
you can do with a user-defined 'Image is very limited. "Real-Time" and "62B"
would not be legitimate uses of 'Image, and the errors that would occur when
trying to read them would be very mysterious to programmers.

                               Randy.

Re: new revision ada (exception handling)

[Dmitry A. Kazakov]

On Thu, 24 Jun 2004 16:13:58 -0500, Randy Brukardt wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:1602287.U74iaLRb4H@linux1.krischik.com...
>> Randy Brukardt wrote:
> ...
>>> We considered it briefly, but there are a number of problems with such a
>>> feature. (One example is that Text_IO.Enumeration_IO depends on 'Image.
>>> How will it know what syntax to read for a user-defined image.) Anyway,
> we
>>> dropped the idea.
>>
>> At least for the first question I know the answer. It is the same as for
>> 'Output:
> 
> No, that's *not* the question. (That's another question, which also needs to
> be answered.)
> 
> The issue is that Enumeration_IO.Get needs to know the syntax of a
> enumeration literal in order to know when to stop reading. For instance, if
> a file has:
> 
> Red;Green Blue
> 
> and you do a Get, the next character to be read is ';', and "Red" will be
> passed to 'Image.
> 
> But if you allow a user-defined 'Image, you don't know what to read in order
> to pass it to 'Image. Perhaps the semicolon is part of the literal, perhaps
> it is not. Perhaps the case matters to the literal, and perhaps not. So
> where does reading stop? (And remember, whatever is done has to be
> compatible with existing code and files.)

One can build a table of all possible values of 'Image and use the table to
match the input. In this case there is no need to know where a name stops,
one only needs to have all names in the table different. However it looks
like the definition of Enumeration_IO.Get assumes that name ends can be
recognized prior knowing names, though A.10.10(9) does not read it
explicitly. Considering an enumeration type with images Red and Red1. Would
it be legal according to A.10.10(9) to read Red; and then raise Data_Error?

But of course the real source of the problems is that there is no S'Class
for enumeration types. Otherwise one could just deduce 'Input from 'Image
and use it Get.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: new revision ada (exception handling)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:s1spuprxstn0$.11739hjwai5o4$.dlg@40tude.net...
...
> One can build a table of all possible values of 'Image and use the table
to
> match the input. In this case there is no need to know where a name stops,
> one only needs to have all names in the table different.

You could do something like that, but:

-- There's no way to do that with the 'Image and 'Value attributes; (it
should be possible to write the bodies of standard packages in Ada) - that's
especially important when they are user-defined, as we were discussing; and
-- It would be very incompatible with the current definition (which
Christophe explained nicely).

                 Randy.

Re: new revision ada

[Brian May]

There seem to be two proposed solutions for the problem of passing
information from exceptions:

>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:

    Martin> Store them in an booch component map indexed by thread
    Martin> id. I do that in AdaCL.Trace.


>>>>> "tmoran" == tmoran  <tmoran@acm.org> writes:

    tmoran> I don't understand why this is considered a problem.  Why not make:
    tmoran> type data_to_pass is record ...
    tmoran> function enstring(x : data_to_pass) return string;
    tmoran> function destring(s : string) return data_to_pass;

Again, both solutions don't feel "right" to me, they seem more work
arounds rather then proper solutions.

For example, if you use the string encoding method to encode a pointer
(and do it in a type safe manner), in order to work around the maximum
string limits, this means you have to allocate the memory first, or
use a global buffer that is of fixed length and could be overwritten.

Similarly, the booch component model no doubt will require allocation
of additional memory, too.

But what if the exception that is being processed is of a direct
result of a out of memory error? (obviously I am assuming this is on
some system, eg. embedded systems, that detects out of memory errors
before it is too late). Even if it isn't the out of memory exception
itself, a program may need to throw a new exception in response to an
out of memory error. No doubt multiple threads may get out of memory
errors simultaneously too, as they probably are sharing the same
memory pool.

(disclaimer: I am assuming, and would hope, that throwing an exception
doesn't require allocating memory, otherwise disregard the above
paragraph).

The above solutions seem to make a simple task complicated; you
wouldn't consider passing parameters to functions, procedures, or
tasks by encoding them to strings or storing them in a global
component container, so why should exceptions be any different?

Sidenote:

I seem to remember that there is a good review of the limitations of
exception handling in Ada in the following reference:

Author: 	 Burns, Alan, 1953-
Title: 	Real-time systems and programming languages : Ada 95, real-time Java, and real-time POSIX / Alan Burns and Andy Wellings.
3rd ed.
Publisher: 	Harlow ; New York : Pearson Education, 2001.
Description: 	xvi, 738 p. :

In this book, Ada gets a pretty good rating, but falls down with
exception handling, and the author lists his reasons, one of them
being this one discussed. It seems to be a pretty good book overall,
which makes comparisons between a number of languages.

Unfortunately I don't have the book handy right now (it is a library
book), so I can't cite from it.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: new revision ada

[Randy Brukardt]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4acyulwtc.fsf@snoopy.apana.org.au...
...
> Similarly, the booch component model no doubt will require allocation
> of additional memory, too.
>
> But what if the exception that is being processed is of a direct
> result of a out of memory error? (obviously I am assuming this is on
> some system, eg. embedded systems, that detects out of memory errors
> before it is too late). Even if it isn't the out of memory exception
> itself, a program may need to throw a new exception in response to an
> out of memory error. No doubt multiple threads may get out of memory
> errors simultaneously too, as they probably are sharing the same
> memory pool.

Given that you're talking about passing an unknown amount of memory along
with the exception (since it depends on which exception you raise, you can
hardly pre-allocate it), I would think that raising an exception in your
model would have to allocate memory. The reason for the 200 character limit
on the exception message string is simply so that memory doesn't need to be
allocated when raising an exception.

(Of course, an implementation could allocate a fixed amount of space for
exception handling, and fall back to allocating memory only if it doesn't
fit -- but that doesn't eliminate the original problem.)

In any case, the ARG looked at ways to extend the exception model, and
ultimately decided that none of them looked very appealing. They were
complex or incompatible, and ultimately the issue was dropped because other
areas were more important (limited with, interfaces, Ravenscar, limited
constructors, etc.)

Recently, we decided to lift some of the restrictions on tagged type
derivation. That would allow exceptions to be a kind of tagged type (with
the Ada 95 restrictions, you wouldn't have been able to declare exceptions
in nested scopes -- which of course would have been too incompatible to
consider). Thus, a clean solution based on type extension now would be
possible. However, we're nearing the end of the process, and we have been
strictly enforcing the rules about not reopening closed AIs. Moreover, WG9
just approved the scope of the Amendment, so adding in anything at this late
date would require extordinary action.

One of the reasons that we stopped working on it was that putting an id of
some sort in the exception message string is sufficient in virtually all
cases. It certainly isn't real clean, but as Tom demonstrated, you can wrap
the entire thing in a generic package and not have to see any of the dirty
details. While having mutually dependent types in multiple packages, or
multiple interface inheritance, or a constructor for a limited object, is
simply impossible in Ada 95.

BTW, look at ada-auth.org for the current state of the project, especially
in the "Grab Bag" section. I haven't updated that yet for the results of the
Palma meeting, but that will be done soon.

                       Randy Brukardt
                       ARG Editor
                       Editor, ISO/IEC 8652:AMD 1

Re: new revision ada

[Georg Bauhaus]

James Rogers <jimmaureenrogers@att.net> wrote:
 
: Your solution detaches the information from the notification.
: This detachment causes problems, which are compounded by
: concurrency. If two exceptions are raised in a program and
: their state information is stored in some buffer such as
: a protected object, how will a handler determine which state
: belongs to which exception occurrence?

The handler might create a unique id from a protecte counting
object, the task ID as Martin has said, and the exception ID
and pass this unique id as exception message.
The message will then become the lookup key in a map.

You could for example store XML in the map.

I'm not thinking of this as a general replacement for exception
handling, because it does incur a number of things that might go
wrong.
That is, I'd keep exception handling a local mechanism 
and write code for more elaborate gotos. :-)


Georg

Re: new revision ada

[Robert I. Eachus]

James Rogers wrote:

> Your solution detaches the information from the notification.
> This detachment causes problems, which are compounded by
> concurrency. If two exceptions are raised in a program and
> their state information is stored in some buffer such as
> a protected object, how will a handler determine which state
> belongs to which exception occurrence?

The simple answer is to make the buffer used to store the information a 
per task object.  The two complicated cases are exceptions in accept 
statements where you might need to create two copies of the information, 
and when an exception is raised in an exception handler.  If you want to 
"deal with" the second case, the per task data needs to be a stack or 
linked list.

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: Typing in Ada

[Alexander E. Kopilovich]

Sorry, can't resist -:)

Empit wrote:

> From typing point of view, how strong is Ada than C?

At first glance it may seem that Ada requires more typing - texts in C look
more condensed (for example, identifiers are typically shorter, famous "++",
"+=" etc. are used everywhere). But when you take into account typing during
debugging, the conclusion changes to the opposite.

> or
>
> Which is the most strongly typed language.

Surely C - again, during debugging - everyone knows that in the heat of
debugging the keys are hit (sometimes) most strongly.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: new revision ada (exception handling)

[Christoph Karl Walter Grein]

> like the definition of Enumeration_IO.Get assumes that name ends can be
> recognized prior knowing names, though A.10.10(9) does not read it
> explicitly. Considering an enumeration type with images Red and Red1. Would
> it be legal according to A.10.10(9) to read Red; and then raise Data_Error?

If you read the chapter on inputting enumeration literals very carefully, you'll find that you have
 to read a sequence of input characters as long as the sequence is a legal sequence for Ada
identifiers. Only after reading characters has ended, you make a check whether this sequence is a
defined literal.

It is irrelevant how long the expected literals are.

So for instance when reading booleans, "trueanything.x" has to be read until the dot, leaving the dot
 and the x in the input stream. Then you compare trueanything to true and raise Data_Error.
__________________________________________________________________
Zeigen Sie Emotionen mit der WEB.DE Bild-SMS! Das Bild ist gratis,
Sie bezahlen nur den Versand. http://freemail.web.de/?mc=021196