The Haskell 98 Report
top | back | next | contents | function index

9  構文リファレンス

9.1  表記規約

以下の表記規約は、構文を表現するのに用いる。

全体を通して BNF風の構文を使う。生成ルールは以下の形式である。

(上付文字で書かれた)優先順位のインデックスがついた非終端記号のグルー プがいくつかある。同様に非終端記号 op、varop および conop には二つのインデックスがつくことがある。文字 l, r または n はそれぞれ、左結合性優先度、 右結合性優先度、非結合性優先度をあらわしています。優先度変数 i の範囲は、0 から 9 で、結合性変数 a のとりうる範囲は {l, r, n} である。したがって、たとえば、

は 30 種類の生成結果、つまり、i について 10 通り、a に ついて 3 通りである。

字句構文および文脈自由構文の両方において、いくつかの曖昧性が存在し、 これらは、文法句を左から右へできるだけ伸ばすことで解決する(シフト還元 構文解析では、シフト/還元の衝突はシフトすることで解決する)。字句構文 において、これは「大喰らい」法である。文脈自由構文では、これは、条件 文、let-式、λ抽象は、可能な限り右へ拡張されるということを意味する。

9.2  字句構文

9.3  レイアウト

2.7 節ではレイアウト規則に ついて非形式的に議論した。この節では、それをもう少し正確に定義する。

Haskell のプログラムの意味はそのレイアウトに依存することがあ る。意味に影響を与えるレイアウトは、そのレイアウトによって決定される 場所にブレースとセミコロンを付け加えることによって、完全に記述するこ とができる。こうして補足されたプログラムは今度は、レイアウトには影響 されない。

レイアウトの影響は、この節では、レイアウトを用いているプログラムに、 どのようにして、ブレースとセミコロンを追加するかを記述することによっ て指定する。この仕様は、変換を行う関数 L の形をとる。L への入力は

• この Haskell レポートの字句構文で指定されたような字句の並びで、以下 のような追加トークンがついているもの。

  • キーワード let、where、do あるいは of のあとに字句 { が続かない場合、トークン {n} をキーワードの後に挿入する。ここで n は、もし 次の字句があればそれのインデント、または、ファイルの終端に到達して いれば 0 である。
  • モジュールの最初の字句が { あるいは module では ないとき、その字句の前に {n} を置く。ここで、n はそ の字句のインデントである。
  • 同一行で、字句の開始の前には白空白しかないとき、この字句の前に <n> を置く。ここで n はこの字句のインデントで、 前の二つの規則の結果、その前には {n} が置かれていない。 (注意: 文字列リテラルは複数行にまたがることがある -- 2.6 節。したがって、
    
      f = ("Hello \
              \Bill", "Jake")
    
    では、\Bill の前に <n> は挿入されることはな い。なぜなら、完全な字句の開始場所ではないからだ。また、, の前にも <n> は置かれることはない。なぜなら、その前に 白空白以外のものがあるからだ。)

• 「レイアウト文脈」のスタックのそれぞれの要素は以下のどれかである。

  • ゼロ、これは文脈を明示的に囲うこと(たとえばプログラマが開ブレース を用意した場合)を示す。もし最も内側の文脈が 0 なら、囲まれた文脈が 終了するか、新しい文脈がプッシュされるまで、レイアウトトークンは挿 入されない。
  • 正の整数、これは囲まれたレイアウト文脈のインデントカラム数

字句の「インデント」は字句の最初の文字のカラム数である。ひとつの行の インデントとは最も左にある字句のインデントを表す。このカラム数を決定 するために以下のような規約をもつ固定幅のフォントを仮定する。

• 改行、リターン、ラインフィードおよび フォームフィード文字はすべて新しい行を開始する
• 最初のコラムは 0 ではなく 1 である
• タブストップは8文字文ずつの位置にある
• タブ文字は現在位置から次のタブストップ位置までそろえるのに必要な だけの空白を挿入する。

レイアウトルールにあわせるために、ソースプログラム中の Unicode 文字は ASCII 文字と同じ幅の固定幅であると看倣す。しかしながら、見た目との混 乱を避けるためプログラマは暗黙のレイアウトの意味が非空白文字の幅に依 存するようなプログラムを書かないようにすべきである。

適用

L tokens []

は、tokens のレイアウトに関知しない変換をもたらす。ここで、 tokens はモジュールの字句解析および上述のようにカラム数表示子 を追加した結果である。L の定義は以下のとおり、ここでは 「:」をストリーム構築操作子として使い、「[]」は空のスト リームである。

Note 1.

入れ子になった文脈は、囲まれた文脈 (n>m) よりも深くインデ ントされて いなければならない。さもなければ、L は失敗し、また、 コンパイラはレイ アウトエラーを表示しなければならない。たとえば、

  f x = let
           h y = let
    p z = z
                 in p
        in h

ここで、p の定義は囲まれた文脈のインデントよりも浅いインデン トである。この場合、h の定義によって設定される。

Note 2.

where の後の最初のトークンが、たとえば、囲まれた文脈よりもイ ンデントされているのでなければ、そのブロックは空でなければならない。 だから、空のブレースが挿入される。トークン {n} は <n> に置き換 えられ、空のブレースが明示的になっていた場合の状況を模倣する。

Note 3.

現在のレイアウト文脈について 0 に対して照合することで、明示的な閉ブ レースが明示的な開ブレースにのみ対応することを確かめる。もし、明示的 な閉ブレースが暗黙の開ブレースに対応している場合には構文解析エラーと なる。

Note 4.

これは、すべてのブレースの対は明示的なレイアウト文脈として扱われる こ とを意味し、ラベル付のデータ構築および更新 (3.15 節)を含む。ここにこの形式化と Haskell 1.4 での 違いがある。

Note 5.

副次的な条件 parse-error(t) は次のように解釈される。もし、次の トークンが t であるような L によっ て生成されたトークン が Haskell の文法の不正な接頭辞を表わしている場合、および、 「}」トークンが続く L によって生成さたトー クンの Haskell 文法の正しい接頭辞である場合、parse-error(t) は真とな る。

m /= 0 のチェックは、暗黙に追加された閉ブレースが、暗黙の開ブレースに 対応することをたしかめる。

Note 6.

入力の終端において、保留された閉ブレースがすべて挿入される。この時点 でレイアウト文脈のなかにある(すなわち、m = 0 である)とエラーとなる。

上のような照合になんの規則もなければ、アルゴリズムは失敗する。入力の 終端に達すると直ちに失敗し、非レイアウト文脈がアクティブになる。それ は閉ブレースが欠けているからである。おこり得るにもかかわらず、このア ルゴリズムでは検出できないエラー状態がある。たとえば、 let } である。

Note 1 は、レイアウト処理はパーズエラーにより相互に停止するという性質 を実現したものである。たとえば、

        let x = e; y = x in e'

は正しい構文である。なぜなら、

        let { x = e; y = x } in e'

に変換されるからである。閉ブレースは上のパーズエラールールにより挿入 される。このパーズエラールールは、これがもつ一般性を実装するのは困難 である。それは、演算子位置の問題を含んでいるからである。たとえば、次 の式

  do a == b == c

は、(型としては正しくないかもしれないが)一つの明白な構文解析結果 をもつ。すなわち、

  (do { a == b }) == c

である。なぜなら、(==) には結合性がないからである。ゆえに、 プログラマは、パーザがこのような場合に閉ブレースを挿入しなければなら ないようなコードを書かないようにするべきなのである。

9.4  文芸的コメント

「文芸的コメント」の規約は、最初 Richard Bird と Philip Wadler が、 Donald Knuth の「文芸的プログラミング」に触発されて、Orwell 用に開発 したのであるが、Haskell のソースコードを書くときのもうひとつのスタイ ルでもある。文芸的スタイルは、デフォルトでコメントである。行頭が、「>」 である行がプログラムの一部としてあつかわれる。それ以外のすべての行は コメントである。

プログラム本文は「>」で始まる行のみから再構成され、各行の先頭の 「>」は空白に置き換えられる。レイアウトとコメントはその結果のテキ ストに対して 9 章で解説されたよ うに厳密に適用される。

あやまって、「>」を忘れたことを捕捉するために、プログラムラインが空 ではないコメント行に隣接した場合、エラーになる。このとき、空白だけか ら構成される行は空白行と解釈される。

規約として、コメントのスタイルはそのファイルの拡張子によって表示され る。拡張子が「.hs」であるときこれは通常の Haskell のファイルであるこ とを示している。「.lhs」は文芸的 Haskell のファイルであることを示して いる。このスタイルを使うと、単純な階乗のプログラムは次のようになる。

   This literate program prompts the user for a number
   and prints the factorial of that number:

> main :: IO ()

> main = do putStr "Enter a number: "
>           l <- readLine
>           putStr "n!= "
>           print (fact (read l))
          
  This is the factorial function.

> fact :: Integer -> Integer
> fact 0 = 1
> fact n = n * fact (n-1)

文芸的プログラミングには特に LaTeX のテキスト処理に適したもうひとつの スタイルがある。この規約では、 \begin{code}...\end{code} 区切り子で囲まれている文 芸的プログラムの部分だけが、プログラムテキストとして扱われる。それ以 外の行はすべてコメントである。より正確には、

• プログラムのコードは \begin{code} ではじまる行の次の行 から始まる。
• プログラムのコードは、\end{code}ではじまる行(もちろん、 文字列リテラルは無視する)の直前で終る。

スタイルとしてそうすることが望ましいが、この区切り子の前後には余分な 空白行を挿入する必要はない。例をあげると、

\documentstyle{article}

\begin{document}

\section{Introduction}

This is a trivial program that prints the first 20 factorials.

\begin{code}
main :: IO ()
main =  print [ (n, product [1..n]) | n <- [1..20]]
\end{code}

\end{document}

9.5  文脈自由構文

The Haskell 98 Report
top | back | next | contents | function index
December 2002