Re: Proposal: pragma Assumption

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3122 bytes --]

"Santiago Urue�a" <suruena@gmail.com> wrote in message 
news:4d2bb014-c956-454b-bcfb-a98cd524e5b4@m36g2000hse.googlegroups.com...
...
>>    -------------------
>>    -- Unimplemented; --
>>    -------------------
>>
>>    procedure Unimplemented is
>>    begin
>>       Ada.Exceptions.Raise_Exception
>>         (Program_Error'Identity, "interrupts/signals not implemented");
>>       raise Program_Error;
>>    end Unimplemented;
>>
>> Then call "Unimplemented;"  where needed. and remove the call when
>> routine is corrected.
>>
>I also considered this approach (but of course the procedure was
>called "Asumption" and it received a boolean parameter :-), but when
>compiling the final binary you are again at risk of forgetting to
>search for any remaining calls to that procedure or to remove its body
>(people make that kind of mistakes all the time). Instead, with pragma
>Assumption the compiler will warn you, anyway it is common practice to
>have different compilations options for each development phase, and
>unless that option is explicitly added the compiler will reject any
>occurrence of that pragma.

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!

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.

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.

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.

                                  Randy Brukardt.