応用情報技術者 2010年 秋期 午後 問02

解答の論理構成

• (1) 反復 {　} が示すもの
  プログラム中には宣言が複数並びます。宣言列を表す非終端記号は一つだけなので、 “複数回出現して良い要素＝宣言そのもの” と判断できます。したがって { … } 内に来る ア は 〈宣言部記述〉 です。
• (2) 宣言行の中央に現れる字句の種類
  例として問題文に示された “short aa ;” を見ると、'short'（宣言記述子）の直後に aa が入り、最後は ';' で閉じられます。この aa は “英字で始まる1文字以上の英字又は数字からなる文字列” であり、'short' と 'long' は＜識別子＞には含まれない” と明記されています。従って イ は 〈識別子〉 となります。
• (3) 〈項〉の先頭に置かれる要素
  加減算より優先順位の高い乗除算を表す 〈項〉 は、乗除演算子で区切られた 〈因子〉 の列です。従って “最初に必ず解析する要素” である ウ は 〈因子〉 になります。

誤りやすいポイント

• { … } と [ … ] を混同し、ア に “〈宣言部〉” など再帰的に違う記号を入れてしまう。
• 例外扱いの 'short'・'long' を＜識別子＞に含めてしまい、イ を “〈数〉” との併記で迷う。
• 〈項〉と〈因子〉の階層を取り違え、“掛け算・割り算をまとめているのは 〈項〉” であることを忘れ、ウ に “〈項〉” を入れるミス。

FAQ

解答の論理構成

誤りやすいポイント

• 〈宣言部記述〉は “型” と 〈識別子〉 1 個 だけ。カンマ区切りや連続記述は許されません。
• 〈式〉や 〈項〉 に 単項演算子（+、-）が存在しない ことを見落とすと、⑤のような記述を正しいと勘違いしがちです。
• “意味エラー（未宣言変数・0除算）” と “構文エラー” を混同しやすいので、設問で何を聞いているかを必ず確認しましょう。

FAQ

解答の論理構成

1. 〈文〉の構文を確認
   【問題文】の構文規則に「〈文〉 ::= 〈識別子〉 ‘=’ 〈式〉 ‘;’」とあります。つまり
   • 先頭に〈識別子〉
   • 次に ‘=’
   • 続いて〈式〉
   • 最後に ‘;’
     の順で現れることが必須です。
2. bun() の処理フローと エ
   図3の bun() は〈文〉を検査する関数です。最初に token が 'I'（〈識別子〉）であることを確認してから gettoken() で次の字句を読み込みます。次に文法どおり ‘=’ が現れるかを調べる必要がありますから、 「if ( token と '=' が等しい ) then」
   が正しい判定条件になります。したがって エ は「token と '=' が等しい」です。
3. 〈式〉の構文と オ
   〈式〉の定義は「〈式〉 ::= 〈項〉 { ‘+’ 〈項〉 | ‘-’ 〈項〉 }」。必ず先頭に〈項〉が来るため、shiki() は開始直後に kou() を呼んで〈項〉の妥当性をチェックしなければなりません。エラー検出ルール（正常なら 0、異常なら -1）より、 「if ( kou() と -1 が等しい ) then return -1 endif」
   が必要条件です。よって オ は「kou() と -1 が等しい」です。
4. 結論
   エ：token と '=' が等しい
   オ：kou() と -1 が等しい

誤りやすいポイント

• ‘=’ と ‘==’ を混同して比較演算子を誤記する
• 〈式〉を shiki() でなく kou() だけで終わらせてしまい、加減算ループに対応できなくなる
• gettoken() を呼ぶ位置を間違え、token が次字句を指していない状態で比較を行う

FAQ

解答の論理構成

1. 問題文は「“d = a * ( 3 + b ) ;”のように、式の演算子の評価順序を明示的に記述するため、『(』及び『)』を使えるように構文規則を拡張したい」と述べています。
2. 追加するトークンは括弧で囲まれた部分であり、その内部に来るのは“＋”や“－”も現れる完全な式です。
3. 図2の既存規則では演算子“＋”“－”を含めた構文を表す非終端記号は＜式＞しか存在しません。
4. したがって、書き換え後の
   　＜因子＞ ::= ＜数＞｜＜識別子＞｜'（'カ')'
   　の カ には＜式＞を入れるのが唯一整合する選択肢です。
5. よって解答は「＜式＞」となります。

誤りやすいポイント

• 括弧内に＜項＞や＜因子＞を入れてしまう誤答が多いですが、これでは“3 + b”の“＋”を含む表現を解析できません。
• 「(」と「)」を終端記号として追加するだけで済むと考え、非終端記号を指定し忘れるケース。
• 全角『（』『）』と半角“(” “)”の表記ゆれを混同し、原文の終端記号を正確に引用しないミス。

FAQ

解答の論理構成

• 図2の構文規則に新しく '(' と ')' を終端記号として追加するため、字句解析段階で両者を区別して取り出せるようにする必要があります。
• 表「字句の種類と関数 gettoken() の戻り値の対応」では
  '＝'、'＋'、'－'、'＊'、'／' 及び '；'
  が「左の各字句に同じ」戻り値を返すと示されています。既存の記号トークンは “その文字自身” を戻しています。
• 同じ方針を踏襲すると、'(' と ')' についても 個別の戻り値 を定義すれば構文解析側は簡単に識別できます。
• よって解答は「『（』と『）』に対してはほかの字句とはそれぞれ別の戻り値を戻す。」となります。

誤りやすいポイント

• 既存記号と同じ戻り値を使って良いと勘違いし、両括弧を同一トークンにまとめてしまう。
• 'S'、'L'、'N'、'I'、'?'、'$' など予約済みコードと衝突する戻り値を割り当てる。
• 構文規則を変更しただけで満足し、gettoken() の修正を失念する。
• 括弧を「＜識別子＞」や「＜数＞」と同様に空白で区切られる字句だと思い込み、字句境界の判定を誤る。

FAQ