Re: Proposal: pragma Assumption

["Santiago Urueña" <suruena@gmail.com>]

> I don't get it. If you remove the package containing Unimplemented from the
> program (as you should do in this case), any remaining references will be
> caught by the compiler as undefined. I don't see how that is different from
> some sort of compiler switch -- it's just as easy to forget changing that.
> Anything that requires a change is a bad thing!
>
The compiler switches for the production and debugging builds are
always carefully chosen, so if by default that pragma is rejected by
the compiler IMO it is unlikely that somebody add it to the production
build script by accident (but it will be quickly added to the debug
target if somebody uses it).

> These days, "production" systems and "debugging" systems often are the
> same -- computers are fast enough that there is rarely a need to remove the
> debugging code. (And leaving it in can help technical support a lot,
> especially when customers can't send a code sample for one reason or
> another.) So anything that depends on a difference in building a system is
> dubious in my view.
>
I agree, and that's fine. In that case pragma Assumption would only
document that: whereas an Assert is (in theory) always true, a pragma
Assumption highlights that that code is not completely finished, and
that it is known that in some cases it will fail.

In both cases, when any Assertion exception is raised, that data
should be sent to the technical support (in fact, that's exactly what
Tony Hoare explains in the article). Probably there is no need to add
another exception when triggering a bad assumption, but it could be
added if somebody thinks that those cases should be handled
separately.

> Moreover, I don't see anything that this feature would provide that is
> really helpful. Our coding standard includes a structured comment:
>     -- **Temp: <explanation>
> for anything that requires later work. I personally usually use "raise
> Program_Error;" or a call to a routine defined for that purpose (the
> Janus/Ada optimizer has a routine "Die(<reason>)" for instance) if code is
> left out for any significant period. The structured comment allows future
> finding of these areas if desired. But it isn't uncommon to decide to not
> bother with implementing such things: if the case never happens, it's
> probably a waste of time to implement it. In which case the comment and
> "Die" may live for a long time.
>
This pragma just reflects common software development processes,
adding support to the language to the incremental and iterative
schemes.

(BTW, they are not the same! see: http://www.stsc.hill.af.mil/crosstalk/2008/05/0805Cockburn.html
)

> Finally, as a pragma, there is nothing preventing an implementer from adding
> it if it is found useful. There doesn't seem to be any compelling reason to
> add it to the language in order to get it implemented. As such, I'd
> recommend that such a proposal be filed as an AC (received no action).
>
> If you can convince some implementers to implement it, *and* it proves
> useful, *then* it might be considered for future standardization. But not
> without something that cannot currently be done.
>
Thanks for the advice, I think that's the way to go!

--
Santiago Urueña Pascual
Technical University of Madrid (UPM)