Amosapientiamスマートフォン用の表示で見るAmosapientiam備忘録この広告は、90日以上更新していないブログに表示しています。意外とこれを一覧したページが見つからないので自分用にまとめた。実用上の価値は特に思いつかない。随時減らしたり増やしたりする。B#説明を読む限りC#に似てそう。コンパクトさをアピールしている。C#.netの看板言語。Javaと比較されることが多い。F#OCamlっぽい.net言語。J#.net上で動くJavaっぽい言語。21:15「#」で終わる二文字のプログラミング言語のリストTweet広告を非表示にするもっと読むコメントを書く2018-08-11C#でズンドコキヨシしてみたn番煎じながらズンドコキヨシしてみた。Extensionsを使っている。解説main関数は以下の通り。x.Last()).Cast<object>().ForEach(WriteLine);行ごとに解説する。Doko))ZunとDokoをランダムに返す無限列を生成している。6))上述の列を最大長さ6の履歴列に変換している。Dokoのpatternになったら終了。x.Last()).Cast<object>().ForEach(WriteLine);最新(最後)の履歴を取り出し出力。}無限イテレータ↑が標準で欲しい。12月31日の23時58分に完成した記事です。一年のシメをこの記事に費やした事実は私がズンドコクラスタであることのなによりの証拠です。オブジェクト生成に用いられるデザインパターンです。必要な引数のみをメソッドチェーンで渡してオブジェクトを生成し、コンストラクタが多くの引数を取り、また省略可能な引数が多いときに有効とされています。今までにさまざまな言語で型安全なBuilderの書き方が紹介されてきており、つい昨日もuhyo氏によりTypeScriptで型安全なBuilderパターンを書く記事が公開されました。本記事ではC#で型安全なビルダーを構築します。ソースコードはこちら断り書きC#には名前付き引数や省略可能引数などがありますが、今回は先行記事たちとレギュレーションを近づけるために使っていません。JavaでBuilderパターンが有効な場面であるからといって、C#でもBuilderパターンが有効だとは限りません。本記事はあくまで「あえてBuilderパターンを適用してみた場合」の話です。対象クラス以下のクラスのビルダーが作りたいとします。{_age}");}IDと名前は必須で指定する必要があり、年齢は指定しなくてもかまいません。型安全でないビルダーまずは型安全でないビルダーを書いてみます。すれば国民番号1番で17歳のRikuさんが生成されます。ビルダーを使用すれば正しく人間が生成されます。残念ながらこのビルダーは以下のような不正な使用を弾くことができません。実行時に検査して例外を吐くように変更するのもひとつの手ですが、ここではレギュレーション従うことにします。このビルダーを静的に正しさを保証するビルダー、すなわち型安全なビルダーに改造します。全体像は以下のとおりです。{}変更点を順を追って説明します。型をフラグとして使うまず、各項目がすでに指定されているかどうかを型で管理する必要があるので、それを表すフラグとしてIOptインターフェースを用意しました。既指定の場合はSomeと使い分けます。{}項目の状態管理Builderは3つの項目の指定の有無を管理するためにIOptを継承する型変数を3つ保持します。->型からBuilder<Some,-,->型への関数となっています。idがまだ未指定のときのみId関数を呼ぶことができ、一度呼ぶとIdが指定されたフラグが立ちます。TId以外の型パラメータは変更されません。builder.Age);Name関数、Age関数も同様です。Person型への関数になっています。idとnameがすでに指定されたBuilderでなければBuild関数を呼ぶことはできません。ageに関しては未指定/既指定を問うていません。以下のような呼び出しはコンパイルが通ります。Builder.Create().Id(4).Name("Aki").Build()Builder.Create().Name("Anna").Id(5).Build()Builder.Create().Name("Mika").Age(24).Id(6).Build()以下のような呼び出しはコンパイル時に型エラーで弾くことができます。Builder.Create().Id(7).Name("Masa").Name("Jarkko").Build()Builder.Create().Id(8).Build();項目指定の間違いをコンパイル時の段階で弾いてくれる型安全なビルダーができあがりました。Blog幽霊型で状態をタグ付けする手法が本記事と同じです。TypeScriptで型安全なBuilderパターンTypeScriptの精緻な型システムを用いて問題が解決されています。present幽霊型を使ってクラスの状態管理をする方法がとてもわかりやすく例示されています。10101010101001本記事で扱っているものとは少し違ったBuilderパターンの例が紹介されています。いう依存型プログラミング言語を少し触ってみました。この言語には強力で複雑な型システムが組み込まれています。現状、依存型言語は世間にはあまり広まっていませんのでF*とは?複雑な型ってなんだろう?複雑な型システムを組み込んで何が嬉しいんだろう?何が嬉しくないんだろう?と疑問をお持ちになる方も多いだろうと思います。この記事ではF*で使われている複雑な型の一部と、複雑な型を持つことの利点・欠点の一部を述べ、それを簡単なコード例を通じて体感してみます。開発中のプログラミング言語です。組み込まれており、複雑な仕様が型で表現できます。F#などのML系関数型言語に似ています。詳しくは下記のリンクたちを参照。effectが組み込まれていることがわかります。型の中に値が現れる型です。「整数型で100より大きい値」の型や「文字列で、長さが10より小さい値」の型などです。関数の型の中には純粋で必ず停止する関数である停止するとは限らない副作用があるかもしれない...などの情報が埋め込まれています。これらを表現する仕組みがeffectと呼ばれています。型は仕様でもあること、型検査は仕様検証でもあることは以前の記事で書きました。この観点から、複雑で表現力の高い型を持つことには以下の利点があると言えます。型によって複雑な仕様が表現でき、実装が複雑な仕様を満たすことを型検査によって保証できる。型が複雑になるにつれ、コンパイラが自力で型検査ををするのは難しくなります。コンパイラの助けになるように人間が自力で型付けのヒントを書かなければならない場面も増えます。極端な場合は複雑な証明をひたすら書くハメになります。以上で挙げた特徴がどういうものなのか、具体的にシンプルな関数を例にとって確認してみます。以下の関数を例にとります。aこの関数は少なくともコンパイルが通ります。