help / color / mirror / Atom feed
From: mockturtle <>
Subject: Contracts in generic formal subprogram
Date: Sat, 8 Apr 2023 00:00:38 -0700 (PDT)	[thread overview]
Message-ID: <> (raw)

this is something that looked like a natural and nice idea to me, but the compiler disagree :-): specifying contracts in formal subprograms in generic declarations.  Actually,   RM 12.6 does not prohibit this on a syntactic level (a aspect_specification part is included), but the compiler complains.

To understand what I mean, please check the following real code toy-zed (can you hear the grammar screaming?)
   type Ring is private;

   with function Divides (Num, Den : Ring) return Boolean;   
   with function Is_Invertible (X : Ring) return Boolean;   
   with function Inv (X : Ring) return Ring
       Pre => Is_Invertible (X);
   with function Gcd (X, Y : Ring) return Ring
       Post => Divides (X, Gcd'Result) and Divides (Y, Gcd'Result); 
package Pippo is
   -- stuff
end Pippo;
The meaning I have in mind is something like

* For "Pre" aspect: who writes function Inv  can assume that X is invertible since Inv will never be called (by the package code, at least) with X not invertible.   Also Inv cannot have a stricter pre-condition.  In a sense, the package expects Inv to work correctly if and only if the pre-condition is true.

* For "Post" aspect: I expect that the result of GCD satisfies the post condition.  Post conditions for the actual subprogram can be stricter, as long as the post condition of the formal parameter is satisfied.  For example, if Ring is Integer, GCD could always return a positive value that divides both X and Y.  The fact that the result is positive does not hurt.

Should   the actual subprogram specify the same contract?  I am not sure (and I guess this could be a stumbling block for the adoption of this idea).  One could say that the actual subprogram gets a contract that is the AND of the actual subprogram and the contract specified in the generic declaration, it is up to the programmer to check that they are compatible.  I guess the compatibility could be verified by the compiler itself in simple cases, but I expect that this could not be feasible in some cases (maybe of academic interest?).


             reply	other threads:[~2023-04-08  7:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-08  7:00 mockturtle [this message]
2023-04-08  8:02 ` Contracts in generic formal subprogram Dmitry A. Kazakov
2023-04-11  5:56   ` G.B.
2023-04-11 12:03     ` Dmitry A. Kazakov
2023-04-12  2:18       ` Spiros Bousbouras
2023-04-12  3:37         ` Spiros Bousbouras
2023-04-12  6:49           ` Niklas Holsti
2023-04-12  7:30           ` G.B.
2023-04-12 12:29           ` Ben Bacarisse
2023-04-13  6:27         ` Dmitry A. Kazakov
2023-04-08  9:09 ` Randy Brukardt
2023-04-08 16:48 ` Simon Wright
2023-04-08 17:27   ` mockturtle
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox