2006年02月02日
川俣晶の縁側ソフトウェア技術雑記total 4732 count

理論・仕様・実装……、プログラム言語を構成する者達の分類についての1感想

Written By: 川俣 晶連絡先

 検索エンジンでここに直接飛んできた人は何書いてるか良く分からないと思いますが、逆にリンクをたどっていけばコンテキスト(文脈)が見えてきます。こういうコンテキスト(文脈)が見えにくいことが現在のインターネットのアーキテクチャの一種の欠陥だと思いますが、あまり問題意識として共有されていないような気がします……、というのは余談として。

 檜山正幸さんの以下について。

■[言及御礼][雑記/備忘]前提、説明、納得の関係とか

より

と、実装に言及しない方向で説明を試みてますが、僕自身「実装を出さないほうがいい」とは思ってません。というか、「実装を引き合いに出すのがいいのか/出さないのがいいのか」さえ確信が持てないで、「なんだろうなぁ」とか他力本願な疑問文を書いているのですよね。

 とりあえず、「実装」という用語を未定義のまま使いますが、汎用プログラム言語については以下のように考えます。

  • プログラム言語の特定の機能について、実装を引き合いに出すことなく説明可能であることが望ましい
  • 説明する側と聞く側が、実装を引き合いに出した方が分かりやすい場合は引き合いに出しても良いが、その場合でも引き合いに出さずとも説明可能であることが望ましい
  • 例外的に、特定の実装を効率よく実現するために用意された機能は、実装を引き合いに出した説明を行った方が良い

 ちなみに、最後の項目は、Cで*dst++ = *src++;のような構文がなぜ許されるのかという理由を説明する場合に、「それはCPUに備わっているアドレッシングモードのポストインクリメントを活用するためだよ」と言ってしまうようなケースを示します。

プログラム言語の構造 §

 プログラム言語というのは、以下のような構造を持ちます。

理論→仕様→実装 (モデルA)

 理論はそれ単体では実行もできず、記述もできないものとします。

 仕様は、理論を表現するための構文を規定します。しかし、その構文に沿ってプログラムを記述しても、それだけでは実行できません。

 実装は、記述されたプログラムを実行するために必要とされます。

 以上のようなモデルはこの文脈では不十分であると考えます。

 実は、仕様において規定しているのは「構文」だけではないからです。そこには、仮想的に設定される「処理モデル」の定義が含まれます。

理論→処理モデル→構文→実装 (モデルB)

 たいていの言語では、処理モデルと構文は一体不可分の存在なので、この2つが明確に分離されていないケースも多いと思います。

 しかし、プログラム言語ではないものの、XMLを用いた言語でXML構文と非XML構文の双方を提供するケースがいくつか出てきているので、それとの関連で考えれば理解可能ではないかと思います。

 (読者サービス: ちなみに、XMLとDOMの場合、処理モデルがXMLのデータモデルで、構文がXML文書の構文です。そして、DOMは文字ではなくオブジェクトによって表現された別の構文です)

 さて、ここで問題となるのは、ある構文の動作について説明する場合です。

 モデルAの場合、ある「構文」の動作を説明するために「仕様」のレイヤーを使わないとすれば、「実装」というレイヤーで説明を行わねばなりません。

 しかし、モデルBの場合、ある「構文」の動作を説明するために「処理モデル」というレイヤーを使うことが可能となります。

 そして、プログラム言語の「仕様」とは「実装」を作成したり利用するための拠り所になるものである以上は、「仕様」の一部である「構文」と「動作」を説明するために「実装」を引き合いに出すのは本末転倒だろうと思います。

 というのが私の考えの理由です。

メモリという処理モデル §

「左辺値と右辺値という概念抜きで説明したいということでしょうか?」に関して言えば、左辺値/右辺値なる概念を、アドレスと、そのアドレスが指す場所に格納された内容という、かなりベタなローレベル・モデルなしで果たして説明できるのか、が僕の疑問だし、とりあえず今の僕は「ベタなローレベル・モデルのほうが説明の効率がいい」と考えています。

 仮にCと仮定すると、ここに出てくるアドレスというのは、実は「実装」レイヤーの概念ではなく、「処理モデル」のレイヤーの概念だと思います。Cで使われるアドレスが、物理的実体としてのCPUが扱うアドレスと一致していなければならない必然性は何もないわけで。

 つまり、ベタなローレベル・モデルは実装とは別のレイヤーに存在するのがCだと思います。

ポリシー? §

でも、人それぞれに、この漠然とした問題に対し、ポリシーとか経験とか手法だとかは持っているんじゃないでしょうかね、僕はちゃんとは持ってないけど。

 この手の問題に対する私のスタンスは、自らが言語をデザインし、仕様を作成するという立場からの方法論です。(しょせん、自己流ではありますが)

 だから、言語仕様書を作成する立場と、それを実装する立場は違うという意味で、実装とそれ以外の境界には非常に鋭敏になっているのかもしれません。

 単なる説明であれば、どのように説明しても通じればOKと言うことかもしれません。

Facebook

キーワード【 川俣晶の縁側ソフトウェア技術雑記
【技術雑記】の次のコンテンツ
2006年
02月
03日
悩ましくも曖昧な「参照」・これは実装に依存しない説明の敵であるか?
3days 0 count
total 3814 count
【技術雑記】の前のコンテンツ
2006年
02月
01日
str1, str2が文字列だとして、if (str1 == str2)と書いてはいけない理由!?
3days 0 count
total 6050 count

このコンテンツを書いた川俣 晶へメッセージを送る

[メッセージ送信フォームを利用する]

メッセージ送信フォームを利用することで、川俣 晶に対してメッセージを送ることができます。

この機能は、100%確実に川俣 晶へメッセージを伝達するものではなく、また、確実に川俣 晶よりの返事を得られるものではないことにご注意ください。

このコンテンツへトラックバックするためのURL

https://mag.autumn.org/tb.aspx/20060202133506
サイトの表紙【技術雑記】の表紙【技術雑記】のコンテンツ全リスト 【技術雑記】の入手全リスト 【技術雑記】のRSS1.0形式の情報このサイトの全キーワードリスト 印刷用ページ

管理者: 川俣 晶連絡先

Powered by MagSite2 Version 0.36 (Alpha-Test) Copyright (c) 2004-2021 Pie Dey.Co.,Ltd.