From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,7fcf9180e7ba7ab1
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: A suggestion for resource management
Date: Sat, 21 Aug 2010 23:34:28 +0300
Organization: Tidorum Ltd
Message-ID: <8darikF1b0U1@mid.individual.net>
References: <8762z4gcoi.fsf@mid.deneb.enyo.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net PSwFAqW2LkFC3htkxAUP7AfrgBrlYvm4C6RLIAoJT5X2isbc2s
Cancel-Lock: sha1:9sOgnUUP7IzdElej+WWwbV721+8=
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328)
In-Reply-To: <8762z4gcoi.fsf@mid.deneb.enyo.de>
Xref: g2news1.google.com comp.lang.ada:13583
Date: 2010-08-21T23:34:28+03:00
List-Id: <comp.lang.ada>

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.

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.

> 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? The semantics will depend 
on whether a type is passed by value or by access, right? Also, saved 
parameters of access type may become unusable (hanging pointers) if the 
statement_sequence deallocates the accessed object. The state of the 
relevant objects may also change in some other non-obvious but 
significant ways that invalidate the saved parameter values.

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 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);
    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).

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.

In summary, the present language already has tools for this need, either 
finalization (as Dmitry suggested) or the nested block shown above. 
Cases where the present tools are not ideal could be covered by a new 
"finally" construct.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .