J3/04-212 Date: 2004-01-14 To: J3 From: Walt Brainerd Subject: Add an ASSERT executable statement and 3 helper functions Date: 2003-12-05 at 09:33:17 Request number: Pub-105 Name: Dick Hendrickson E_mail: dick.hendrickson@att.net ================================================================ Number: Title: Add an ASSERT executable statement and 3 helper functions Submitted by: J3 Status: For Consideration References: Basic Functionality: Add an executable statement of the form ASSERT (alexp, [string],[level]) where alexp is either a simple-logical-expression or a non-simple-logical-expression. The value of alexp shall be TRUE If string is absent it is as if it were present with the value who_am_i(some_argument)//"alexp". If level is absent, it is if it were present with the value 1 Execution of an assert statement has no effect. Add 3 helper functions: WHO_AM_I (logical-flag) if logical-flag has one value (or is absent) the result is a string with the name of the subprogram in it. If logical- flag has the other value, the result is "module:subprogram" USUALLY(alexp) The result of USUALLY is TRUE RARELY(alexp) The result of RARELY is TRUE There are no restrictions on alexp for either function. Rationale: It allows the user to explicitly state things that must be true in a subprogram in a way that can be checked or bypassed at execution time. It allows the user to give explicit hints to the optimizer in both a portable and checkable way. By splitting the alexp into simple and non-simple, where simple for example has no .AND., etc. operators, only simple inquiry functions, only simple integer operations, etc, vendors would be strongly encouraged to parse the simple expressions and use them in their optimization decisions. They could also parse the non-simple ones. But, the intent is to make the simple ones a portable way to say simple things about a routine so that almost all optimizers will be pressured to do the right thing. This, obviously, requires input from vendors. The RARELY and USUALLY functions in an ASSERT would be hints for optimization as opposed to flat out truths. Thus, for example, ASSERT (MOD(N,4) == 0) DO I = 1,N would allow a processor to unroll the loop by 4 and NOT generate checking code. Whereas, ASSERT(USUALLY(MOD(N,4)==0)) would tell a processor that unrolling by 4 is a darn good idea, but that checking code is needed. ASSERTs would most likely occur at the start or end of a subprogram for "programming by contract" or just before a DO loop as an optimization hint. Estimated Impact: It only adds one more executable statement that follows the normal rules of executable statements, it can be a branch target, can't be mixed with the declaratives, etc. Execution of an ASSERT has no effect, hence it's reletivily easy for a naive code generator to process. A more reasonable implementation would be something like IF (level < some_command_line_or_environment_value .and. .not. alexp) STOP string This allows the user to get run-time checking during debugging and allows for fast execution once a program is completely debugged. Detailed Specification: see above. If this idea really flies, we could think about allowing simple asserts to be part of the declarations and hence part of the interface information and hence take part in generic resolution. This sounds like a darn good idea for a subsequent revision of the standard. History: Submittied as Pub-105