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

仕事で使わない 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)

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

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::mapoperator[] なんかが典型である。

組み込み関数で左辺値を返す典型は 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 も併用して値の検査を型制約に任せても良い。

コメント

このブログの人気の投稿

BuckleScript が ReScript に改称し独自言語を導入した

Via: BuckleScript Good and Bad News - Psellos OCaml / ReasonML 文法と標準ライブラリを採用した JavaScript トランスパイラである BuckleScript が ReScript に改称した。 公式サイトによると改称の理由は、 Unifying the tools in one coherent platform and core team allows us to build features that wouldn’t be possible in the original BuckleScript + Reason setup. (単一のプラットフォームとコアチームにツールを統合することで従来の BuckleScript + Reason 体制では不可能であった機能開発が可能になる) とのこと。要は Facebook が主導する外部プロジェクトである ReasonML に依存せずに開発を進めていくためにフォークするという話で、Chromium のレンダリングエンジンが Apple の WebKit から Google 主導の Blink に切り替わったのと似た動機である (プログラミング言語の分野でも Object Pascal が Pascal を逸脱して Delphi Language になったとか PLT Scheme (の第一言語) が RnRS とは別路線に舵を切って Racket になったとか、割とよくある話である。) 公式ブログの Q&A によると OCaml / ReasonML 文法のサポートは継続され、既存の BuckleScript プロジェクトは問題なくビルドできるとのこと。ただし現時点で公式ドキュメントは ReScript 文法のみに言及しているなど、サポート水準のティアを分けて ReScript 文法を優遇することで移行を推進していく方針である。 上流である OCaml の更新は取り込み、AST の互換性も維持される。将来 ReScript から言語機能が削除されることは有り得るが、OCaml / ReasonML からは今日の BuckleScript が提供する機能すべてにアクセスできる。 現時点における ReScript の

多分週刊チラシの裏 (Oct 12 - 18, 2020)

プログラミング言語のエネルギィ効率性 おなじみ Computer Language Benchmark Game にある言語のうちプロプライエタリな Smalltalk を除く 27 言語の、時間効率性と空間効率性に加えて「エネルギィ効率性」を検証したという研究。 結果は大方の予想を外れない (コンパイラ言語 - VM 言語 - インタプリタ言語の序列) のだが、言語毎によって単位時間あたりのエネルギィ効率 (換言すると CPU 最適化性能) が異なるので「速ければより省エネ」とは必ずしも言えないことや、最大メモリ消費量は言語のパラダイムによって大方が決まり、エネルギィ効率とはほとんど相関がない (ので Java でもエネルギィ効率は高い) ことなど面白い事実が見られる。 『アメリカのインターネット』の終焉 1994 年に Netscape が設立されたとき、世界にはおよそ一億台の PC があり、その半数は合衆国にあった。 WWW はスイスで開発されたしコンピュータは英国の発明だが、インターネットは米国製だった。 米国の企業がその課題を与え、重要な製品とサービスを作り、規制や言論は米国の立場、文化、法が支配した。 (引用者訳) 合衆国政府による TikTok 分割騒動に寄せての現在と未来のインターネットの話。 今日のインターネットの利用者のうち 80 - 90% は米国外の住人である。中国のスマートフォン台数は米国と欧州を合わせたよりも多く、ソフトウェア・スタートアップの半数はシリコンバレーの外で起きている。 テクノロジーは規制産業になったが、その規則はもはや合衆国の一存では決まらないのである。 まつもとゆきひろのツイッターを見てRuby使うのをやめようと思った Ruby の原開発者にして「寛大なる就寝独裁官 (BFDL)」の Twitter における言動が差別主義とは言えないまでもマイクロアグレッションに満ちていたので製品としての Ruby にも悪印象がついたという話。 不要に攻撃的な人やコミュニティから距離を置く理性は心身の健康のためにも重要である。 FTP のフェードアウト Chrome をはじめとする Web ブラウザにおいてファイル転送プロトコル (FTP) のサポート終了が迫っていることに寄せて、半世紀に渡ってインターネットの

OCaml で Web フロントエンドを書く

要旨 フロントエンド開発に Elm は堅くて速くてとても良いと思う。昨今の Flux 系アーキテクチャは代数的データ型と相性が良い。ところで工数を減らすためにはバックエンドも同じ言語で書いてあわよくば isomorphic にしてしまいたいところだが、Elm はバックエンドを書くには現状適していない。 OCaml なら js_of_ocaml でエコシステムを丸ごとブラウザに持って来れるのでフロントエンドもバックエンドも無理なく書けるはずである。まず The Elm Architecture を OCaml で実践できるようにするため Caelm というライブラリを書いている。俺の野望はまだまだこれからだ (未完) Elm と TEA について Elm というプログラミング言語がある。いわゆる AltJS の一つである。 ミニマリスティクな ML 系の関数言語で、型推論を持ち、型クラスを持たず、例外機構を持たず、変数の再代入を許さず、正格評価され、代数的データ型を持つ。 言語も小綺麗で良いのだが、何より付属のコアライブラリが体現する The Elm Architecture (TEA) が重要である。 TEA は端的に言えば Flux フロントエンド・アーキテクチャの変種である。同じく Flux の派生である Redux の README に TEA の影響を受けたと書いてあるので知っている人もいるだろう。 ビューなどから非同期に送信される Message (Redux だと Action) を受けて状態 (Model; Redux だと State) を更新すると、それに対応して Virtual DOM が再構築されビューがよしなに再描画され人生を書き換える者もいた——という一方向の流れはいずれにせよ同じである。 差異はオブジェクトではなく関数で構成されていることと、アプリケーション外部との入出力は非同期メッセージである Cmd / Sub を返す規約になっていることくらいだろうか。 後者は面白い特徴で、副作用のある処理はアプリケーションの外で起きて結果だけが Message として非同期に飛んでくるので、内部は純粋に保たれる。つまり Elm アプリケーションが相手にしないといけない入力は今現在のアプリケーションの完全な状態である Model と、時系列イベ