* Ada to 'C' parameter passing problem @ 2003-02-18 15:39 Patrick 2003-02-18 16:47 ` Jeffrey Carter 2003-02-18 19:50 ` Rod Chapman 0 siblings, 2 replies; 14+ messages in thread From: Patrick @ 2003-02-18 15:39 UTC (permalink / raw) I am using GNAT Ada on Linux. I am trying to port from a Sun (Solaris) implementation. I didn't write the Ada or 'C' myself, but am trying to make it work on Linux. The Ada code passes five parameters to the 'C' code. It is trying to pass the address in each case so that the 'C' can pass back status in the variables (parameters). The below Ada code (in tls.ads) contains the definition of the function "to_c_pointer" to convert the Ada address to a "c_pointer": type us1 is range 0..SYSTEM.MAX_INT; subtype unsigned_long is us1; subtype c_pointer is unsigned_long; -- convert ada address into a value that can be assigned -- to a c pointer. The following is an example of a call to -- to_c_pointer: TLS.to_c_pointer(i'ADDRESS) function to_c_pointer is new unchecked_conversion(SYSTEM.address, c_pointer); pragma inline(to_c_pointer); Here is what the Ada call to 'C' looks like: DMC_Initialize_Database_Configuration_C( TLS.to_c_pointer(Configuration_Id_In'ADDRESS), TLS.to_c_pointer(Configuration_Id_Len'ADDRESS), TLS.to_c_pointer(Initialization_Status_Ind'ADDRESS), TLS.to_c_pointer(Init_Failure_Text_In'ADDRESS), TLS.to_c_pointer(Init_Failure_Text_Len'ADDRESS)); Here is what the 'C' funtion definition looks like: DMC_Initialize_Database_Configuration_C( char *Configuration_Id, int *Configuration_Id_Len, int *Initialization_Status, char *Init_Failure_Text, int *Init_Failure_Text_Len) { As I said, there are five parameters. This worked fine under Solaris (Spark compiler for Ada), but under Linux the address of the 2nd and 4th parameters ends up being zero on the 'C' side (we can tell this with a debugger). Using the debugger, it looks like the first parameter on the Ada side is being passed into the first parameter on the 'C' side. The second parameter on the Ada side shows up on the 'C' side as the third parameter. The third parameter on the Ada side shows up on the 'C' side as the fifth parameter. So, at least on the surface, it looks as if the size of the parameter on the Ada side is twice the size of the parameter on the 'C' and it is filling in with zero. Have you run into anything similar that would enable you to help me solve this problem? Thanks for any help you can give me, ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-18 15:39 Ada to 'C' parameter passing problem Patrick @ 2003-02-18 16:47 ` Jeffrey Carter 2003-02-18 19:50 ` Rod Chapman 1 sibling, 0 replies; 14+ messages in thread From: Jeffrey Carter @ 2003-02-18 16:47 UTC (permalink / raw) Patrick wrote: > I am using GNAT Ada on Linux. I am trying to port from a Sun > (Solaris) implementation. I didn't write the Ada or 'C' myself, but > am trying to make it work on Linux. The Ada code passes five > parameters to the 'C' code. It is trying to pass the address in each > case so that the 'C' can pass back status in the variables > (parameters). The below Ada code (in tls.ads) contains the definition > of the function "to_c_pointer" to convert the Ada address to a > "c_pointer": > type us1 is range 0..SYSTEM.MAX_INT; > subtype unsigned_long is us1; > subtype c_pointer is unsigned_long; > -- convert ada address into a value that can be assigned > -- to a c pointer. The following is an example of a call to > -- to_c_pointer: TLS.to_c_pointer(i'ADDRESS) > function to_c_pointer is new > unchecked_conversion(SYSTEM.address, c_pointer); > pragma inline(to_c_pointer); > > Here is what the Ada call to 'C' looks like: > DMC_Initialize_Database_Configuration_C( > TLS.to_c_pointer(Configuration_Id_In'ADDRESS), > TLS.to_c_pointer(Configuration_Id_Len'ADDRESS), > TLS.to_c_pointer(Initialization_Status_Ind'ADDRESS), > TLS.to_c_pointer(Init_Failure_Text_In'ADDRESS), > TLS.to_c_pointer(Init_Failure_Text_Len'ADDRESS)); > > Here is what the 'C' funtion definition looks like: > DMC_Initialize_Database_Configuration_C( > char *Configuration_Id, > int *Configuration_Id_Len, > int *Initialization_Status, > char *Init_Failure_Text, > int *Init_Failure_Text_Len) > { > > As I said, there are five parameters. This worked fine under Solaris > (Spark compiler for Ada), but under Linux the address of the 2nd and > 4th parameters ends up being zero on the 'C' side (we can tell this > with a debugger). Using the debugger, it looks like the first > parameter on the Ada side is being passed into the first parameter on > the 'C' side. The second parameter on the Ada side shows up on the > 'C' side as the third parameter. The third parameter on the Ada side > shows up on the 'C' side as the fifth parameter. So, at least on the > surface, it looks as if the size of the parameter on the Ada side is > twice the size of the parameter on the 'C' and it is filling in with > zero. Compare the values of System.Max_Int on the Solaris compiler and GNAT. GNAT supports 64-bit integers on all platforms, while it's likely the compiler used on Solaris only supports 32-bit integers. This might explain what you're seeing. There's no need for all this complication in the interface. You could declare the procedure as taking System.Address for its parameters in Ada, and simply pass the addresses without the conversions. This would be a simple modification to get things working. A C pointer is generally an address, and Ada and C compilers for the same platform generally use the same representation for an address. If you want to put more effort into it, you could check out Annex B and learn how things are passed to a C subprogram, and get some type checking into the call as well. -- Jeff Carter "The time has come to act, and act fast. I'm leaving." Blazing Saddles ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-18 15:39 Ada to 'C' parameter passing problem Patrick 2003-02-18 16:47 ` Jeffrey Carter @ 2003-02-18 19:50 ` Rod Chapman 2003-02-20 2:36 ` Matthew Heaney 1 sibling, 1 reply; 14+ messages in thread From: Rod Chapman @ 2003-02-18 19:50 UTC (permalink / raw) Pat.Donahue@msfc.nasa.gov (Patrick) wrote in message news:<ea3b54bb.0302180739.3cb6c159@posting.google.com>... > I am using GNAT Ada on Linux. I am trying to port from a Sun > (Solaris) implementation. I didn't write the Ada or 'C' myself, but > am trying to make it work on Linux. <snip> This code looks mildly horrible. All that messing about with 'Address and Unchecked_Conversion is in very poor style. My advice: 1) Work out what the true Ada mode of each parameter should be. Just because C forces pass-pointer-by-copy mechanism doesn't mean that you should try to emulate that directly in Ada. Is each pointed-to parameter intended to be read, updated or both? That tells you that each parameter should be "in" , "out", or "in out" in Ada terms. 2) What type is each by-reference parameter actually pointing at? (Integer or "zero-terminated bounded array of character" are probable answers) - that tells you the Ada types that you should be passing. 3) Check out Annex B.3 - The package Interfaces.C gives you lots of stuff (e.g. for turning an Ada String into a null-terminated C string) that's useful. Also read up the small print on what Pragma Import does when you use Convention "C" - that defines how Ada parameters are passed to C - very useful. 4) A C function that has multiple side-effects via by-reference parameters shouldn't be a function in Ada at all - it's a procedure! That should allow you to write a clean Ada binding. - Rod Chapman, SPARK Team, Praxis Critical Systems ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-18 19:50 ` Rod Chapman @ 2003-02-20 2:36 ` Matthew Heaney 2003-02-20 9:18 ` Rod Chapman 0 siblings, 1 reply; 14+ messages in thread From: Matthew Heaney @ 2003-02-20 2:36 UTC (permalink / raw) rod.chapman@praxis-cs.co.uk (Rod Chapman) wrote in message news:<cf2c6063.0302181150.55991a7e@posting.google.com>... > Pat.Donahue@msfc.nasa.gov (Patrick) wrote in message news:<ea3b54bb.0302180739.3cb6c159@posting.google.com>... > > I am using GNAT Ada on Linux. I am trying to port from a Sun > > (Solaris) implementation. I didn't write the Ada or 'C' myself, but > > am trying to make it work on Linux. > <snip> > > This code looks mildly horrible. All that messing about with > 'Address and Unchecked_Conversion is in very poor style. > > My advice: > > 4) A C function that has multiple side-effects via > by-reference parameters shouldn't > be a function in Ada at all - it's a procedure! No, Rod, it's a subprogram that returns a value. There is no difference between a function and a procedure, except for syntax. That Ada doesn't allow you to specify inout mode for function parameters is a deficiency of Ada, especially since it advertises itself as a language that is supposed to facilitate inter-language programming. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-20 2:36 ` Matthew Heaney @ 2003-02-20 9:18 ` Rod Chapman 2003-02-20 9:43 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Rod Chapman @ 2003-02-20 9:18 UTC (permalink / raw) mheaney@on2.com (Matthew Heaney) wrote in message news:> That Ada doesn't allow you to specify inout mode for function > parameters is a deficiency of Ada... Wow! This reflects somewhat of a gulf between our respective views of language design! (Don't get me wrong, neither position is necessarily right or wrong, just different...) At the SPARK end of the spectrum functions calls are expressions which return a value and never have a side-effect. Procedure calls are statements which have side-effects - A rather significant _semantic_ difference! If you do prefer the ability to allow a function to modify its parameters, then it should at least be good enough to confess this to the outside-world as part of its specifiction. The current discussion for Ada0Y in AI231 (extending anonymous access parameters) is welcome here, especially from a static-analysis point of view. - Rod ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-20 9:18 ` Rod Chapman @ 2003-02-20 9:43 ` Dmitry A. Kazakov 2003-02-20 22:05 ` Simon Wright 2003-02-24 23:53 ` Matthew Heaney 2 siblings, 0 replies; 14+ messages in thread From: Dmitry A. Kazakov @ 2003-02-20 9:43 UTC (permalink / raw) On 20 Feb 2003 01:18:34 -0800, rod.chapman@praxis-cs.co.uk (Rod Chapman) wrote: >mheaney@on2.com (Matthew Heaney) wrote in message news:> That Ada doesn't allow you to specify inout mode for function >> parameters is a deficiency of Ada... > >Wow! This reflects somewhat of a gulf between our respective >views of language design! (Don't get me wrong, neither position >is necessarily right or wrong, just different...) > >At the SPARK end of the spectrum functions calls are expressions >which return a value and never have a side-effect. Procedure >calls are statements which have side-effects - A rather >significant _semantic_ difference! > >If you do prefer the ability to allow a function to modify its >parameters, then it should at least be good enough to confess >this to the outside-world as part of its specifiction. The current >discussion for Ada0Y in AI231 (extending anonymous access >parameters) is welcome here, especially from a static-analysis >point of view. [ Long awaited thread "inout parameters for functions" is again here (:-)) ] "To return a value via the result parameter" /= "To have no side effects other than on the out and inout parameters" To mix the above two is definitely a deficiency. To involve pointers as a work-around for consequences of that deficiency is worse than just a deficiency. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-20 9:18 ` Rod Chapman 2003-02-20 9:43 ` Dmitry A. Kazakov @ 2003-02-20 22:05 ` Simon Wright 2003-02-21 9:53 ` Stuart Palin 2003-02-24 23:53 ` Matthew Heaney 2 siblings, 1 reply; 14+ messages in thread From: Simon Wright @ 2003-02-20 22:05 UTC (permalink / raw) rod.chapman@praxis-cs.co.uk (Rod Chapman) writes: > mheaney@on2.com (Matthew Heaney) wrote in message news:> That Ada doesn't allow you to specify inout mode for function > > parameters is a deficiency of Ada... > > Wow! This reflects somewhat of a gulf between our respective > views of language design! (Don't get me wrong, neither position > is necessarily right or wrong, just different...) > > At the SPARK end of the spectrum functions calls are expressions > which return a value and never have a side-effect. Procedure > calls are statements which have side-effects - A rather > significant _semantic_ difference! I recall Robert Dewar saying that he thought that restricting functions to "in" (or access) parameters was a Bad Idea -- Ada is a programming language, not a mathematical abstraction, and there is nothing in Ada to stop a function modifying global state. (Praise be, say I). But Robert got outvoted during the Ada 9X process. There would be nothing to stop SPARK requiring functions to have only "in" parameters -- after all you disallow access parameters & modifying global state! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-20 22:05 ` Simon Wright @ 2003-02-21 9:53 ` Stuart Palin 2003-02-21 17:39 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Stuart Palin @ 2003-02-21 9:53 UTC (permalink / raw) Simon Wright wrote: > I recall Robert Dewar saying that he thought that restricting > functions to "in" (or access) parameters was a Bad Idea -- Ada is a > programming language, not a mathematical abstraction, and there is > nothing in Ada to stop a function modifying global state. (Praise be, > say I). But Robert got outvoted during the Ada 9X process. I would think that there are [at least] a couple of conflicting inputs to this. 1) By allowing functions to have side-effects you create problems related to expression evaluation order - which introduces an additional source of compiler dependencies. 2) Modifying global state is not prevented by the language rules. But this would be so difficult to do within the constraints (or freedoms) of other language objectives (principally the separate compilation of specification and body and the hiding of internal behaviour. Note that SPARK addresses the issue of purity by ensuring the effect on global state is made visible at the specification level). Point 1 suggests it is a bad idea, point 2 shows the language can not be entirely pure on this matter. Would allowing function parameters to be in out/out be encouraging a risky practice, or a recognition that the language can not fully police the concept. I favour the existing language rules which at least do not 'encourage' the risks that might arise through functions with side-effects. [RD does not usually make unconsidered statements, so I would be interested in reading his line of arguments. Is it available somewhere convenient?] -- Stuart Palin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-21 9:53 ` Stuart Palin @ 2003-02-21 17:39 ` Jeffrey Carter 2003-02-21 18:12 ` Warren W. Gay VE3WWG 2003-02-21 20:25 ` Randy Brukardt 2 siblings, 0 replies; 14+ messages in thread From: Jeffrey Carter @ 2003-02-21 17:39 UTC (permalink / raw) Stuart Palin wrote: > Simon Wright wrote: > >>I recall Robert Dewar saying that he thought that restricting >>functions to "in" (or access) parameters was a Bad Idea -- Ada is a >>programming language, not a mathematical abstraction, and there is >>nothing in Ada to stop a function modifying global state. (Praise be, >>say I). But Robert got outvoted during the Ada 9X process. > > [RD does not usually make unconsidered statements, so I > would be interested in reading his line of arguments. Is it > available somewhere convenient?] I'm sure it is; have you tried a search on Google groups? I think I can restate RD's basic argument: Functions already allow side effects, just not explicit side effects on their parameters. Disallowing them is an unnecessary impediment to developers and makes interfacing to other languages more difficult than is necessary; allowing them would make some side effects more visible. -- Jeff Carter "If you don't get the President of the United States on that phone, ... you're going to have to answer to the Coca-Cola Company." Dr. Strangelove ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-21 9:53 ` Stuart Palin 2003-02-21 17:39 ` Jeffrey Carter @ 2003-02-21 18:12 ` Warren W. Gay VE3WWG 2003-02-21 20:25 ` Randy Brukardt 2 siblings, 0 replies; 14+ messages in thread From: Warren W. Gay VE3WWG @ 2003-02-21 18:12 UTC (permalink / raw) Stuart Palin wrote: > Simon Wright wrote: >>I recall Robert Dewar saying that he thought that restricting >>functions to "in" (or access) parameters was a Bad Idea -- Ada is a >>programming language, not a mathematical abstraction, and there is >>nothing in Ada to stop a function modifying global state. (Praise be, >>say I). But Robert got outvoted during the Ada 9X process. > > I would think that there are [at least] a couple of > conflicting inputs to this. > > 1) By allowing functions to have side-effects you create > problems related to expression evaluation order - which > introduces an additional source of compiler dependencies. > > 2) Modifying global state is not prevented by the language > rules. ... > Would allowing function parameters to be in out/out be > encouraging a risky practice, or a recognition that the > language can not fully police the concept. > > I favour the existing language rules which at least do not > 'encourage' the risks that might arise through functions > with side-effects. > > [RD does not usually make unconsidered statements, so I > would be interested in reading his line of arguments. Is it > available somewhere convenient?] > -- > Stuart Palin I can see that there is value in being able to say, while reading somebody's code: "this is a function, hence there is no state change here." But, we all know that this isn't enforced in the language, beyond the trivial aspect of restricting parameter use (even that is inconsistent, because access parameters are permitted). The function being called can be changing state within the package it is defined in, or even calling other functions and procedures that change states in other places to boot. So this idea cannot be trusted to begin with. So with my own personal "practical hat" on, I'd have to side with those in favour of opening up the function arguments to permit in/out, out parameters. The present arrangement only _discourages_ side effects, and perhaps this is something that some feel is worth maintaining. If it becomes a requirement to provide purely functional calls (ie. with no side effect), then I think it is mandatory for some other mechanism to exist and have it enforced by the compiler, IMHO. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-21 9:53 ` Stuart Palin 2003-02-21 17:39 ` Jeffrey Carter 2003-02-21 18:12 ` Warren W. Gay VE3WWG @ 2003-02-21 20:25 ` Randy Brukardt 2 siblings, 0 replies; 14+ messages in thread From: Randy Brukardt @ 2003-02-21 20:25 UTC (permalink / raw) Stuart Palin wrote in message <3E55F70B.A254EAF@0.0>... >[RD does not usually make unconsidered statements, so I >would be interested in reading his line of arguments. Is it >available somewhere convenient?] I believe that all of those arguments were at least partially rehashed on Ada-Comment last fall. You can find that discussion in the !appendix section of AI-323 http://www.ada-auth.org/ais.html Randy. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-20 9:18 ` Rod Chapman 2003-02-20 9:43 ` Dmitry A. Kazakov 2003-02-20 22:05 ` Simon Wright @ 2003-02-24 23:53 ` Matthew Heaney 2003-02-25 17:21 ` Rod Chapman 2 siblings, 1 reply; 14+ messages in thread From: Matthew Heaney @ 2003-02-24 23:53 UTC (permalink / raw) rod.chapman@praxis-cs.co.uk (Rod Chapman) wrote in message news:<cf2c6063.0302200118.63a7ea1d@posting.google.com>... > > Wow! This reflects somewhat of a gulf between our respective > views of language design! (Don't get me wrong, neither position > is necessarily right or wrong, just different...) > At the SPARK end of the spectrum functions calls are expressions > which return a value and never have a side-effect. Procedure > calls are statements which have side-effects - A rather > significant _semantic_ difference! Our disagreement is probably on how this is should be stated in the language. My model is that you only have subprograms, and different kinds of subprograms simply have a different syntax for returning values back to the caller. For example, if I say: O : T; declare Value : constant Value_Type := Get_Value (O); begin then that is exactly equivalent to this: declare Value : Value_Type; begin Get_Value (O, Value); Both of these sequences of statements have exactly the same effect, which is to return an object of type Value_Type, without modifying object O. The keyword used indicate to the compiler that Get_Value is a subprogram is not relevant, and I don't really care what its spelling is. I could change the example around. I can set the value like this: Value : Value_Type := ...; declare Status : Status_Type; begin Set_Value (O, Value, Status); Here, we wish change the state of object O, and Set_Value returns some information back to the caller to indicate whether the state change was successful. We can also rewrite the example like this: declare Status : constant Status_Type := Set_Value (O, Value); begin This has exactly the same effect as in the previous example. The *only* difference in this pair of examples is the syntax of subprogram invokation. Ada95 lets me do both. Apparently SPARK does not. To me this inconsistency seems odd. > If you do prefer the ability to allow a function to modify its > parameters, then it should at least be good enough to confess > this to the outside-world as part of its specifiction. The current > discussion for Ada0Y in AI231 (extending anonymous access > parameters) is welcome here, especially from a static-analysis > point of view. Yes, of course a function should be able to state that it modifies its parameters, especially if it modifies them! Realize, however, that there is a difference between the "logical" view of an abstraction and the "physical" view. For example, the model for the random number is that it is a stream of values, and invoking function Random simply returns the next value in the stream. In this case, it makes more sense that the function accept the generator as an in-only (not inout) parameter. The real issue is telling the compiler that the subprogram modifies its arguments, in a manner independent of subprogram parameter mode (again, because there are distinct views of the type). Ideally, you'd like to state this at the time of declaration of the type (instead of letting the compiler infer this when it sees the body of the package, which is necessarily later). C++ solved this problem by introducing a "mutable" keyword to inform the compiler that this variable is subject to modification, irrespective of whether the member function is declared as const: class C { mutable int i; public: void f() const; }; and where void C::f() const { ++i; } Ada doesn't always do a great job of separating the logical properties of the type from its physical properties, and it tends to conflate the two, e.g. package P is type T is range 0 .. 255; function "+" (L, R : T) return T; --clamped add end P; How should one implement "+" without getting infinite recursion? It seems to me that it would be better to have an explicit way of indicating to the compiler that a subprogram parameter is modified. (The spelling of the keyword that indicates to the compiler that this is a subprogram is not relevant). Now the compiler must sort of guess, by looking at the declaration, e.g. type T is limited record Handle : Handle_Type (T'Access); --Rosen Trick ... end record; Does that make it obvious to the compiler? I don't really know. Now of course I realize that some programmers do make a distinction between subprograms that are spelled "function" vs. spelled "procedure". I do not make such a distinction. If you decide that subprograms spelled "function" should not modify their arguments, then you are free to write your programs that way, and I won't try to stop you. However, where I must object is when those programmers try to tell *me* that that's how I should write *my* programs. What the original Ada83 language designer did was to overstep his authority, and legislate what I should do. But the locution I choose to invoke a subprogram that modifies its arguments should be none of his business. The purpose of a programming language is to make it easy for a programmer to write programs. The language designer should not decide by fiat how that should be done. Both the language and its designer should stay out of the programmer's way, and assume that it is the programmer himself who is in the best position to decide whether a value-returning subprogram is appropriate for the problem at hand. So I don't agree with your characterization of this as a "language design" issue. If you want to try to convince me (via forums like CLA, etc) that a function shouldn't modify its arguments, then you're free to do that. (And I would be interested in your arugments, even if I don't happen to agree with them.) But what you should NOT do is to force me to do it your way by designing the language such that subprogram parameter modification is prohibited by the rules of the language. You the language designer would be overstepping the limits of your authority, with the concomitant effect that programmers will either circumvent the rules, or simply chose another language. A programming language is the programmer's servent, not his master. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada to 'C' parameter passing problem 2003-02-24 23:53 ` Matthew Heaney @ 2003-02-25 17:21 ` Rod Chapman 0 siblings, 0 replies; 14+ messages in thread From: Rod Chapman @ 2003-02-25 17:21 UTC (permalink / raw) mheaney@on2.com (Matthew Heaney) wrote in message news: > The purpose of a programming language is to make it easy for a > programmer to write programs. The language designer should not decide > by fiat how that should be done. Both the language and its designer > should stay out of the programmer's way, and assume that it is the > programmer himself who is in the best position to decide whether a > value-returning subprogram is appropriate for the problem at hand. Aha! I just can't resist steaming back in here... For high-integrity applications, "ease of writing programs" is hardly ever the most important thing. We're really interested in the ease, efficiency and cost of _verification_ of such programs. With that in mind as our primary design goal, then (as a language designer), we sometimes _do_ remove or constrain language features - the lack of function side-effects in SPARK is one such example. In this case we think it's worth it - the entire data-flow, information-flow, and VC-Generation facilities of SPARK depend on this particular property of the language (and many others...). We are acutely aware of the trade-off between expressive power and analysability/verifiability of the language, so we don't take these decisions lightly. Matt might find SPARK too restrictive for his interests and application domain, which is just fine. Many of our users think SPARK is about right. A few of them think it's too big! Vive la difference! All the best, Rod ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Ada to 'C' parameter passing problem @ 2003-02-21 16:52 Lionel.DRAGHI 0 siblings, 0 replies; 14+ messages in thread From: Lionel.DRAGHI @ 2003-02-21 16:52 UTC (permalink / raw) To: comp.lang.ada | -----Message d'origine----- | De: Stuart Palin [mailto:null@0.0] ... | [RD does not usually make unconsidered statements, so I | would be interested in reading his line of arguments. Is it | available somewhere convenient?] Search for example the 4 Nov 2001 05:07:42 answer to Nick Roberts in the "Re: Rosen Trick [List container strawman]" thread. It begins with "Here are the facts:", it's a kind of signature, isn't it? :-) Lionel Draghi ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-02-25 17:21 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-02-18 15:39 Ada to 'C' parameter passing problem Patrick 2003-02-18 16:47 ` Jeffrey Carter 2003-02-18 19:50 ` Rod Chapman 2003-02-20 2:36 ` Matthew Heaney 2003-02-20 9:18 ` Rod Chapman 2003-02-20 9:43 ` Dmitry A. Kazakov 2003-02-20 22:05 ` Simon Wright 2003-02-21 9:53 ` Stuart Palin 2003-02-21 17:39 ` Jeffrey Carter 2003-02-21 18:12 ` Warren W. Gay VE3WWG 2003-02-21 20:25 ` Randy Brukardt 2003-02-24 23:53 ` Matthew Heaney 2003-02-25 17:21 ` Rod Chapman -- strict thread matches above, loose matches on Subject: below -- 2003-02-21 16:52 Lionel.DRAGHI
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox