スキップしてメイン コンテンツに移動

仕事で使わない Perl コーディングテクニック

ラベル:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan

(まずもって、デバッグがプログラミングの倍も難しいことは衆知である。だからもしあなたが能う限りの知力でコードを書いたとしたら、どうやってデバッグするのか？)

言語のマイナ機能とか関数のデフォルトの挙動なんかを駆使してプログラムを書くと未来の自分や同僚が困るので、普段はいくらか制限して書くと思う。 僕は Perl 5 だとライブラリはともかくアプリケーションのコードは「続・初めてのPerl (Intermediate Perl)」程度の知識を前提して書いていた。

要するに意図的に低俗なコードを書いているわけで面白くない。 だいたい頭の内にあるボンヤリとした「Perl 的な書き方」が実際に動くのがこの言語の良いところで、昔2ちゃんねるで見かけた「キモいが矛盾していない、それが Perl」というコメントはけだし慧眼だったと思う。

そんなわけでマイナであったり環境の都合で自制していた言語機能をいくつか紹介したい。

メソッドの事前解決

Perl 5 のメソッド呼出しは遅い。まずもってメソッドの解決が遅い。繰り返し同じメソッドを呼ぶときはメソッドを一度だけ解決してそれを直接呼び出したい。要するに Objective-C で selector を取得してそれを実行するようなことをやりたい。

名前のせいで述語と勘違いしがちだが UNIVERSAL::can はまさにこのメソッド解決を行う。例えば my $do_foo = $obj->can('do_foo'); とすれば $obj が属するパッケージないしその親クラスに存在する do_foo メソッドへのリファレンスが得られる。存在しない場合は undef である。

そうとなれば後は簡単で、メソッドは第一引数にインスタンスないしクラス名を受けるただのサブルーチンなので、$do_foo->($obj, ...) と呼び出せば動くことは動く。 しかしこれは不恰好である。抽象が破れているではないか。何故メソッド呼び出しだったものを関数呼び出しに書き換えなければならないのか。

実はメソッド呼び出しの矢印演算子の右辺には CodeRef が置ける。この場合メソッド解決は省略され、単に左辺を第一引数として右辺の CodeRef が呼ばれる。つまり解決済みの $do_foo メソッドを呼び出すには $obj->$do_foo(...) とすれば良い。

この事実は perlop と perlobj に載っているが、そもそもメソッド名は裸のワードであるから都合の良いときはほぼいつでもシンボリック・リファレンスで与えられることを我々は知っている。そうなればハード・リファレンスに拡張されることも自然に類推できる。

Perl 5.24 にて実験を行った。簡単なカウンタを作り、百万回 incr メソッドを呼んで数値をインクリメントする。"regular" は毎回メソッド解決を行い、"resolved" は can で解決済みのメソッドを使う:

#!/usr/bin/env perl

use strict;
use warnings;
use Benchmark qw/cmpthese/;

package Counter {
  sub new {
    my ($class, $initial) = @_;
    bless \$initial => $class;
  }

  sub count {
    my ($self) = @_;
    $$self;
  }

  sub incr {
    my ($self) = @_;
    ++$$self;
  }
}

cmpthese(
  -5,
  +{
    regular => sub {
      my $counter = Counter->new(0);
      $counter->incr for 1 .. 1_000_000;
    },
    resolved => sub {
      my $counter = Counter->new(0);
      my $incr = $counter->can('incr');
      $counter->$incr for 1 .. 1_000_000;
    },
  },
);

結果は以下の通りで、解決済みのメソッドを使う方が20ポイントほど高速であった:

bash-3.2$ perl ~/toybox/sel.pl
           Rate  regular resolved
regular  3.73/s       --     -18%
resolved 4.56/s      22%       --

ブロックの last / redo

ブロックは新しい字句的スコープを導入する。これはガードオブジェクトと組み合わせて確実にリソースを開放したいときなどに便利だが、それだけに留まらない。

ブロックは「一回こっきり実行されるループ」と見なして良い。つまりループ制御コマンドの last/redo はループでないただのブロックでも使用できる (next も使えるが last と同じになるので意味はない)。

これは途中で失敗したときにやり直す処理を書くのに便利である:

my @resources = (...);
my @locks;
my $retries = 0;
my $lock_succeed = 0;
TRY_LOCKS:
{
    last if $retries >= 3;
    for my $resource (@resources) {
        my $lock = try_lock($resource);
        unless ($lock) {
            ++$retry;
            @locks = ();
            redo TRY_LOCKS;
        }
        push $locks, $lock;
    }
    $lock_succeed = 1;
}

if ($lock_succeed) { ... }

Key-Value ハッシュスライス

これは Perl 5.8 フリーな環境では仕事で使っている人もいるかも知れない。

perldelta をちゃんと毎回読んでいる人には衆知だが Perl 5.20 からの新機能。Perl 5.10 の // defined-or 演算子や Perl 5.14 の /r 非破壊的置換修飾子以来のキラー機能だと思う。 要するにハッシュの一部だけを抜き出して偶数サイズのリストにする機能で、構文は大方の想像通り:

my %source = (foo => 1, bar => 2, baz => 3);
# equivalent: map { $_ => $source{$_} } qw/foo bar/;
my %projected = %source{qw/foo bar/};  # (foo => 1, bar => 2)

ちなみに exists や delete 演算子などと同様に配列にも一般化されている:

my @source = 'a' .. 'z';
# equivalent: map { $_ => $source[$_] } [3, 4, 5]
my %projected = %source[3, 4, 5];  # (3 => 'd', 4 => 'e', 5 => 'f')

少々異和感を覚えるが、代入の両辺で sigil が揃う点で一貫しているし慣れの問題だろう。

左辺値の返却

関数やメソッドは左辺値を返せる。左辺値であるからにはつまり代入できる。

C++ でも lvalue 参照を使うと同じことができて、std::map の operator[] なんかが典型である。

組み込み関数で左辺値を返す典型は substr / vec / splice である。 perldoc -f substr を見るとプロトタイプは次のようになっている:

substr EXPR,OFFSET,LENGTH,REPLACEMENT
substr EXPR,OFFSET,LENGTH
substr EXPR,OFFSET

この内4引数版に代入するのはナンセンスなのでエラーになるが、2引数版と3引数版は第一引数 (EXPR) が左辺値であれば代入ができる:

my $str = 'bar';
substr($str, 2, 1) = 'z';  # $str eq 'baz'

つまり右辺の値は4引数版の第四引数に相当する。substr は第一引数への一種のビューを提供しているとも見なせるが、実際にはそれ以上のことを行う。代入される文字列の長さが substr で得られた文字列と異なる場合は元の文字列が伸縮する。例えば空文字列を代入することで部分文字列を削除できる。

ちなみ代入式全体の値は元の (置換された) 文字列である。上記の例であれば 'r' が返る。

同様にvec はビット列に対してビット列を代入することができるし、splice は配列に対してリストを代入できる。

また少し意外なものとしては keys も左辺値を返す。これは C++ の STL コンテナにある reserve メンバ関数に似ていて、事前にハッシュの記憶スロットを確保しておくのに使える:

my %code_map;
keys(%code_map) = 26;
$code_map{+chr} = $_ for 65 .. 90;

蛇足として keys 自体は Perl 5.12 から配列に対しても使えるが、この場合左辺値としては使えない。 配列の事前確保は特殊変数 $#array への代入で行えるが、こちらは伸びた領域が実際に undef で埋まってしまうので元の要素数に戻す一手間が要る:

my @char_map;
$#char_map = 26 - 1;  # Initialized with (undef) x 26
@char_map = ();  # もう一回空にするが、確保されたスロットはそのまま
push @char_map, chr for 65 .. 90;

さてユーザ定義する場合だが、lvalue 属性がついたサブルーチンの最後に評価される式が左辺値であれば良い。メソッドの例を示す:

package Foo;

sub new {
    my ($class) = @_;
    bless +{ foo => '' } => $class;
}

sub foo :lvalue {
    my ($self) = @_;
    $self->{foo};
}

package main;

use 5.024;

my $obj = Foo->new;
$obj->foo = 'bar';
say $obj->foo;  # 'bar'

属性 (attributes) を忘れている人も多いと思うが、要するに Java でいうアノテーションである。Catalyst なんかで見たことがあるだろう。

うっかり値を return してしまうと左辺値にならないことに注意が必要である。(return $x) = 42; はナンセンスだ。

ところでアクセサがオブジェクトの状態を左辺値として返すのはカプセル化の観点からはあまりよろしくない。代入される値を検査できないのでオブジェクトの状態が保障できないからである。 これを避けるには代入操作にフックして検査をすれば良い。C++ なら返す型の代入演算子 (operator=) をオーバーライドするが、Perl ではスカラの代入演算をオーバーライドする。つまり tie するのである:

package Bar;

use strict;
use warnings;

sub new {
    my ($class) = @_;
    bless +{ bar => 0 } => $class;
}

sub bar :lvalue {
    my ($self) = @_;
    tie my $v, 'Bar::NumberField' => $self->{bar};
    $v;
}

package Bar::NumberField;

use strict;
use warnings;
use Carp ();
use Scalar::Util qw/looks_like_number/;

# $_[1] は tie に渡された引数 (e.g., $self->{bar}) のエイリアスなので、
# リファレンスを保存しておくことで後で書き換えられるようにする。
sub TIESCALAR { bless \$_[1] => $_[0] }

sub FETCH { ${$_[0]} }

sub STORE {
    my ($self, $value) = @_;
    unless (looks_like_number $value) {
        Carp::croak("Seems like not a number: $value");
    }
    $$self = $value;
}

package main;

use strict;
use warnings;
use feature qw/say/;

my $bar = Bar->new;
$bar->bar = 42;
say $bar->bar;  # 42
$bar->bar = 'blah blah blah';  # Error.

この例だとやりたいことに比べて労力が馬鹿げているが、ともかく tie された変数を返すことで substr のような組み込み関数と同じ挙動をユーザ定義できるということに意義がある。 実際的には Sentinel のようなライブラリを使うことでシンプルに書ける。なんなら Moose も併用して値の検査を型制約に任せても良い。

コメント

コメントを投稿

このブログの人気の投稿

京大テキストコーパスのパーサを書いた

要旨 CaboCha やなんかの出力形式であるところの京大テキストコーパス形式のパーサモジュールを Perl で書いたので紹介します。 Github Tarball on Github Ppages これを使うと例えば CaboCha の出力した係り受け関係を Perl のオブジェクトグラフとして取得できます。 使用例 単なる文節区切りの例。 #!/usr/bin/env perl use v5.18; use utf8; use IPC::Open3; use Parse::KyotoUniversityTextCorpus; use Parse::KyotoUniversityTextCorpus::MorphemeParser::MeCab; use Symbol qw//; my ($in, $out, $err); my $pid; BEGIN { ($in, $out, $err) = (Symbol::gensym, Symbol::gensym, Symbol::gensym); $pid = open3($in, $out, $err, cabocha => '-f1'); } END { close $out; close $err; waitpid $pid => 0 if defined $pid; } binmode STDOUT, ':encoding(utf8)'; binmode $in, ':encoding(utf8)'; binmode $out, ':encoding(utf8)'; my $parser = Parse::KyotoUniversityTextCorpus->new( morpheme_parser => Parse::KyotoUniversityTextCorpus::MorphemeParser::MeCab->new, ); say $in '星から出るのに、その子は渡り鳥を使ったんだと思う。'; say $in '出る日の朝、自分の星の片付けをした。'; close $in; my $sentence
コメントを投稿
続きを読む

救急外来にかかったときの記録

子どもの頃にかかった記憶はあるが自分で行ったことはなかったのでメモしておく。 先日怪我をした。より具体的に云うとランニング中に転倒し顎を地面に叩きつけた。深夜の12時ごろの話である。 その時点ては両手の擦傷が痛いとか下顎の間接が痛いとか奥歯のセラミックが割れなくて幸いだったといった程度だが、マスクを外して見るとなにやら下部に血がついている。 顎にも擦傷があるのかとうんざりしながら歩いて帰り、血の滲んだマスクを捨てて傷口を洗おうとしたところで皮膚が割けて肉が見えているのに気付いた。 一瞬顔が青くなったが単身なので倒れるわけにはいかない。幸い血は固まっていてそれほど出血していないし、先程まで運動していたからかあまり痛みもない。 この時点で明白な選択肢は3つあった。即ち: 救急車を呼ぶ 自力で病院へ行き救急外来を受診する 応急処置して朝になったら近場の医院を受診する である。まず 3 は精神的に無理だと悟った。血も完全には止まっていないし、痛みだしたら冷静に行動できなくなるだろう。 1 はいつでも可能だったが、意識明瞭で移動にも支障がない状態では憚られた。救急車が受け入れ先病院を探すのにも時間がかかると聞く。 結局とりあえず 1 をバックアップ案とし、2 の自分で連絡して病院へ向かうことにした。まずは病院探しである。このときだいたい 00:30 AM。 最初に連絡したのは最寄りの都立病院の ER だった。ここならタクシーで10分もかからない、のだが、なんと ER が現在休止しているとの回答だった。そんなことがあるのかと驚愕したがどうしようもない。 近場に形成外科の救急外来の開いている病院はないか尋ねたところ 消防庁の相談センター の電話番号を案内された。 ここで4つの病院を紹介された。余談だが相談の対応は人間だが番号の案内は自動音声に切り替わるので録音の用意をした方が良い (一応2回くり返してくれる。) いずれも若干遠くタクシーで2、30分かかるが仕方がない。最初に連絡した最寄りの病院はその日形成外科の当直医師がいなかった。二件目でトリアージの質問をされ、受け入れ可能とのことだったので受診先が決定。このとき 00:45 AM。 診察時に脱ぎ易い服に着替え (このときまでランニングウェアだった)、健康保険証を持って病院へ向かう。ガーゼがないのでマス
コメントを投稿
続きを読む

C の時間操作関数は tm 構造体の BSD 拡張を無視するという話

久しぶりに C++ (as better C) で真面目なプログラムを書いていて引っかかったので備忘録。 「拡張なんだから標準関数の挙動に影響するわけねえだろ」という常識人は読む必要はない。 要旨 time_t の表現は環境依存 サポートしている時刻は UTC とプロセスグローバルなシステム時刻 (local time) のみで、任意のタイムゾーン間の時刻変換を行う標準的な方法はない BSD / GNU libc は tm 構造体にタイムゾーン情報を含むが、tm -> time_t の変換 ( timegm / mktime ) においてその情報は無視される 事前知識 C 標準ライブラリにおいて時刻の操作に関係するものは time.h (C++ では ctime) ヘッダに定義されている。ここで時刻を表現するデータ型は2つある: time_t と tm である。time_t が第一義的な型であり、それを人間が扱い易いように分解した副次的な構造体が tm という関係になっている。なので標準ライブラリには現在時刻を time_t として取得する関数 ( time_t time(time_t *) ) が先ずあり、そこから time_t と tm を相互に変換する関数が定義されている。 ここで time_t の定義は処理系依存である。C / C++ 標準はそれが算術型であることを求めているのみで (C11 からは実数型に厳格化された)、その実体は任意である。POSIX においては UNIX epoch (1970-01-01T00:00:00Z) からのうるう秒を除いた経過秒数であることが保証されており Linux や BSD の子孫も同様だが、この事実に依存するのは移植性のある方法ではない。 一方で tm は構造体であり、最低限必要なデータメンバが規定されている: int tm_year : 1900 年からの年数 int tm_mon : 月 (0-based; 即ち [0, 11]) int tm_mday : 月初からの日数 (1-based) int tm_hour : 時 (Military clock; 即ち [0, 23]) int tm_min : 分 int tm_sec : 秒 (うるう秒を含み得るので [0
コメントを投稿
続きを読む

js_of_ocaml の使い方

js_of_ocaml (jsoo) は Ocsigen が提供しているコンパイラである。その名の通り OCaml バイトコードから JavaScript コードを生成する。 これを使うことで OCaml で書いたプログラムを Web ブラウザや node.js で実行することができる。 インストール 単に OPAM を使えば良い: $ opam install js_of_ocaml js_of_ocaml-ocamlbuild js_of_ocaml-ppx バージョン 3.0 から OPAM パッケージが分割されたので、必要なライブラリやプリプロセッサは個別にインストールする必要がある。 とりあえず使うだけなら js_of_ocaml と js_of_ocaml-ppx の二つで十分。後述するように OCamlBuild でアプリケーションをビルドするなら js_of_ocaml-ocamlbuild も入れると良い。 これで js_of_ocaml コマンドがインストールされ、OCamlFind に js_of_ocaml 及びサブパッケージが登録される。 コンパイルの仕方 以下ソースファイル名は app.ml とし、ワーキングディレクトリにあるものとする。 手動でやる場合 一番安直な方法は、直接 js_of_ocaml コマンドを実行することである: $ # バイトコードにコンパイルする。js_of_ocaml.ppx は JavaScript オブジェクトの作成や操作の構文糖衣を使う場合に必要 $ ocamlfind ocamlc -package js_of_ocaml,js_of_ocaml.ppx -linkpkg -o app.byte app.ml $ # 得られたバイトコードを JavaScript にコンパイルする $ js_of_ocaml -o app.js app.byte OCamlBuild を使う場合 OCamlBuild を使う場合、.js 用のビルドルールを定義したディスパッチャが付属しているので myocamlbuild.ml でこれを使う: let () = Ocamlbuild_plugin . dispatch Ocamlbuild_js_of_ocaml . dispatcher $ # app.ml ->
コメントを投稿
続きを読む

開発環境の構築に asdf が便利なので anyenv から移行した

プロジェクト毎に異なるバージョンの言語処理系やツールを管理するために、pyenv や nodenv など *env の利用はほとんど必須となっている。 これらはほとんど一貫したコマンド体系を提供しており、同じ要領で様々な環境構築ができる非常に便利なソフトウェアだが、それを使うことで別の問題が出てくる: *env 自身の管理である。 無数の *env をインストールし、シェルを設定し、場合によりプラグインを導入し、アップデートに追従するのは非常に面倒な作業だ。 幸いなことにこれをワンストップで解決してくれるソリューションとして anyenv がある。これは各種 *env のパッケージマネージャというべきもので、一度 anyenv をインストールすれば複数の *env を簡単にインストールして利用できる。さらに anyenv-update プラグインを導入すればアップデートまでコマンド一発で完了する。素晴らしい。 そういうわけでもう長いこと anyenv を使ってきた。それで十分だった。 ——のだが、 ここにもう一つ、対抗馬となるツールがある。 asdf である。anyenv に対する asdf の優位性は大きく2つある: 一貫性と多様性だ。 一貫性 “Manage multiple runtime versions with a single CLI tool” という触れ込み通り、asdf は様々な言語やツールの管理について一貫したインタフェースを提供している。対して anyenv は *env をインストールするのみで、各 *env はそれぞれ個別のインタフェースを持っている。 基本的なコマンド体系は元祖である rbenv から大きく外れないにしても、例えば jenv のように単体で処理系を導入する機能を持たないものもある。それらの差異はユーザが把握し対応する必要がある。 多様性 asdf はプラグインシステムを持っている。というより asdf 本体はインタフェースを規定するだけで、環境構築の実務はすべてプラグイン任せである。 そのプラグインの数は本稿を書いている時点でおよそ 300 を数える。これは言語処理系ばかりでなく jq などのユーティリティや MySQL のようなミドルウェアも含むが、いずれにしても膨大なツールが asdf を使えば
コメントを投稿
続きを読む