Re: A suggestion for resource management

[Florian Weimer <fw@deneb.enyo.de>]

* Niklas Holsti:

> Florian Weimer wrote:
>> Here's a proposal for a resource management pragma, tentatively called
>> pragma Scoped.  It is similar to the scope(exit) directive in D, the
>> C++ scope guard idom, and (to a lesser degree) Go's rescue statement.
>>
>> The syntax is:
>>
>>    pragma Scoped (procedure_call_statment);
>
> I strongly dislike the idea of using "pragma" to introduce such
> non-obvious flow of control.

In a sense, it's just repeating what Unchecked_Deallaction does behind
the scenes.

> Flow of control should be clearly represented in the syntactic
> structure, with textual order matching execution order. The current
> exception-handling syntax is good in that respect.

I understand that goal.  However, this approach separates the
initialization from the clean-up code, and the clean-up code might
need repeating in several places.  This cannot be good.

>> Regarding dynamic semantics: When a Scoped pragma which is part of a
>> handled_sequence_of_statements is executed or when it is elaborated as
>> part of a declarative_part, the procedure_name or procedure_prefix and
>> actual parameters of the procedure_call_statment are evaluated.
>
> ... and, if I understand your suggestion, the evaluated parameters are
> saved somewhere, in case they are needed for the later call. I think
> this can cause large run-time overheads, as well as confusion and
> errors. How "deeply" are the parameters saved?

renaming-declaration-deeply, so it really depends on the types
involved.  This happens with any procedure call, so the overhead
cannot be huge.

> The semantics will depend on whether a type is passed by value or by
> access, right?

Not really.  The idea is to avoid strange action-at-a-distance if the
actual arguments change their value between execution of the pragma
and the embedded procedure call.

> Also, saved parameters of access type may become unusable (hanging
> pointers) if the statement_sequence deallocates the accessed object.

Ordinary procedure calls suffer from this problem, too.  As far as I
can see, this can only happen with Unchecked_Deallaction, so it is
acceptable.

> You did not discuss if "pragma Scoped" could be executed
> conditionally, as in:
>
>    Do_Something ( ... Success => Ok);
>    if Ok then
>       pragma Scoped (Undo_Something (...));
>    end if;
>
> Is this included in your suggestion?

The branches of an if statement aren't a
handled_sequence_of_statements, so it's not allowed.

>> The example at the end of section B.4 could use the Scoped pragma in
>> this way:
>>
>>           procedure Test_External_Formats is
>>              ...
>>              COBOL_File : File_Type;
>>              ...
>>
>>           begin
>>              Open (COBOL_File, Name => "Some_File");
>>              pragma Scoped (Close (COBOL_File));
>>
>>              loop
>>                ...
>>           exception
>>              when End_Error => ...
>>           end Test_External_Formats;
>
> If I understand your suggestion correctly, more or less the same
> behaviour can be achieved in current Ada by a statement block:
>
>    procedure Test_External_Formats is
>       ...
>       COBOL_File : File_Type;
>       ...
>    begin
>       Open (COBOL_File, Name => "Some_File");
>       begin
>          loop
>             ...
>          end loop;
>       exception
>          when End_Error => ...
>       end;
>       Close (COBOL_File);

You also need this here:

     exeption
        when others =>
           Close (COBOL_File);
           raise;

plus another level of nesting because you shouldn't call Close when
Open results in an exception, and when Close itself raises an
exception.

>    end Test_External_Formats;
>
> I find that form clear and brief enough, although I admit that
> nesting depth may become awkwardly large (the remedy is to split the
> procedure).

No one will write such code unless forced to do so by some static
analysis tool.  It's rather messy.  It's actually pretty difficult to
see if all clean-ups occur as needed.  If the subprogram needs two
objects which require clean-up, it will not fit on a single screen
anymore.  Splitting it up into two outer subprograms which perform
initialization and cleanup for each object and another one which does
the bulk of the work will not add much value to the reader, either.

> I'm not sure if your suggestion is that the "pragma" procedure call
> (here, Close (COBOL_File)) should be performed also if an exception is
> propagated from the exception handler of the
> handled_sequence_of_statements. My version above does not perform
> Close in that case. If Close should be performed in that case, I would
> very much prefer new syntax for a "finally" structure placed at the
> end of the handled_sequence_of_statements, after the exception handler
> if any, over the "pragma" suggestion.

"finally" was state-of-the-art in 1995.  I'm not sure if it still can
be considered good language design.  Most languages which strive for
exception safety are gradually moving to different constructs (even
Java).  "finally" is much less syntactically heavyweight than nested
exception handling blocks, but programmers still do not use it
consistently.