* Typing in Ada @ 2004-05-31 13:32 Empit 2004-05-31 14:04 ` Poul-Erik Andreasen ` (2 more replies) 0 siblings, 3 replies; 66+ messages in thread From: Empit @ 2004-05-31 13:32 UTC (permalink / raw) From typing point of view, how strong is Ada than C? or Which is the most strongly typed language. Responses appreciated ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 13:32 Typing in Ada Empit @ 2004-05-31 14:04 ` Poul-Erik Andreasen 2004-05-31 17:01 ` Jeffrey Carter 2004-06-01 1:02 ` Typing in Ada Alexander E. Kopilovich 2 siblings, 0 replies; 66+ messages in thread From: Poul-Erik Andreasen @ 2004-05-31 14:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 13:32 Typing in Ada Empit 2004-05-31 14:04 ` Poul-Erik Andreasen @ 2004-05-31 17:01 ` Jeffrey Carter 2004-05-31 20:03 ` Peter C. Chapin 2004-06-01 1:02 ` Typing in Ada Alexander E. Kopilovich 2 siblings, 1 reply; 66+ messages in thread From: Jeffrey Carter @ 2004-05-31 17:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 17:01 ` Jeffrey Carter @ 2004-05-31 20:03 ` Peter C. Chapin 2004-05-31 22:56 ` tmoran ` (3 more replies) 0 siblings, 4 replies; 66+ messages in thread From: Peter C. Chapin @ 2004-05-31 20:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 20:03 ` Peter C. Chapin @ 2004-05-31 22:56 ` tmoran 2004-06-01 1:09 ` Peter C. Chapin 2004-05-31 23:22 ` Nick Roberts ` (2 subsequent siblings) 3 siblings, 1 reply; 66+ messages in thread From: tmoran @ 2004-05-31 22:56 UTC (permalink / raw) >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)); ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 22:56 ` tmoran @ 2004-06-01 1:09 ` Peter C. Chapin 2004-06-01 4:40 ` tmoran 2004-06-10 3:00 ` Dave Thompson 0 siblings, 2 replies; 66+ messages in thread From: Peter C. Chapin @ 2004-06-01 1:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 1:09 ` Peter C. Chapin @ 2004-06-01 4:40 ` tmoran 2004-06-01 11:26 ` Peter C. Chapin 2004-06-10 3:00 ` Dave Thompson 1 sibling, 1 reply; 66+ messages in thread From: tmoran @ 2004-06-01 4:40 UTC (permalink / raw) >> 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++. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 4:40 ` tmoran @ 2004-06-01 11:26 ` Peter C. Chapin 2004-06-10 3:01 ` Dave Thompson 0 siblings, 1 reply; 66+ messages in thread From: Peter C. Chapin @ 2004-06-01 11:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 11:26 ` Peter C. Chapin @ 2004-06-10 3:01 ` Dave Thompson 0 siblings, 0 replies; 66+ messages in thread From: Dave Thompson @ 2004-06-10 3:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 1:09 ` Peter C. Chapin 2004-06-01 4:40 ` tmoran @ 2004-06-10 3:00 ` Dave Thompson 1 sibling, 0 replies; 66+ messages in thread From: Dave Thompson @ 2004-06-10 3:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 20:03 ` Peter C. Chapin 2004-05-31 22:56 ` tmoran @ 2004-05-31 23:22 ` Nick Roberts 2004-06-01 1:04 ` Peter C. Chapin 2004-06-01 2:36 ` Hyman Rosen 2004-06-01 2:14 ` David C. Hoos 2004-06-02 1:30 ` Jeffrey Carter 3 siblings, 2 replies; 66+ messages in thread From: Nick Roberts @ 2004-05-31 23:22 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 23:22 ` Nick Roberts @ 2004-06-01 1:04 ` Peter C. Chapin 2004-06-01 2:29 ` Nick Roberts 2004-06-02 4:39 ` Robert I. Eachus 2004-06-01 2:36 ` Hyman Rosen 1 sibling, 2 replies; 66+ messages in thread From: Peter C. Chapin @ 2004-06-01 1:04 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 1:04 ` Peter C. Chapin @ 2004-06-01 2:29 ` Nick Roberts 2004-06-02 4:39 ` Robert I. Eachus 1 sibling, 0 replies; 66+ messages in thread From: Nick Roberts @ 2004-06-01 2:29 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 1:04 ` Peter C. Chapin 2004-06-01 2:29 ` Nick Roberts @ 2004-06-02 4:39 ` Robert I. Eachus 2004-06-02 15:17 ` Hyman Rosen 1 sibling, 1 reply; 66+ messages in thread From: Robert I. Eachus @ 2004-06-02 4:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-02 4:39 ` Robert I. Eachus @ 2004-06-02 15:17 ` Hyman Rosen 0 siblings, 0 replies; 66+ messages in thread From: Hyman Rosen @ 2004-06-02 15:17 UTC (permalink / raw) 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); } ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 23:22 ` Nick Roberts 2004-06-01 1:04 ` Peter C. Chapin @ 2004-06-01 2:36 ` Hyman Rosen 2004-06-01 4:27 ` Larry Kilgallen ` (2 more replies) 1 sibling, 3 replies; 66+ messages in thread From: Hyman Rosen @ 2004-06-01 2:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 2:36 ` Hyman Rosen @ 2004-06-01 4:27 ` Larry Kilgallen 2004-06-01 4:05 ` Hyman Rosen [not found] ` <d4vnb0tepd4togdrvdrbqpok1ne6n9i2vp@4ax.com> 2004-06-01 20:24 ` Niklas Holsti 2 siblings, 1 reply; 66+ messages in thread From: Larry Kilgallen @ 2004-06-01 4:27 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 4:27 ` Larry Kilgallen @ 2004-06-01 4:05 ` Hyman Rosen 0 siblings, 0 replies; 66+ messages in thread From: Hyman Rosen @ 2004-06-01 4:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
[parent not found: <d4vnb0tepd4togdrvdrbqpok1ne6n9i2vp@4ax.com>]
* Re: Typing in Ada [not found] ` <d4vnb0tepd4togdrvdrbqpok1ne6n9i2vp@4ax.com> @ 2004-06-01 14:36 ` Wes Groleau 0 siblings, 0 replies; 66+ messages in thread From: Wes Groleau @ 2004-06-01 14:36 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 2:36 ` Hyman Rosen 2004-06-01 4:27 ` Larry Kilgallen [not found] ` <d4vnb0tepd4togdrvdrbqpok1ne6n9i2vp@4ax.com> @ 2004-06-01 20:24 ` Niklas Holsti 2004-06-02 4:43 ` Wes Groleau 2004-06-02 5:04 ` Typing in Ada Robert I. Eachus 2 siblings, 2 replies; 66+ messages in thread From: Niklas Holsti @ 2004-06-01 20:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 20:24 ` Niklas Holsti @ 2004-06-02 4:43 ` Wes Groleau 2004-06-02 5:28 ` Robert I. Eachus 2004-06-02 11:26 ` Marin David Condic 2004-06-02 5:04 ` Typing in Ada Robert I. Eachus 1 sibling, 2 replies; 66+ messages in thread From: Wes Groleau @ 2004-06-02 4:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-02 4:43 ` Wes Groleau @ 2004-06-02 5:28 ` Robert I. Eachus 2004-06-02 8:19 ` tmoran 2004-06-02 14:47 ` Wes Groleau 2004-06-02 11:26 ` Marin David Condic 1 sibling, 2 replies; 66+ messages in thread From: Robert I. Eachus @ 2004-06-02 5:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-02 5:28 ` Robert I. Eachus @ 2004-06-02 8:19 ` tmoran 2004-06-02 14:47 ` Wes Groleau 1 sibling, 0 replies; 66+ messages in thread From: tmoran @ 2004-06-02 8:19 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-02 5:28 ` Robert I. Eachus 2004-06-02 8:19 ` tmoran @ 2004-06-02 14:47 ` Wes Groleau 1 sibling, 0 replies; 66+ messages in thread From: Wes Groleau @ 2004-06-02 14:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-02 4:43 ` Wes Groleau 2004-06-02 5:28 ` Robert I. Eachus @ 2004-06-02 11:26 ` Marin David Condic 2004-06-02 14:54 ` gratuitous restrictions (was:Typing in Ada) Wes Groleau 1 sibling, 1 reply; 66+ messages in thread From: Marin David Condic @ 2004-06-02 11:26 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: gratuitous restrictions (was:Typing in Ada) 2004-06-02 11:26 ` Marin David Condic @ 2004-06-02 14:54 ` Wes Groleau 0 siblings, 0 replies; 66+ messages in thread From: Wes Groleau @ 2004-06-02 14:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-01 20:24 ` Niklas Holsti 2004-06-02 4:43 ` Wes Groleau @ 2004-06-02 5:04 ` Robert I. Eachus 1 sibling, 0 replies; 66+ messages in thread From: Robert I. Eachus @ 2004-06-02 5:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 20:03 ` Peter C. Chapin 2004-05-31 22:56 ` tmoran 2004-05-31 23:22 ` Nick Roberts @ 2004-06-01 2:14 ` David C. Hoos 2004-06-02 1:30 ` Jeffrey Carter 3 siblings, 0 replies; 66+ messages in thread From: David C. Hoos @ 2004-06-01 2:14 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 20:03 ` Peter C. Chapin ` (2 preceding siblings ...) 2004-06-01 2:14 ` David C. Hoos @ 2004-06-02 1:30 ` Jeffrey Carter 2004-06-02 10:53 ` Peter C. Chapin 3 siblings, 1 reply; 66+ messages in thread From: Jeffrey Carter @ 2004-06-02 1:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-02 1:30 ` Jeffrey Carter @ 2004-06-02 10:53 ` Peter C. Chapin 2004-06-02 11:38 ` Marin David Condic 0 siblings, 1 reply; 66+ messages in thread From: Peter C. Chapin @ 2004-06-02 10:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-02 10:53 ` Peter C. Chapin @ 2004-06-02 11:38 ` Marin David Condic 2004-06-17 2:50 ` Dave Thompson 0 siblings, 1 reply; 66+ messages in thread From: Marin David Condic @ 2004-06-02 11:38 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-02 11:38 ` Marin David Condic @ 2004-06-17 2:50 ` Dave Thompson 2004-06-17 4:24 ` James Rogers 0 siblings, 1 reply; 66+ messages in thread From: Dave Thompson @ 2004-06-17 2:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-17 2:50 ` Dave Thompson @ 2004-06-17 4:24 ` James Rogers 2004-06-17 12:28 ` Hyman Rosen 0 siblings, 1 reply; 66+ messages in thread From: James Rogers @ 2004-06-17 4:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-17 4:24 ` James Rogers @ 2004-06-17 12:28 ` Hyman Rosen 2004-06-17 23:42 ` James Rogers 0 siblings, 1 reply; 66+ messages in thread From: Hyman Rosen @ 2004-06-17 12:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-17 12:28 ` Hyman Rosen @ 2004-06-17 23:42 ` James Rogers 2004-06-20 11:27 ` Nick Roberts 0 siblings, 1 reply; 66+ messages in thread From: James Rogers @ 2004-06-17 23:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-06-17 23:42 ` James Rogers @ 2004-06-20 11:27 ` Nick Roberts 2004-06-20 23:29 ` new revision ada Brian May 0 siblings, 1 reply; 66+ messages in thread From: Nick Roberts @ 2004-06-20 11:27 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-20 11:27 ` Nick Roberts @ 2004-06-20 23:29 ` Brian May 2004-06-21 2:16 ` tmoran ` (3 more replies) 0 siblings, 4 replies; 66+ messages in thread From: Brian May @ 2004-06-20 23:29 UTC (permalink / raw) >>>>> "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> ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-20 23:29 ` new revision ada Brian May @ 2004-06-21 2:16 ` tmoran 2004-06-21 2:34 ` James Rogers 2004-06-21 23:33 ` Brian May 2004-06-21 5:31 ` Wes Groleau ` (2 subsequent siblings) 3 siblings, 2 replies; 66+ messages in thread From: tmoran @ 2004-06-21 2:16 UTC (permalink / raw) >... 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; ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-21 2:16 ` tmoran @ 2004-06-21 2:34 ` James Rogers 2004-06-22 2:16 ` Roland Illig 2004-06-21 23:33 ` Brian May 1 sibling, 1 reply; 66+ messages in thread From: James Rogers @ 2004-06-21 2:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-21 2:34 ` James Rogers @ 2004-06-22 2:16 ` Roland Illig 2004-06-22 3:41 ` James Rogers 0 siblings, 1 reply; 66+ messages in thread From: Roland Illig @ 2004-06-22 2:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-22 2:16 ` Roland Illig @ 2004-06-22 3:41 ` James Rogers 2004-06-22 6:53 ` Martin Krischik 0 siblings, 1 reply; 66+ messages in thread From: James Rogers @ 2004-06-22 3:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-22 3:41 ` James Rogers @ 2004-06-22 6:53 ` Martin Krischik 0 siblings, 0 replies; 66+ messages in thread From: Martin Krischik @ 2004-06-22 6:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-21 2:16 ` tmoran 2004-06-21 2:34 ` James Rogers @ 2004-06-21 23:33 ` Brian May 2004-06-22 20:26 ` Simon Wright 2004-06-22 22:06 ` tmoran 1 sibling, 2 replies; 66+ messages in thread From: Brian May @ 2004-06-21 23:33 UTC (permalink / raw) >>>>> "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> ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-21 23:33 ` Brian May @ 2004-06-22 20:26 ` Simon Wright 2004-06-23 0:50 ` Larry Elmore 2004-06-22 22:06 ` tmoran 1 sibling, 1 reply; 66+ messages in thread From: Simon Wright @ 2004-06-22 20:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-22 20:26 ` Simon Wright @ 2004-06-23 0:50 ` Larry Elmore 0 siblings, 0 replies; 66+ messages in thread From: Larry Elmore @ 2004-06-23 0:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-21 23:33 ` Brian May 2004-06-22 20:26 ` Simon Wright @ 2004-06-22 22:06 ` tmoran 1 sibling, 0 replies; 66+ messages in thread From: tmoran @ 2004-06-22 22:06 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-20 23:29 ` new revision ada Brian May 2004-06-21 2:16 ` tmoran @ 2004-06-21 5:31 ` Wes Groleau 2004-06-21 12:27 ` new revision ada (limited with, excpetion handling) Nick Roberts 2004-06-22 10:38 ` new revision ada Georg Bauhaus 3 siblings, 0 replies; 66+ messages in thread From: Wes Groleau @ 2004-06-21 5:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (limited with, excpetion handling) 2004-06-20 23:29 ` new revision ada Brian May 2004-06-21 2:16 ` tmoran 2004-06-21 5:31 ` Wes Groleau @ 2004-06-21 12:27 ` Nick Roberts 2004-06-21 13:04 ` Martin Dowie 2004-06-22 10:38 ` new revision ada Georg Bauhaus 3 siblings, 1 reply; 66+ messages in thread From: Nick Roberts @ 2004-06-21 12:27 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (limited with, excpetion handling) 2004-06-21 12:27 ` new revision ada (limited with, excpetion handling) Nick Roberts @ 2004-06-21 13:04 ` Martin Dowie 0 siblings, 0 replies; 66+ messages in thread From: Martin Dowie @ 2004-06-21 13:04 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-20 23:29 ` new revision ada Brian May ` (2 preceding siblings ...) 2004-06-21 12:27 ` new revision ada (limited with, excpetion handling) Nick Roberts @ 2004-06-22 10:38 ` Georg Bauhaus 2004-06-22 12:45 ` James Rogers 3 siblings, 1 reply; 66+ messages in thread From: Georg Bauhaus @ 2004-06-22 10:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-22 10:38 ` new revision ada Georg Bauhaus @ 2004-06-22 12:45 ` James Rogers 2004-06-22 15:17 ` Martin Krischik ` (2 more replies) 0 siblings, 3 replies; 66+ messages in thread From: James Rogers @ 2004-06-22 12:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-22 12:45 ` James Rogers @ 2004-06-22 15:17 ` Martin Krischik 2004-06-22 16:09 ` new revision ada (exception handling) Nick Roberts 2004-06-23 4:31 ` new revision ada Brian May 2004-06-22 16:37 ` Georg Bauhaus 2004-06-26 14:57 ` Robert I. Eachus 2 siblings, 2 replies; 66+ messages in thread From: Martin Krischik @ 2004-06-22 15:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (exception handling) 2004-06-22 15:17 ` Martin Krischik @ 2004-06-22 16:09 ` Nick Roberts 2004-06-23 7:55 ` Pascal Obry 2004-06-23 4:31 ` new revision ada Brian May 1 sibling, 1 reply; 66+ messages in thread From: Nick Roberts @ 2004-06-22 16:09 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (exception handling) 2004-06-22 16:09 ` new revision ada (exception handling) Nick Roberts @ 2004-06-23 7:55 ` Pascal Obry 2004-06-23 8:40 ` Martin Krischik 0 siblings, 1 reply; 66+ messages in thread From: Pascal Obry @ 2004-06-23 7:55 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (exception handling) 2004-06-23 7:55 ` Pascal Obry @ 2004-06-23 8:40 ` Martin Krischik 2004-06-23 19:33 ` Randy Brukardt 0 siblings, 1 reply; 66+ messages in thread From: Martin Krischik @ 2004-06-23 8:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (exception handling) 2004-06-23 8:40 ` Martin Krischik @ 2004-06-23 19:33 ` Randy Brukardt 2004-06-24 6:57 ` Martin Krischik 0 siblings, 1 reply; 66+ messages in thread From: Randy Brukardt @ 2004-06-23 19:33 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (exception handling) 2004-06-23 19:33 ` Randy Brukardt @ 2004-06-24 6:57 ` Martin Krischik 2004-06-24 21:13 ` Randy Brukardt 0 siblings, 1 reply; 66+ messages in thread From: Martin Krischik @ 2004-06-24 6:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (exception handling) 2004-06-24 6:57 ` Martin Krischik @ 2004-06-24 21:13 ` Randy Brukardt 2004-06-25 8:05 ` Dmitry A. Kazakov 0 siblings, 1 reply; 66+ messages in thread From: Randy Brukardt @ 2004-06-24 21:13 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (exception handling) 2004-06-24 21:13 ` Randy Brukardt @ 2004-06-25 8:05 ` Dmitry A. Kazakov 2004-06-25 17:28 ` Randy Brukardt 0 siblings, 1 reply; 66+ messages in thread From: Dmitry A. Kazakov @ 2004-06-25 8:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (exception handling) 2004-06-25 8:05 ` Dmitry A. Kazakov @ 2004-06-25 17:28 ` Randy Brukardt 0 siblings, 0 replies; 66+ messages in thread From: Randy Brukardt @ 2004-06-25 17:28 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-22 15:17 ` Martin Krischik 2004-06-22 16:09 ` new revision ada (exception handling) Nick Roberts @ 2004-06-23 4:31 ` Brian May 2004-06-23 19:47 ` Randy Brukardt 1 sibling, 1 reply; 66+ messages in thread From: Brian May @ 2004-06-23 4:31 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-23 4:31 ` new revision ada Brian May @ 2004-06-23 19:47 ` Randy Brukardt 0 siblings, 0 replies; 66+ messages in thread From: Randy Brukardt @ 2004-06-23 19:47 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-22 12:45 ` James Rogers 2004-06-22 15:17 ` Martin Krischik @ 2004-06-22 16:37 ` Georg Bauhaus 2004-06-26 14:57 ` Robert I. Eachus 2 siblings, 0 replies; 66+ messages in thread From: Georg Bauhaus @ 2004-06-22 16:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada 2004-06-22 12:45 ` James Rogers 2004-06-22 15:17 ` Martin Krischik 2004-06-22 16:37 ` Georg Bauhaus @ 2004-06-26 14:57 ` Robert I. Eachus 2 siblings, 0 replies; 66+ messages in thread From: Robert I. Eachus @ 2004-06-26 14:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Typing in Ada 2004-05-31 13:32 Typing in Ada Empit 2004-05-31 14:04 ` Poul-Erik Andreasen 2004-05-31 17:01 ` Jeffrey Carter @ 2004-06-01 1:02 ` Alexander E. Kopilovich 2 siblings, 0 replies; 66+ messages in thread From: Alexander E. Kopilovich @ 2004-06-01 1:02 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: new revision ada (exception handling)
@ 2004-06-25 9:48 Christoph Karl Walter Grein
0 siblings, 0 replies; 66+ messages in thread
From: Christoph Karl Walter Grein @ 2004-06-25 9:48 UTC (permalink / raw)
To: comp.lang.ada
> 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
^ permalink raw reply [flat|nested] 66+ messages in thread
end of thread, other threads:[~2004-06-26 14:57 UTC | newest] Thread overview: 66+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-05-31 13:32 Typing in Ada Empit 2004-05-31 14:04 ` Poul-Erik Andreasen 2004-05-31 17:01 ` Jeffrey Carter 2004-05-31 20:03 ` Peter C. Chapin 2004-05-31 22:56 ` tmoran 2004-06-01 1:09 ` Peter C. Chapin 2004-06-01 4:40 ` tmoran 2004-06-01 11:26 ` Peter C. Chapin 2004-06-10 3:01 ` Dave Thompson 2004-06-10 3:00 ` Dave Thompson 2004-05-31 23:22 ` Nick Roberts 2004-06-01 1:04 ` Peter C. Chapin 2004-06-01 2:29 ` Nick Roberts 2004-06-02 4:39 ` Robert I. Eachus 2004-06-02 15:17 ` Hyman Rosen 2004-06-01 2:36 ` Hyman Rosen 2004-06-01 4:27 ` Larry Kilgallen 2004-06-01 4:05 ` Hyman Rosen [not found] ` <d4vnb0tepd4togdrvdrbqpok1ne6n9i2vp@4ax.com> 2004-06-01 14:36 ` Wes Groleau 2004-06-01 20:24 ` Niklas Holsti 2004-06-02 4:43 ` Wes Groleau 2004-06-02 5:28 ` Robert I. Eachus 2004-06-02 8:19 ` tmoran 2004-06-02 14:47 ` Wes Groleau 2004-06-02 11:26 ` Marin David Condic 2004-06-02 14:54 ` gratuitous restrictions (was:Typing in Ada) Wes Groleau 2004-06-02 5:04 ` Typing in Ada Robert I. Eachus 2004-06-01 2:14 ` David C. Hoos 2004-06-02 1:30 ` Jeffrey Carter 2004-06-02 10:53 ` Peter C. Chapin 2004-06-02 11:38 ` Marin David Condic 2004-06-17 2:50 ` Dave Thompson 2004-06-17 4:24 ` James Rogers 2004-06-17 12:28 ` Hyman Rosen 2004-06-17 23:42 ` James Rogers 2004-06-20 11:27 ` Nick Roberts 2004-06-20 23:29 ` new revision ada Brian May 2004-06-21 2:16 ` tmoran 2004-06-21 2:34 ` James Rogers 2004-06-22 2:16 ` Roland Illig 2004-06-22 3:41 ` James Rogers 2004-06-22 6:53 ` Martin Krischik 2004-06-21 23:33 ` Brian May 2004-06-22 20:26 ` Simon Wright 2004-06-23 0:50 ` Larry Elmore 2004-06-22 22:06 ` tmoran 2004-06-21 5:31 ` Wes Groleau 2004-06-21 12:27 ` new revision ada (limited with, excpetion handling) Nick Roberts 2004-06-21 13:04 ` Martin Dowie 2004-06-22 10:38 ` new revision ada Georg Bauhaus 2004-06-22 12:45 ` James Rogers 2004-06-22 15:17 ` Martin Krischik 2004-06-22 16:09 ` new revision ada (exception handling) Nick Roberts 2004-06-23 7:55 ` Pascal Obry 2004-06-23 8:40 ` Martin Krischik 2004-06-23 19:33 ` Randy Brukardt 2004-06-24 6:57 ` Martin Krischik 2004-06-24 21:13 ` Randy Brukardt 2004-06-25 8:05 ` Dmitry A. Kazakov 2004-06-25 17:28 ` Randy Brukardt 2004-06-23 4:31 ` new revision ada Brian May 2004-06-23 19:47 ` Randy Brukardt 2004-06-22 16:37 ` Georg Bauhaus 2004-06-26 14:57 ` Robert I. Eachus 2004-06-01 1:02 ` Typing in Ada Alexander E. Kopilovich -- strict thread matches above, loose matches on Subject: below -- 2004-06-25 9:48 new revision ada (exception handling) Christoph Karl Walter Grein
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox