【第11回】RPG Ⅳの歴史(part.6) 未来に目を向ける

RPG Ⅳの歴史を通してのこの旅の6番目にして最後のエピソードを携え、ここに再びジョンが戻ってきました。私はこれらの話を書くのを楽しんだと言わなければなりません。これらの話は、好きな記憶ともちろんいくつかのあまり好きでない記憶を思い出させました。

第5話の最後に述べた話題に入る前に、まだ公式には発表されていないRPG Ⅳに対する１つのアップデート候補について簡単に述べようと思います。

まだIBMが発表していないとしたら、どうやってそれについて知るのでしょうか? IBMは最近RDi (Rational Developer for i)のバージョン9.5を出荷し始めました。そして、その中で2～3日前に次のRPG Ⅳの発表に関してうっかり秘密を洩らしました。RDi 9.5には、1桁目から始まり何処までも続く、もはやカラム制限のないフリーフォーム・コーディングを許すRPG用の機能が含まれています。このニュースはRDiコミュニティの多くの人から暖かく祝福されたと言うのは控えめな表現でしょう。公式発表は今朝行われました。

この機能拡張により、V7のフリーフォーム・ファイルおよびデータ宣言サポートと結び付けることで、RPGは完全にフリーフォーム言語であると本当に主張できます。確かに、I仕様書やO仕様書はフリーフォームでコーディングできませんし、多分決してそうならないでしょう。しかし、ともかくそれらを使用する新しいプログラムを書く理由は何もありません。

私はもうIBMで働いていないので、RPGの将来計画について特別な洞察は何もありません。しかしそのことは、私たちがRPGに追加されるかもしれない幾つかの可能性を自明なこととして仮定するのを妨げません。決して追加されることはないと私がかなり確信しているのは、オブジェクト指向（以下OOと略記します）です。これに対するいくつかの要望は長い間寄せられてきていますが、互換性を維持しながら良い仕事をするのは本当に難しく、潜在的ユーザーの数も少ないのではないかと考えています。Java、C++、PHPそして今やPythonやnode.jsのような優れたOOベースの言語がIBM i上で利用可能であり、RPGにOO機能を組み込もうとしてもあまり意味がありません。

「盗む」価値がある幾つかのOO的機能が無いわけではありません。たとえば、同じ名前をもちながらパラメータが異なる複数のルーチンを定義し、コンパイラーがそのシグニチャ（つまり、パラメータの数、型そして順番）に基づいてどのルーチンを呼び出すかを解決できたら素晴らしいでしょう。

同様の効果に使用できるかもしれないもう1つの役に立つオプションは、RPGが型の無いパラメータを実装することです。言い換えるならば、パラメータとして何でも渡せるという機能です。呼び出されたルーチンは、渡された実際のパラメータの型に応じて振る舞いを決定します。このアプローチの最大の問題は、OSが完全なパラメータ記述子をサポートしていないことです。特定のデータ型だけがカバーされています。その結果、このオプションの有効性はそれらのデータ型に制限されるか、またはRPG独自の記述子の仕組みを発明しなければなりません。

これらの機能のどちらも、何回も要求され続けてきました。それらのどちらかがIBMのToDoリストの1番に登るかどうか、私たちは成り行きを見守らなければなりません。

恐らく実装される可能性が最も高い機能のタイプは、共通のビジネス機能を簡単にするものでしょう。たとえば、フィールドの値がある範囲にあるかどうかのテストを簡単にする仕組みです。あるいは、もしかするとフィールドの値が指定されたリストの中にあるかどうかを判断する、SQLのIN（値のリスト）に似た機能かも知れません。

これらは組み込み関数（BIF）として実装されるか、あるいは有効な値／範囲がデータ宣言の一部として設定されるCOBOLと同様のやり方で（読者の皆さんの中のバイリンガルの人たちのために88レベルについて話しています）実装される可能性があります。もちろん、サブプロシージャのお陰でそのような機能を自分自身で実装することが既にできます。しかし、そのような機能を言語内に有していることは、我々の同胞内のILE恐怖症の人々にも恩恵をもたらします。

その他の可能性のある候補は、既存のサポートに「ギャップ」がある機能です。たとえば、DS配列がサポートされるようになってから少々時が経ちますが、それに対して基本的な%Lookup操作しか実行できません。GTやLEなどの変種の命令を使用することはできません。おそらく、個々のキーに昇順／降順を指定できないのがその理由だと思われます。個人的には、%Lookupや%Scanのような関数が、代入処理で使われた場合に結果として配列を返す機能を提供してほしいと思います。

配列について話をしていますが、PHPを使うことでRPGにもっと強力な配列サポートが欲しくなりました。まずは可変長配列が良いと思います。RPGの伝統的な機能に起因するいくつかの実装上の課題があることは分かっていますが、それでもそれは可能であり機能拡張する価値があると考えています。もちろん、これと共に単純なループ計算用に、あるFOR-EACH形式をサポートするためにFOR操作の拡張を行うべきです。ループ・カウンターをなくして単に「これを、このすべてについて実行せよ」と命令できたら、プログラム・ロジックがどれ程簡潔になることでしょう。もしIBMがSQLによって動的配列に値を設定できるようにもするつもりなら、あなたは結果セットを探索する洗練された単純な方法をも手にすることになります。

まだ延々と書き続けることもできますが、望むらくはブログのコメント欄に読者の皆さんからいくつかの提案がなされることを期待します。

まとめ

私がこの一連の物語を楽しく書いたと同じくらい皆さんが楽しくこれを読んでくださったことを願っています。過去25年ほどの時を振り返るのは魅惑的なことでした。そして、皆さんが毎日使っている製品に結実しているIBMでの数多くの決定に投入されている仕事量を、皆さんが少しはよく理解できるようにできたと願っています。

私はRPG Ⅳを「誕生させた」チームの一員であったことをとても誇りに思っています。私たちが愛している言語を機能拡張し続けているIBMに居る献身的なチームの多くの人たちを、今でも「友人」と呼べることに私はそれ以上の誇りを感じています。とりわけ、RPG Ⅳの女王であり、RPGに対する数多くの最近の機能強化の背後に居る人物である素敵なバーバラ・モリスを選ばなければなりません。

私たちは間違いを犯したでしょうか? 確かに間違えましたが、同時に多くのことを正しもしました。今日市場にある驚くべきRPGベースのツールやアプリケーションのいくつかを目にすると、21年前にRPGプログラマーには想像も付かなかった機能への扉を開いたコンパイラーを作るための戦いで、私たちは本当に正しいことをしたのだと確信します。また、RPG Ⅳは次の21年間も現役でいることも確信しています。もっとも、そのお祝いのときには私は健在ではないかも知れませんが。

追伸：

第5話の終わりに、私はあまりに使われなさ過ぎているOpen Access機能について話をするつもりだと述べました。私は将来この話題に立ち戻るかもしれませんが、実際やっとのことで時間を見つけてこの記事を書いていた時点では、それは「適している」様には見えませんでした。この話題を息を殺して待っていた人たちにはお詫びいたします。