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!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.158.31.10.MISMATCH!newsfeed-0.progon.net!progon.net!kasuga.switch.ch!kanaga.switch.ch!switch.ch!news.belwue.de!LF.net!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: A suggestion for resource management Date: Sat, 21 Aug 2010 23:01:57 +0200 Message-ID: <87eidr3cje.fsf@mid.deneb.enyo.de> References: <8762z4gcoi.fsf@mid.deneb.enyo.de> <8darikF1b0U1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: idssi.enyo.de 1282424517 7467 172.17.135.6 (21 Aug 2010 21:01:57 GMT) X-Complaints-To: news@enyo.de Cancel-Lock: sha1:C28pGNibQkBh9O5nmowHYkYY8fM= Xref: g2news1.google.com comp.lang.ada:13585 Date: 2010-08-21T23:01:57+02:00 List-Id: * 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.