Perl/PPCs/ppcs/ppc0004 defer block の翻訳

この文書は、Perl/PPCs/ppcs/ppc0004-defer-blockを翻訳したものです。

原題は、「Deferred block syntax」です

Deferred block syntax

(遅延ブロック構文)

Preämble 序文

翻訳注：こちらは原文の情報です。

Author:  Paul Evans <PEVANS>
Sponsor:
ID:      0004
Status:  Implemented

Abstract 要約

defer { BLOCK }と記述する新たな制御フロー構文を追加します。この構文は、コードブロックを遅延実行するため、キューにコードブロックを追加し、スコープを抜けた際にそのコードブロックを実行します。

Motivation 動機

コードの"セットアップ"操作を行い、そのタスクの終わりに"後処理"が必要になることがあります。例外が投げられた時やループ文の時の制御フローを考慮すると、常に次のコードのように簡潔には書けません。

{
  setup();
  operation();
  teardown();
}

このコードの場合、もし、operation関数が例外を投げると、後処理が行われません。これに対する伝統的な解決策は、DESTROYメソッドを持つ何らかのオブジェクトをレキシカル変数に割り当て、変数のクリーンアップ時のオブジェクト破壊時に必要なコードを実行するというものです。このプロセスを自動的に行うモジュールはコアにはありませんが、CPANモジュールのScope::Guardはよく取られる選択肢です。

この一般的な振る舞いがネイティブのコアの構文として提供できれば良さそうです。defer { BLOCK }と書くだけで良ければ、ガードオブジェクトをレキシカル変数に保存することや、適切なタイミングに本当にリリースされたか心配する必要がなくなります。

この構文は、Syntax::Keyword::Deferとして、CPANモジュールとして既に実装されています。このPPCによって、コアで同じ実装を試みることを正式化しています。

Rationale 提案理由

((TODO - 動機の段落とこの段落の言葉を私は明確に区別できてないです。))

"defer"という命名は、他の言語から取っています。Swift、Zig、Jai、NimやOdinとほぼ同じ構文が提供されています。Goは、単一のステートメントに作用するdeferキーワードを定めていますが、Goでは、単一のレキシカルブロックではなく、deferを含んだ関数の終わりまで処理を遅延します。私はこの違いを考えましたが、このGoとの違いの懸念よりも、純粋なレキシカルスコープの性質の方が明確で、より"Perlish"だと判断しました。

Specification 仕様

新たなレキシカルスコープの特性は、以下のようにして要求されます。

use feature 'defer';

これにより新たな構文が有効になり、以下のように利用できます。

defer { BLOCK }

この構文は、whileループなどと同様に、完全にステートメントとして独立しています。遅延実行されるブロックは、一つもしくは複数のステートメントを含みます。

通常のコード実行中に、deferステートメントがあったら、すぐには何も起こりません。ブロックの内容はperlインタプリンターによって保存され、このdeferステートメントが含まれるブロックから制御を抜ける際に、遅延呼び出しされるようにキューに追加されます。

もし同じブロックで、複数のdeferステートメントがあった場合、LIFOの順で実行されます。つまり、次のコードのように、最も最近遭遇したコードが、最初に実行されます。

{
  setup1();
  defer { say "This runs second"; teardown1(); }

  setup2();
  defer { say "This runs first"; teardown2(); }
}

deferステートメントは、その行が、実際に制御フローで現れた時のみ"活性化"されます。(コンパイラが解析すれば活性化されるENDブロックとは異なります。) もし、deferステートメントに到達しない場合、遅延されたコードは呼び出されません。

while(1) {
  defer { say "This will happen"; }
  last;
  defer { say "This will *NOT* happen"; }
}

*((TODO: 現時点では明確にドキュメント化されていませんが、CPANバージョンとコアバージョンの両方の現状の実装から自然と次のことが導かれます。deferが実装しているLIFOスタックによって、localによる変更など他のものも実装しています。例えば、次のコードをみてください。

our $var = 1;
{
  defer { say "This prints 1: $var" }

  local $var = 2;
  defer { say "This prints 2: $var" }
}

((この偶然の一致を、ドキュメントに明記し保証するか、このまま言わないでおくか、私はまだ強い意見を持っていません。))

非ローカルな制御フロー（next/last/redo、gotoやreturn)が、deferブロックの境界を超えようとすることは許可されません。

foreach my $item (@things) {
  defer { last; }  ## This is NOT permitted
}

もしこれを試みた場合、例外が発生します。おそらく次のようなエラーメッセージでしょう。

Attempting to 'last' out of a 'defer' block is not permitted at FILE line LINE.

もちろん、非ローカルな制御フローであっても、deferブロックの中に全て完結するのであれば、許可されます。ブロックを抜けようとする場合のみ禁止します。

{
  defer {
    foreach my $i ( 1 .. 10 ) {
      last if $i == 5;  ## This is permitted
    }
  }
}

これのただ一つの例外は、deferブロックの中で例外が発生(言葉遊びで失礼)した時に、呼び出し元に伝搬することです。

例えば、次の例をみてください。

sub f {
  defer { die "This is thrown\n"; }
}

f();

呼び出し元は、通例のブロック(deferではないブロック)で例外が発生したのと同じように見えます。

現在、スタックが展開されている最中に、deferブロックで例外が発生した時の動作は未定義です。

{
  defer { die "Exception A\n"; }
  die "Exception B\n";
}

このケースにおいて、呼び出し元は、このコードから例外が投げられることを確実に見ることになりますが、その例外が、A、B、あるいはこの2つの例外の組み合わせのような別の何かとなるか現時点では保証はありません。これは将来の拡張性のため意図的に保留しています。もし、perlが真のオブジェクト型のコアの例外を持つことになったら、その際には、"二重例外"のような何かで表現できるかもしれません。

Backwards Compatibility 後方互換性

この新たなdefer { BLOCK } 構文は、レキシカルフィーチャーガードで守られます。フィーチャーガードを認識しない静的解析器の場合、間接呼び出し構文と誤解するかもしれませんが、これはtry/catchといったブロックを制御するフィーチャーガードで保護された他のキーワードと大差ありません。

古いPerlバージョンとの簡単な互換性のために、上記で言及したCPANの実装が利用できます。もし、このPPCが、コア構文に追加することに成功したら、Feature::Compat::Deferモジュールを、Feature::Compat::Tryと同様の形で作れます。

Security Implications セキュリティへの影響

予想されるものはありません。

Examples 例

いくつかの小さなコードは上述の通りです。他には、Syntax::Keyword::Deferのドキュメントからも引用できます。

use feature 'defer';

{
  my $dbh = DBI->connect( ... ) or die "Cannot connect";
  defer { $dbh->disconnect; }

  my $sth = $dbh->prepare( ... ) or die "Cannot prepare";
  defer { $sth->finish; }

  ...
}

Prototype Implementation プロトタイプ実装

既に言及されているCPANモジュールのSyntax::Keyword::Deferがあります。 加えて、breadperlにほぼ完全なブランチがあります。(まだ5.34のリリースに関する更新を行ってないためいくらか遅れてます)

https://github.com/leonerd/perl5/tree/defer

私はまだ実装に満足していません(遅延されたOP木を保存するために、SVOPを乱用したのを見ないでほしいです)。私がCPANモジュールを書く間に学んだ様々なことを踏まえて、修正し、整理する必要があります。

Future Scope 将来の見込み

このPPCが実装された場合、Perl 5.34で追加されたtry/catch構文にfinally句を追加するために、この同じ仕組みを利用するかどうかという疑問が自然に沸きます。この問は未解決です。つまり、新たな能力ではなく、新たな表現力と一部のユーザが慣れた方法であることが、同じ事を書くのに2つのやり方を持たせるに足る正当な理由かどうか？

加えて、コアの例外が、単なる文字列ではなく、メタデータやオブジェクトのような表現力を持つようであれば、deferは上述された二重例外のケースに対処できるようになります。

Rejected Ideas 却下されたアイデア

名称について言えば、元々はLEAVE {}と呼んでいました。ですが、Raku言語の同名のものと意味が一致しないため却下されました。その後、CPANで実装された時、FINALLY {}と改名されました。ですが、try/catch/finallyと似すぎているため、また、SHOUTY PHASER BLOCKであるべきではないといった理由で却下されました。全てのSHOUTY PHASER BLOCKは宣言であり、コンパイル時に単に存在するだけで、活性化されます。一方、defer {}は実行時に実際に遭遇した場合のみ効果を発揮します。p5pのメーリングリストやそのCPANモジュールのRTには、UNWIND、UNSTACK、CLEANUPといった様々な却下された命名案が残っています。

他に却下されたアイデアは、次のコードのような条件つきのキューです。

defer if (EXPR) { BLOCK }

これは複雑な文法になる一方、利点があまりないため却下されました。現在の文法だと、deferキーワードに続くブロックは、ブレースで区切られている必要がありますが、こういった別のアイデアは、後日、考慮する可能性があります。

Open Issues

設計面では、未解決の問題はなさそうです。

実装面では、まだ作業すべきことがあり、まだマージできる状態ではありません。

Copyright

Copyright (C) 2021, Paul Evans.

This document and code and documentation within it may be used, redistributed and/or modified under the same terms as Perl itself.