これからこの型を幾度となく見ることでしょう。関数をリファクタリングしましょう。ようにしなければなりません。あることを意味します。あるため、エラーの報告には全く役立たないことです。別の何かに変えることから始めましょう。間違いなく簡単に使えます。返せばいいのですから。パニックを起こすよりは良くなっています。いえ、もっと良くすることもできます。代わりに、発生したエラーについての詳細を渡すべきでしょう。使うのがよさそうです。型のエラーが起こり得ますので、これらを共通の型に変換する必要があります。}}このコードは、やや難解になってきました。このようなコードを簡単に書けるようになるまでには、結構な量の練習が必要かもしれません。変更したらすぐに、それに合ったコンビネータを探し始めるのです。3種類のコンビネータだけを使いました。エラーを返すかもしれない処理同士を繋いでいくために使います。ファイルから読み込む所と、内容を数値としてパースする所です。ときに関数を適用するために使います。定義に従ってスキップされます。全体をうまく動かすための仕掛けです。ときに関数を適用するところが異なります。いう同一の型に変換する予定でした。メソッドを呼ぶことで変換できました。説明し終わった後でも、このコードは難解なままです。コンビネータの使い方をマスタすることは重要ですが、コンビネータには限界もあるのです。次は、早期リターンと呼ばれる、別のアプローチを試してみましょう。使って書き直してみようと思います。早期リターンとは、関数の途中で抜けることを指します。クロージャの中にいる間は、早期リターンはできないので、明示的な場合分けまでいったん戻る必要があります。}}このコードが、コンビネータを使ったコードよりも良くなったのかについては、人によって意見が分かれるでしょう。あなたがコンビネータによるアプローチに不慣れだったら、このコードのほうが読みやすいと思うかもしれません。エラーが起きたら関数の実行を打ち切って、エラーを(文字列に変換してから)返します。以前は、エラーハンドリングをエルゴノミックにするために、明示的な場合分けを減らすべきだと言っていました。それなのに、今は明示的な場合分けに戻ってしまっています。コンビネータが唯一の方法ではありません。マクロはコンビネータと同様、場合分けを抽象化します。抽象化してくれることです。パターンを抽象化できるのです。