Haskell Questチュートリアル-ホール

ほとんどの場合、これは時間通りに発行される最後の部分です。 私の休暇はもうすぐ終わり、今では週に記事を書くのは非常に難しいでしょう。 Haskell Quest Tutorialに興味を持っていたすべての人に感謝します！

居間

あなたはリビングルームにいます。 東には出入り口、西には奇妙なゴシック様式の文字が描かれた木製のドア、閉ざされているように見える、トロフィーケース、部屋の中央に大きな東洋の敷物があります。

トロフィーケースの上には、古き良き時代のエルフの剣がかかっています。

トロフィーケースには、バッテリー駆動の真鍮製ランタンがあります。

内容：

あいさつ

パート1-先

パート2-フォレスト

パート3-ポリアナ

パート4-キャニオンのビュー

パート5-ホール



パート5

ここでは、小さなエラーから重要な結果を導き出し、ゲームにオブジェクトを追加します。





まず、記憶をリフレッシュしましょう。 4番目のパートで取得したrun関数について見ていきましょう。 ご覧のとおり、私はあなたのために働いて、Lookアクションを追加しました。 実行機能が印象的になりました。

curLoc = doを実行します

putStrLn （ describe curLocを記述）

putStr 「コマンドを入力：」

x < -getLine

のケース （ convertStringToAction x ）

終了-> putStrLn 「 会い ましょう...」

見て-> やる

putStrLn （ describe curLocを記述）

curLocを実行します

Go dir- > do

putStrLn （ " \ n You walking to" ++ show dir ++ "。 \ n " ）

実行（ walk curLoc dir ）

convertResult- > do

putStrLn （ evalAction convertResult ）

putStrLn 「ターン終了。 \ n "

curLocを実行します

最後の2番目のタスクでは、「（describeLocation curLoc）」への2つの呼び出しを回避する方法について考える提案がありました。 もちろん、1つの小さな関数の例を使用してリソースを奪い合うためにN体の重力問題を解決するわけではありませんが、この重要性からいくつかの重要な結果が生じます。 命令型言語がある場合、結果を変数に割り当てるだけです。 Haskellでは、データは不変であると見なされるため、そのような割り当てはありません。 しかし、判明したように、割り当てを一般化するだけでなく、変更されていない状態を考慮して、興味深い効果をもたらす他のメカニズムがあります。 たとえば、実行の決定論。 実際、グローバルな状態が関数に影響せず、その内部でデータが明らかに変更されていない場合、同じ引数に同じ値を返すことを意味します。 関数を1回呼び出すことで、パラメーターと結果を記憶できます。同じパラメーターで2回呼び出す必要がある場合は、前に計算した結果を単純に返します。



しかし、ビジネスに取りかかりましょう。 私たちの問題にはいくつかの解決策があります。 まず、getLineからの行と変数xを接続したのと同じ方法で、結果を変数に関連付けてみます。 これは割り当てに似ており、ここでの考え方は簡単です。必要なだけ変数を使用できます。 最初の呼び出しから、おおよそ次のコードを取得します。

curLoc = doを実行します

locDescr < -describeLocation curLoc

putStrLn locDescr

putStr 「コマンドを入力：」

x < -getLine

のケース （ convertStringToAction x ）

...- 残りのコード

しかし、このコードはコンパイルされないため、トリックです。

*メイン> ：r

[ 2 of 2 ] Mainのコンパイル（ H：\ Haskell \ QuestTutorial \ Quest \ QuestMain。Hs 、解釈済み）



H：\ Haskell \ QuestTutorial \ Quest \ QuestMain hs： 58 ： 17 ：

予期されたタイプ ' [ a0 ] 'を実際のタイプ ' IO （ ） 'と一致させることができませんでした

' putStrLn 'の呼び出しの戻り 型

「 do 」式の文 ： putStrLn locDescr

式では：

...



失敗しました。モジュールがロードされました：Types 。

「x <-getLine」と「locDescr <-describeLocation curLoc」の違いは何ですか？ 同じことのようです：getLine関数は、変数xに関連付けられた文字列を返します。 また、関数（describeLocation curLoc）は、別のlocDescr変数にバインドする文字列も返します。 しかし、インタープリターはいくつかのタイプが一致しないと言います。 状況を見てみましょう。そして、このためには、run関数で実際に何が起こるかを理解する必要があります。



エラーのある行をコメントアウトして、作業コードに戻りましょう。

curLoc = doを実行します

-locDescr <-describeLocation curLoc

-putStrLn locDescr

putStr 「コマンドを入力：」

x < -getLine

のケース （ convertStringToAction x ）

...- 残りのコード



*タイプ> ：r

[ 2 of 2 ] Mainのコンパイル（ H：\ Haskell \ QuestTutorial \ Quest \ QuestMain。Hs 、解釈済み）

OK 、ロードされたモジュール：Main 、 Types 。

*メイン>

そのタイプの複雑さに入らないように、意図的にrun関数の定義を作成しませんでした。 しかし、彼女には型があり、コンパイラーは自分でそれを忠実に表示します。 チェック：

*メイン> ：実行

実行::ロケーション-> IO （ ）

そして、ここで驚きが待っています。 Locationは単一のパラメーターの型であり、奇妙な型IO（）の場合、戻り値の型以外は何もありません。 とても面白い！ 結局のところ、どこでもIO（）を使用していません。どこから来たのですか？ Haskellの暗い行為と意性のせいですでにHaskellを責めようとしている場合は、急がないでください。 実際には、Haskellによると、入出力（I / O）アクションは潜在的なエラーおよび障害であり、「副作用」としても知られています。 したがって、入出力関数（putStrLn、putStr、putChar、getLine、getChar、readFile、writeFile）は危険であり、同じ引数に異なる結果を返すことがあり、場合によってはエラーをスローすることさえあります。 したがって、これらはIO型であり、言語の観点では、私たちに関係するはずです。 さらに、内部にIOタイプを持つ他のすべての関数も非決定性になり、採用する必要があります。 run関数は安全でないアクションを選択したため、IO（）タイプに感染しました。 ちなみに、プログラムへのエントリポイント（メイン関数）は、runが呼び出されるため、この運命を逃れませんでした。

* Main > ：t main

メイン:: IO （ ）

公平に言えば、説明ではIOアクションを伴う関数は非決定的であるという仮定がなされていると言う価値があります。 実際、これは完全に真実ではありません。 ある意味でそのような関数は決定論的であり、純粋でさえあります。 この質問は、一般的に言えば、Haskellの純度に関する議論のつまずきのブロックであり、その議論はインターネットで見つけることができます。

上記は私たちの問題にどのように関係していますか？ 間違ったコードを（コンパイルせずに）もう一度見てみましょう。実行関数の定義を順番に割り当てます。

実行::ロケーション-> IO （ ）

curLoc = doを実行します

locDescr < -describeLocation curLoc

putStrLn locDescr

putStr 「コマンドを入力：」

x < -getLine

のケース （ convertStringToAction x ）

...- 残りのコード

知っているように、doキーワードはアクションをチェーンにリンクしますが、チェーンにはリンクしません。 do-notationでは、チェーン内のすべてのアクションが同じ型を返す必要があります。 I / Oで作業するため、関数のタイプにはIOが含まれている必要があります。

*メイン> ：t putStrLn

putStrLn :: 文字列 -> IO （ ）



* Main > ：t putStr

putStr :: 文字列 -> IO （ ）

String型の引数に加えて、これらの2つの関数は同じ戻り値型-IO（）を持っています。 ここでの空の括弧は、有用なものが何も返されないことを示します。 実際、コンソールに引数を出力するだけであれば、putStrLnが何を返すかは関係ありません。 それどころか、getLine関数には「有用な」何かが期待されますが、これは独自の方法でそのタイプに反映されます。

* Main > ：t getLine

getLine :: IO 文字列

getLineはユーザーから文字列を受け取り、それをギフトとしてIOタイプにパックします。 そして、あなたがギフトで何でもしたいです。 たとえば、convertStringToAction関数に渡します。

...

x < -getLine

のケース （ convertStringToAction x ）

...

しかし、convertStringToAction関数には異なる型があります！ -あなたを叫び、あなたは正しいでしょう。 彼女はIO Stringではなく、入力でStringを待っています！ トリックは何ですか？ さて、これらの2行のどこかでギフトが展開され、IOボックスは捨てられ、空白行はすでに進んでいます。 そして、これは矢印によって行われます。 パックされた結果を右側から取得し、左側の変数にアンパックします。 ところで、この操作は割り当てではなくバインディングと呼ばれます。 考えてみると、右側のどこにも何も詰め込まれていないため、「locDescr <-describeLocation curLoc」という表現は間違っています。読み取り、結果はIOボックスに入れられません。

* Main > ：t （ロケーションホームの説明）

（ describeLocationホーム） :: 文字列

さて、ここにあります...できるだけシンプルにしたかったのですが、多くのページがどのような結果をもたらしました。 しかし、私はあなたに朗報があります：解決策があります！ 私たち自身が右側にあるものをタイプIOに詰め込み、矢印を窒息させます。 これには戻り関数があります。 次のコードは意図したとおりに機能します。

実行::ロケーション-> IO （ ）

curLoc = doを実行します

locDescr < -return （ describeLocation curLoc ）

putStrLn locDescr

putStr 「コマンドを入力：」

x < -getLine

のケース （ convertStringToAction x ）

終了-> putStrLn 「 会い ましょう...」

見て-> やる

putStrLn locDescr

curLocを実行します

...- 残りのコード

はい、戻り関数は文字列をdo（IO）ブロックタイプにパックし、矢印はそれをアンパックしてlocDescr変数に関連付けます。 また、場所の説明を何度も計算する必要がなくなりました。 もちろん、論理は珍しいですが、あなたは同意する必要があります：それには何らかの内面的な美しさがあります。 飲む価値あり！

IOの表記法とタイプには、さらに多くの結果と落とし穴があります。 より深く掘り下げると、副作用だけでなく、IOアクションとは異なる法則に従って関連付けることができる他の多くの計算も、普遍的な方法で調整できます。 いわゆるモナドを使用して計算を行うと、驚くほどシンプルで便利なロジックになり、コードは簡潔で理解しやすく、表現力になります。 このようなコードは厳密に数学的で非常に便利であることが重要です。 解析、DSL、可変状態など、特定のタスクを記述するのに非常に適しています。 おそらくいつかこのトピックに戻りますが、これが実際に必要になるのはそれ以前です。

さて、私たちは問題を解決しました。 では、なぜ他の解決策を考え出す必要があるのでしょうか？ はい、一般的には、同じことです。Haskellについて何か他のことを学ぶことです。



次のソリューションでは、whereコンストラクトを使用します。 これは、ここでのみ利用可能な関数を記述することができる特別な構造です-他のプログラミング言語の入れ子関数のように。 whereブロック内では、親関数の変数が使用可能であり、通常の関数に適用されるすべての法則が適用されます。 つまり、同じ関数の複数のバリアントを作成し、パターンマッチング、セキュリティ式を使用し、さらにネストされたwhere-constructionを作成できます。



構造が特別な説明を必要としない場合、例を見てください：

実行::ロケーション-> IO （ ）

curLoc = doを実行します

putStrLn locDescr

putStr 「コマンドを入力：」

x < -getLine

のケース （ convertStringToAction x ）

終了-> putStrLn 「 会い ましょう...」

見て-> やる

putStrLn locDescr

curLocを実行します

...- 残りのコード

どこで

locDescr = describeLocation curLoc

whereブロックの前にdoブロックと同じインデントを作成しました。 基本的に、このブロックの場所を定義しました。 結果を変数locDescrに割り当てているように見えるかもしれませんが、そうではありません。 ここには変数と割り当てはありません。 locDescrは、場所の説明を返す関数です。 この関数を親コードから2回呼び出します。 ただし、ほとんどの場合、一度だけ計算されます。 Haskellコンパイラは、過去の結果を再利用のために保持できます。 データが不要になると、組み込みのガベージコレクターによって削除されます。 フィボナッチ数が計算される最後の部分のサイドバーを思い出してください。 再帰の各ステップで値が最初から計算された場合、プログラムはどのように機能しますか？



最後に、最後の解決策-いわゆるlet式-が最も単純で、おそらくここで最も適切です。 また、let式はwhereと非常に似ていますが、式のエイリアスを定義しますが、そのような名前の関数は定義しません。 doブロック内では、let式は次のようになります。

実行::ロケーション-> IO （ ）

curLoc = doを実行します

let locDescr = describeLocation curLoc

putStrLn locDescr

putStr 「コマンドを入力：」

x < -getLine

のケース （ convertStringToAction x ）

終了-> putStrLn 「 会い ましょう...」

見て-> やる

putStrLn locDescr

curLocを実行します

...- 残りのコード

doブロックの外側、たとえば他の式の内側でlet式を使用すると、レコードはわずかに変わります。 inキーワードが追加されます。

実行::ロケーション-> IO （ ）

curLoc =を実行します

let locDescr = describeLocation curLoc in

する

putStrLn locDescr

putStr 「コマンドを入力：」

x < -getLine

のケース （ convertStringToAction x ）

終了-> putStrLn 「 会い ましょう...」

見て-> やる

putStrLn locDescr

curLocを実行します

...- 残りのコード

実際、letとinの間にこのような式をいくつでも定義できます。オブジェクトの追加に進むと、これがどのように行われるかがわかります。 それまでは、let式がdoブロック内にある前のオプションをそのままにします。

Let式は短く書かれているだけでなく、いくつかの特別な場合に使用できるため、優れています。 そのため、たとえば、同じ目的でリスト内包表記にletを挿入できます。スコープを制限して式を定義します。 ただし、欠点もある場所と比較して、ガード式とパターンマッチングを使用することはできません。 もちろん、私たちは仮名を定義しているので、その範囲内でそれらを繰り返すべきではありません。

オブジェクトに到達したときに尋ねますか？ 私はすでに切り替えています。 あなたはまだですか？ その後、追いつく。 次のように、オブジェクトのADTタイプを作成します。

データオブジェクト=テーブル

| 傘

| 引き出し

| 電話番号

| メールボックス

| フレンドキー

導出 （ Eq 、 Show 、 Read ）

場所の画像に、オブジェクトの説明を含む関数を追加します。

describeObject :: Object- > String

describeObject Umbrella = "素敵な赤いメカニックの傘。"

describeObject Table = "引き出し付きの良い木製テーブル。"

describeObject Phone = "電話には音声メッセージがあります。"

describeObject MailBox = "メールボックスが閉じています。"

describeObject obj = "特別なことは何もありません" ++ show obj

トリックはありません、私たちはすでにこれをすべて知っており、私たちはできるのです。 新しいオブジェクトは、場所のオブジェクトを定義する必要があるときに始まります。 もちろん、すべての準備が整い、テイクアンドドロップアクションが機能し、インベントリ、複合オブジェクトがあったことを望みます...しかし、これは起こりません。 次に、オブジェクトのドラフトバージョンを作成またはスローできない場所で作成し、それに基づいて他のより高度で適切なメカニズムを考えます。



ゲームが始まるホームの場所にいくつかのオブジェクトがあり、その中にテーブル、テーブル引き出し、電話、傘があると仮定します。 この場所のオブジェクトのリストを返すlocationObjects関数を設定します。

locationObjects ::場所-> [オブジェクト]

locationObjectsホーム= [傘、引き出し、電話、テーブル]

locationObjects _ = [ ]

一般的に、リストはシンプルに見えます。 オブジェクトのリストは[オブジェクト]の一種です。 ホームの場所については、4つのオブジェクトのリストを返します。 空のリストは、他のすべての場所にオブジェクトがない限り、空の角括弧で示されます。 先に進む前にコードをテストする価値があります。

*メイン> locationObjectsホーム

[傘、引き出し、 Phome 、テーブル]



* Main > locationObjects Garden

[ ]



*メイン> describeObjectテーブル

「引き出し付きの良い木製テーブル。」

Object型はShow型クラスから継承されるため、show関数は型コンストラクターだけでなく、この型のリストにも使用できます。

*メイン>傘を表示

傘



*メイン> ショー [傘、テーブル]

「[傘、テーブル]」



* Main > show （ locationObjects Home ）

「[傘、引き出し、電話、テーブル]」



* Main > putStrLn （ show （ locationObjects Home ） ）

[傘、引き出し、電話、テーブル]

逆もまた真です。 読み取り関数でリスト項目を解析できる場合、リスト全体も解析できます。

* Main > read "[Table、MailBox]" :: [ Object ]

[表、メールボックス]

構文が理解できたので、現在の場所について説明が表示されるだけでなく、そこにあるオブジェクトのリストも印刷されるように構文を作成します。 let式を使用してみましょう。

curLoc = doを実行します

let locDescr = describeLocation curLoc

let objectsDescr = " \ nここにはいくつかのオブジェクトがあります：" ++ show （ locationObjects curLoc ）

let fullDescr = locDescr ++ objectsDescr

putStrLn fullDescr

...- 残りのコードは、Lookアクションを更新することを忘れないでください。

プログラムの出力は次のようになります。

*メイン>メイン

Haskellでのクエストアドベンチャー。



ホーム

あなたは木製のテーブルの真ん中の部屋に立っています。

ここにはいくつかのオブジェクトがあります： [傘、引き出し、電話、テーブル]

コマンドを入力してください：

コードには少し面倒です。 その場所にオブジェクトがなくても、「ここにはオブジェクトがいくつかあります」という碑文は、まだ目障りです。

コマンドを入力：Go North



北へ歩いています。



庭

あなたは庭にいます。 .....

ここにはいくつかのオブジェクトがあります： [ ]

コマンドを入力してください：

オブジェクトの空のリストに対して表示しないように、オブジェクトを記述するためのすべてのコードを別の関数に入れ、enumerateObjectsと呼びます。 入力ではリストを受け取り、出力ではリストされたオブジェクトを含む文字列を渡します。

enumerateObjects :: [オブジェクト] -> 文字列

enumerateObjects [ ] = ""

enumerateObjects objects = " \ nここにはいくつかのオブジェクトがあります：" ++オブジェクトを表示

enumerateObjects関数の最初のバリアントは空の文字列を返しますが、転送されたオブジェクトのリストが空の場合のみです。 空でない場合、最初のオプションは拒否され、2番目のオプションが機能します。 実行機能：

curLoc = doを実行します

let locDescr = describeLocation curLoc

let objectsDescr = enumerateObjects （ locationObjects curLoc ）

let fullDescr = locDescr ++ objectsDescr

putStrLn fullDescr

... -...

または、必要に応じて、doブロックからlet式を引き出すことができます。

curLoc =を実行します

させる

locDescr = describeLocation curLoc

objectsDescr = enumerateObjects （ locationObjects curLoc ）

fullDescr = locDescr ++ objectsDescr

やる

putStrLn fullDescr

... -...

この単純なリファクタリングのおかげで、実行に影響を与えずにenumerateObjects関数を変更できるようになりました。 したがって、オブジェクトを列挙するだけでなく、オブジェクトの説明も表示したいので、遊び心のあるペンでenumerateObjectsにアクセスして、そこにある何かを修正しました。 しかし、どういうわけか後で。 次に、カスタムアクションInvestigateを追加しましょう。 このコマンドにより、プログラムはオブジェクトの詳細な説明を提供する必要があります。 ユーザーが次のように入力する必要があることは明らかです。

コマンドを入力：傘の調査

「Investigate Umbrella」という行を解析する必要があります。 おなじみですか？ 既にGoチームでこれを行っています。 ここでも同じです。InvestigateコンストラクターにObjectパラメーターを配置するだけです。

データアクション=

...

| オブジェクトを調査する

...

ほんの少しだけ-実行機能を修正するには：

curLoc = doを実行します

...

...

のケース （ convertStringToAction x ）

objを調査する-> do

putStrLn （ describeObject obj ）

curLocを実行します

...

そして出来上がり！ 別のユーザーアクションを実装しました！ おめでとうございます！ コマンド「Investigate Umbrella」を入力すると、プログラムに「Nice red mechanic Umbrella」という文字列が表示されることを確認できます。



それだけです...私たちの悪いところを知っていますか？ ホームの場所で「Investigate MailBox」コマンドを入力すると、メールボックスの説明が表示されますが、ここからはまったく見えません！ それでは、オブジェクトが見つかった場合にTrueを返すisVisible関数を考えます。この場合のみ、オブジェクトの説明を発行します。 isVisible関数の引数は何ですか？ 調査対象のオブジェクトと、すべてのロケーションオブジェクトのリストが必要です。 このようなもの：

isVisible ::オブジェクト-> [オブジェクト] -> Bool

このリストにオブジェクトがあるかどうかをどうにかして調べる必要があります。 リスト内のすべてのオブジェクトを列挙する「愚かな」オプションは考えられませんが、これは非常に可能ですが、標準のelem関数を使用するだけです。 要素とリストの2つのパラメーターを取ります。 リスト内にアイテムが見つかった場合、Trueを返します。 必要なもの！

isVisible ::オブジェクト-> [オブジェクト] -> Bool

isVisible objオブジェクト= elem objオブジェクト

Haskellには特別な表記法があり、関数を引数の間に配置します-意味の明確さと透明性を高めます。 これを行うには、関数を逆アポストロフィ、ボタン上にあるもので囲む必要があります。

isVisible ' ::オブジェクト-> [オブジェクト] -> Bool

isVisible 'obj objects = obj ` elem`オブジェクト

しかし、同じ機能の「ダム」バージョン。 それらの中で、リスト内のオブジェクトを手動で探します。

isVisible '' ::オブジェクト-> [オブジェクト] -> Bool

isVisible '' obj [ ] = False

isVisible '' obj （ o：os ） = （ obj == o ） || （ isVisible '' obj os ）



isVisible '' ' ::オブジェクト-> [オブジェクト] -> Bool

isVisible '' 'obj [ ] = False

isVisible '' 'objオブジェクト= （ obj == ヘッドオブジェクト） || （ isVisible '' 'obj （ テールオブジェクト） ）

それらは同じように機能し、違いは使用する手段のみです。 そことそこの両方で、リストは部分に分割されます：残りの要素のヘッド要素とテール。 最初の例では、リストはエントリ（o：os）を使用して分割されます。 変数「o」にはヘッドが含まれ、変数「os」には他のすべてが含まれていることは明らかです。 2番目の例では、ヘッドリストとテールリストの上の組み込み関数でのみ同じことを行います。 次に、オブジェクトがhead要素と一致するかどうかを確認し、一致しない場合は、残りの要素に対してisVisibleを再帰的に呼び出します。 再帰が無限にならないようにするために、関数「isVisible obj [] = False」のバリアントを追加しました。リストのすべての要素を突然噛んで、何も残っていない場合に機能します。

さて、残っているのはこの機能を使用することだけです。 いつものように、runを変更し、現在の場所のオブジェクトを数回要求しないように、それらをlet式に入れます。

curLoc = doを実行します

let locObjects = locationObjects curLoc

let locDescr = describeLocation curLoc

let objectsDescr = enumerateObjects locObjects

let fullDescr = locDescr ++ objectsDescr

putStrLn fullDescr

putStr 「コマンドを入力：」

x < -getLine

のケース （ convertStringToAction x ）

objを調査する-> do

if （ isVisible obj locObjects ）

次に putStrLn （ describeObject obj ）

else putStrLn （ "表示されません" ++ show obj ++ "here。" ）

curLocを実行します

終了-> putStrLn 「 会い ましょう...」

...- 残りのコード

以上です。 この重要な注意事項を停止します。休憩の時間です。すでに膨大な知識があります。

修正のための割り当て。



1.オブジェクトに関連するすべての機能をオブジェクトモジュールに、場所に関連するすべての機能を場所モジュールに転送します。

2.ロケーションオブジェクトの実験的結論を次の形式で作成します。

 ホーム
あなたは木製のテーブルの真ん中の部屋に立っています。
  ここにはいくつかのオブジェクトがあります。
     傘：素敵な赤い整備士の傘。
     テーブル：引き出し付きの良い木製テーブル。
     電話：電話には音声メッセージがあります。
     引き出し：引き出しには特別なものはありません。 

3. Investigateアクションの処理をリファクタリングするには、このための個別の関数を作成します。 リファクタリング後のrun関数のコードは次のようになります。

...

objを調査する-> do

putStrLn （ obj locObjectsを調査）

curLocを実行します

...

この部分のソース 。



目次、参照、および追加情報はGreetingsにあります。