欲しいシーンはあるので、ちょっと欲しいです。文の強力版ただし、match式はパターンマッチのほんの1例にすぎない。この例だと、あまりありがたみはないが、F#にはさまざまな形式のパターンマッチが提供されているので、非常に便利。名無しの権兵衛さんレコード型をパターンマッチで分解しているの図。!だったりするが華麗にスルーで。Pattern,(アクティブパターン)なんてのもある。なんか見たことあるやつ。動物抽象クラスを継承して動物たちが鳴くやつ。ここもスルーで(機能的にはmatch式と同じでその引数省略できる版)いわゆる代数的なデータ型的なやつ。一部誤解を与えてしまう可能性もあるが、ある種のクラス階層を表現するのに使える。オブジェクト指向プログラミングの「継承」と明らかに違う点は、まったく性質の異なるものを同質のものとみなして定義することが出来る点、かなあと思う。これを難しいと言われると、もうどうしようもない。中括弧のことなわけですが。洞窟物語のキャラにカーリーブレイスって居たなと。スコープがインデントで区切られるという構造のオフサイドルール(軽量構文)。Pythonインスパイア。これに対して、インデントにしばられない冗語構文もあるが、(どうとでもなるので)そっちは別段覚えなくてもよいと思う(個人の感想)オフサイドルールは最初こそ少しとっつきにくいかもしれないが、ルールがシンプルなのですぐに慣れることができるだろうし、実際明確でわかりやすいように思う。人によっては「見た目キモすぎぃぃぃ」と言う反応をする方もいる。それも理解できないこともない。慣れないものを見ると拒絶反応を示すというのはごくごく当たり前の反応だし。無理なものは無理だし。you!)とかもまあ現実世界でも実際あるわけだし、世知辛いですね(なんの話)唐突には挿入した息抜き用の画像。さんが作ってくれたものです。かなりの謎コラだけど、非常によい表情です。変数は、値にわかりやすい名前を付けて定義しておくことで、続くコードで再利用するためのもの。変数を作り出すことを変数束縛と言います(くどい)例えば破壊的代入(再代入)を許すようなプログラムでは、変数が異なる状態を持ち得るのでその変数を参照する場合「この変数の今の値は何だろう?」と観測しなければならなくなり、複雑性を生み出す要因となる。よる変数束縛ではデフォルトで破壊的代入(再代入)ができません。mutable宣言をすることで、破壊的代入が可能な変数として宣言することもできます。関数プログラミングというスタイルでは極力「破壊的な状態の変化」というものを避ける傾向にあるので、破壊的代入をデフォルトで許さないようにしている。これはスタイルとしての「副作用をできるだけ使わない」ということを推奨/支援しているとも言える。変数が状態を持ってしまうと、その変数を参照する箇所で「この変数の今の値は何だろう?」と注意しなければならない。この例においては、2番目の出力は「5963」ではなく「4649」と表示される。F#は、変数を後から宣言した同名の変数でシャドウイング(隠ぺい)することができる。シャドウィングが使えることで、破壊的代入をしなくても不便さはそれほどなくなる。プログラムのスコープが明確になり、書きやすいだけではなく非常に読みやすいプログラムとなる。スコープの中の直前のものにのみ着目すればよいので、余計な複雑さを排除できてコードの見通しがくなり、プログラミングそのものに集中できる。宣言をシャドウィングすることはできないという制限ありプログラマーのかわりに関数を利用しているコードの型などから、コンパイラがよしなに型をつけてくれる型推論。関数の引数や戻り値にも型を書かなくてよいし、可能であればジェネリックな関数として自動的に推論してくれたりする。変数の定義も関数の定義も、letというキーワードで統一的に定義できるようになっていてうれしい。キーワードを覚えるだけで、かなりのプログラミングが書ける。式を覚えれば条件分岐もできる。覚えれば、ループ処理が書けるので、いとも簡単に三種の神器を手に入れることができる(アッハイ)JavaScriptのコードでカリー化関数と部分適用の説明。JavaScript!なのだが、社内勉強会用に作った資料の流用だったりするので。高階関数のうれしいところ高階関数を扱いやすくするのに必要な機能とかの話。F#では関数内関数が簡単にかけてうれしい。高階関数を書きやすくする要因のひとつとして、関数内関数が無理なくかけるかというのがある。書けないこともないが、どうしても書きにくいので書くモチベーションにならない。素直に名前を付けてメソッドとして切り出して書くべきだ。F#では、無理なく関数内関数を書くことができるのでなんの抵抗も生まれないし、その場限りの関数であれば、関数内関数として定義することはごくごく当たり前に行われる。これは、インデントによるオフサイドルールとも相性が良く、書き方/スタイルとして非常になじむ。プログラミングスタイルそのものが変わります。関数の合成のしやすさも、関数プログラミングのしやすさの指標と考えられます。C#で合成関数を書こうとするとかなり骨が折れます。これは、特定の型に関する合成しかできません。F#で定義した関数は、コンパイラの型推論と自動ジェネリック化のメカニズムによって、可能であれば暗黙的にジェネリックな関数となります。これにより非常にシンプルな記述で、あらゆる型の関数を合成するような関数(演算子)が表現できてしまうというわけです。いった特徴を兼ね備えているので、小さな関数を巧みに組み合わせて、より大きな関数を構築していくという関数プログラミングというプログラミングスタイルが違和感なく行えます。レキシカルスコープのほうが、コードを追いやすい話。ダイナミックスコープで解決されてうれしい場面ってどの程度あるのだろうか。F#はレキシカルスコープを採用しているので、オフサイドルールやシャドウィングの仕様ともよくマッチしていて人道的でわかりやすいスコープとなっている。コードは非常に読みやすい(追いやすい)。これが仮にダイナミックなスコープだとすると、関数を適用したときに、どのような結果をもたらすかコードリーディングだけで判別しにくくなってしまう。高階関数とかこわくて使えない。言い換えると、関数プログラミングしやすい条件ともいえる。ここから、「続きはWebで」のぶぶん有名なアレ。null非許容型が欲しいなんて話はたびたび聞きます。いう話ではないんです。値を値にも変数にも使用しません。デフォルトで危険性を回避するように設計されています。例外的な場合を除いて、nullの使用はできる限り避けるよう言語設計されています。してもコンパイルエラーとなります。値を扱うことはあります。メソッド呼び出しからの戻り値または出力パラメーターを解釈する場合のいずれかしかありません。属性を使用して対応します。許容する型を明示的に定義することができます。使用すべきではありません。NullReferenceExceptionとなります。いずれかの関数を使用した場合に限られます。いえ、値がない状態というのをプログラミングで表現したいシーンはたくさんあります。そんなときに役立つのがオプション型で、これにより「値がないかもしれない」ということを型として明示することができます。計算不能や計算失敗などにより、実際の値が存在しない場合などに使えます。あることが型の情報として現れないことで。null参照によるエラーというのは実行してみるまで誰にも分からないからです。nullが来るかどうかの判定をプログラマーが正確に管理しなければならないこと意味します。これは実際難しいことです。null値を使用することなく安全に「値がない状態」を表すことができます。面白い(エキサイティングな)機能なのでご紹介します。」「わけがわからないよ。コード上であらゆる情報を安全に扱えるようにする仕組み。型プロバイダーの主目的はコンパイル時プログラミングではないものの、型のないものを扱う際に生じやすいしょーもないバグを未然に防ぐことができるソリューションと解釈することもできます。型のないものを安全に扱える世界があなたの手中にといったところです。ごむごむいろいろできそうです(オラワクワクしてきたぞ)でも、TypeProviderはDSLなどをメタプログラミングするためのものではないと、TypeProviderのドキュメントに書かれています。学習目的であればメタプログラミング目的の方がとっつきやすいかもしれませんので。導入するのがもっとも近道。TypeProviderを作る際に必要な便利部品がひととおり用意されている。スキーマが動的に変化することは想定されていないので、スキーマがコーディング中やプログラムの実行中に安定しているかということは、もちろん前提として必要。構造体だったりに対するマッピング。型システムと言っているのは、主に判別共用体やレコード型に対するマッピングを意味している。型システムの型を生成するのか、あるいはオブジェクト指向プログラミングになじみやすいような型を生成するのか、そのあたりはよく検討してデザインする必要がある。FsBulletMlでは実際に、XML(外部DSL)から判別共用体(型付き内部DSL)への安全なマッピングのためのTypeProvider提供しています。セッションでは、いちおう簡単なDemoだけ紹介しました。コンパイル時にメタデータからリアルタイムで型がつくられる。Studioとも連携しているので、インテリセンスも効くという感じ。こんな簡単なDemoからでも、「TypeProviderでなんか面白いことができそうだな!」ということが容易に想像できると思う。今回のDemoのような単純なものであれば少し勉強すれば、すぐに作れるようになりますが、ある程度複雑なものになると、ぐんと難しくなります。それは関数プログラミング的な側面で難しいという意味ではなく、メタプログラミングの側面として難しいという意味です。FSharp.Data等のライブラリのソースを読んで勉強する感じになるかと思います。github.comF#に限らずさまざまな言語の話も飛び交う感じの割とフリーダムなゆるい集まり。私も何度かお邪魔して楽しくすごさせていただいています。ほとんどF#を書いたことがないというような人でも気軽に参加していただける勉強会です。言語の発展に物申したい場合は有料会員になる感じだと思います。さんは、こちらのボードメンバーでもあります。他のプログラミング言語に比べてF#が特別難しいというようなことはありません(もちろん難しい部分も当然あります)。F#は高階関数が扱いやすく関数プログラミングがしやすい言語です。プログラミングのスタイルは自然と関数プログラミングに軸をおいたものとなります。F#って何に使えるんですか?等の質問をいただきますが、VBがC#とほとんど同じ場面で使えると同じように、ほとんどの場面で同じようにF#も使えます。F#を選択する理由があるとするならば、関数プログラミングのスタイルおよびそれによって享受できるメリットを重視するかしないかくらいのものです。それ以上でもそれ以下でもありません。関数プログラミングのスタイルを重視しないのであれば、選ぶ理由はないでしょう。現状、世間一般ではそれを重視しないのが多数派であり、人材の確保が難しかったりある程度学習コストが高いという側面があるので、選択肢としてあがることも少なく(んなもんで人材が増えないという悪循環)、結果「流行っていない」ということになります。実際間違いではないし、どちらかというと筋がよいことだと思うんだけど、それを必要としている人もいるししてない人もいるというのは理解できます。実際いまのところは(残念ながら)必要とされていない(らしい)ので、F#流行っていないということになります。良い言語(実際)ですが、今のところMSが推す気配なし!ということもあって、だいぶ闇は深いです。月別アーカイブ参加グループプログラミング。