多値について本気で考えてみた - ぐるぐる～
先日のエントリの反応として、多値の批判をしているように受け取られた方がいました。 実際には、多値の批判をしているのではなく、Go言語の「多値とそう見えるけど違うものがある」という仕様を批判したものでした。 また、タプルにこだわっているという受け取り方をした方もいました。 このエントリでは、「タプルにこだわっているのではない、多値にこだわっているのだ」ということを説明しようと思います。 このエントリで出てくるコードは言及がない限り妄想上のもので、実際の言語のコードではありません。 長いから3行で。 スタックマシンと多値は仲良し。継続と多値も仲良し。 多値は多値、タプルはタプル、みんなちがってみんないい。 多値とは、カンマで区切られた単なる複数の値だよ。妄想だけどね。 これで満足して仕事に戻っていただいて構いません。以下オマケ。 多値とタプルの違い まず、多値とタプルの意味的な違いについてをは
続・そろそろPower Assertについてひとこと言っておくか - ぐるぐる～
3年前にこんな記事をあげました。 bleis-tift.hatenablog.com 3行でまとめると、 Power Assertはユニットテストのためにほしかったものではない 欲しいのは結果の差分 誰か作って！ というエントリでした。 そしたら id:pocketberserker が作ってくれました！ github.com PowerAssertより強そうな名前でいい感じです。 Power Assertは時代遅れ、今はMuscle Assertだ！的な話かな？— 裸のWPF/MVVMを書く男(マン) (@gab_km) 2016年6月1日 MuscleAssertの使い方 このライブラリは、PersimmonというF#用のテスティングフレームワークを拡張するライブラリとして作られています。 ただ、ざっくり概要をつかむだけであればどちらも知らなくても問題ありません。 このライブラリででき
再帰関数のスタックオーバーフローを倒す話 その3 - ぐるぐる～
連載目次 再帰関数のスタックオーバーフローを倒す話 その1 CPSとCPS変換の話 再帰関数のスタックオーバーフローを倒す話 その1.5 F#での「末尾」についての話 再帰関数のスタックオーバーフローを倒す話 その2 .NETにおける末尾最適化の方法についての話 再帰関数のスタックオーバーフローを倒す話 その2.5 継続モナドと、F#の残念さの話 再帰関数のスタックオーバーフローを倒す話 その3 ← 今回 すべてをあきらめて再帰をwhileに書き直す方法の話 はじめに 再帰関数のスタックオーバーフローを倒す話 その2の続きで、最後です。 前回はCPS変換じゃスタックオーバーフローが回避できない場合もあるよという話でした。 前提知識は、F#と、スタックについてです。 これまではCPSの話を中心にしてきましたが、この記事ではCPSの知識とか不要です。 F#で再帰関数によってスタックオーバーフロ
再帰関数のスタックオーバーフローを倒す話 その1 - ぐるぐる～
再帰関数のスタックオーバーフローを倒す話を何回かに分けてします。 連載目次 再帰関数のスタックオーバーフローを倒す話 その1 ← 今回 CPSとCPS変換の話 再帰関数のスタックオーバーフローを倒す話 その1.5 F#での「末尾」についての話 再帰関数のスタックオーバーフローを倒す話 その2 .NETにおける末尾最適化の方法についての話 再帰関数のスタックオーバーフローを倒す話 その2.5 継続モナドと、F#の残念さの話 再帰関数のスタックオーバーフローを倒す話 その3 すべてをあきらめて再帰をwhileに書き直す方法の話 はじめに 継続渡しスタイルもしくは継続渡し形式(Continuation Passing Style、以降CPS)という言葉を聞いたことがあるでしょうか。 今日はCPSの話をします。 前提知識は、F#のみです。 継続とは CPSの前に、まずは継続の話です。 継続と言って
Scalaのnull/Nothing/Nil/Noneはやりすぎなのか？ - ぐるぐる～
Twitterしてたら目に入ったので軽く。 Javaにおけるnull。これまでとこれから この後のスライドで、 Scalaにおける「何もないもの」の分類はやり過ぎ感はある と言われているんですが、ある程度は誤解に基づく意見だよなぁこれは、ということを言っておこうかなと。 Scalaについて 日本では説明が不要なくらいScalaって有名になってると思うんですが一応。 ScalaはJVMの上で動作する、(クラス指向の)オブジェクト指向プログラミングと関数型プログラミングを融合させた言語です。 そして、Scalaのコア機能はどちらかというとオブジェクト指向プログラミング寄りです。 オブジェクト指向プログラミングをベースに、関数型の色々なものを実現している感じです*1。 オブジェクト指向プログラミング的な機能として真っ先に思いつくのは何でしょうか？ 割と上位の方に、「継承」とか「型階層」とか来るん
SCM Boot Camp in Nagoya に行ってきた・・・と見せかけた SML# の多相レコードの話 - ぐるぐる～
SCM Boot Camp については他の型方が書いてくれると思うので、違う話を書きます。 SCM Boot Camp 開始前の雑談や懇親会で話題になった SML# ですが、幸か不幸か .NET 系の言語と勘違いされがちです。 でも SML# の # は、多相レコードを扱う際に出てくる # が元になっています。 ちなみに、.NET Framework は 2000 年リリース、SML# の前身である (でいいのかな？) SML# of Kansai が 1993 年開発と言うことで、なんと .NET よりも歴史があるのです。 で、懇親会で SML# すごいよ、って話をしたら「多相レコード？何それ美味しいの？」って人がほとんどだったので、(ぶっちゃけ自分もそんな理解してないですけど) SML# の多相レコードを紹介してみようかな、と思い、このエントリを書いています。 環境は Windows
TypeProviderについて、勝手に補足 - ぐるぐる～
昨日行われたF# Meetup in TokyoのPart 1で@kos59125さんがTypeProviderに関する素晴らしい発表をしてくれました。 今日の発表資料アップロードしました。 commpass からもアクセス可能です。 http://t.co/XrdiVppTpM #fsugjp— kos59125 (@kos59125) 2014, 8月 3 TypeProviderを作りたい場合に、最初の入り口として素晴らしい発表資料だと思います。 何より、日本語で読めるのがすばらしいですね！ この資料について勝手に補足します。 ProvidedTypes.fsについて ProvidedTypes.fsというのは、TypeProviderを作るうえであると便利なものを提供してくれる素敵なファイルです。 正直、これがない状態でTypeProviderを作るのは至難の業であり、事実上必須の
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
TDD の基礎体力と、TDD に対する想い - ぐるぐる～
TDD Advent Calendar 2011 の 4 日目の参加エントリです。 前半では、TDD を学ぶ前に身に付けておくといいと思う基礎体力について書きました。 後半は、まぁ、その。後悔はしていません。反論ウェルカム、議論しようぜ。 不安をテストに 「レッド - グリーン - リファクタリング」は、TDD の根っこの部分であり、これ自体が「どう TDD をやればいいか」を教えてくれるものではありません。 それに対して、「不安をテストに」というのは、「どう TDD をやればいいか」という指針を与えてくれる言葉です。 この言葉自体は、TDD Boot Camp で自分のものにできました。 不安については、テスト駆動開発入門では (言及されているものの) 自然に組み込まれていて、最初に読んだときには全然気づきませんでした。 しかし、TDDBC で id:t-wada (和田さん) に短くて
詳説コンピュテーション式 - ぐるぐる～
コンピュテーション式とは コンピュテーション式とは、機能を制限したマクロです。 ・・・では投げやりすぎるので、もうちょっとだけ説明を試みると、 「式変形によって言語の用意する構文の意味をカスタマイズできるようにする仕組み」です。 モナド用の構文として紹介されることもありますが、それはコンピュテーション式という仕組みの上でモナドを扱っているだけに過ぎません。 もっとも、コンピュテーション式はモナド用の構文として使うことが一番多いでしょうから、 モナド用の構文と理解しても問題はないでしょう。 また、このような状況を考えると、モナド以外のことにコンピュテーション式を使う場合は、 現状では「これはモナドではありません」という表明をドキュメントなりなんなりでしておくのが無難でしょう。 特に、let!とreturnを提供する場合でコンピュテーション式をモナドではない構文とする場合は、 うるさいくらいそ
.NETの標準ライブラリと仲良くする話 - ぐるぐる～
F# Advent Calendar 2013の9日目の記事です。 昨日の記事は、id:nenono さんの「F# でリフレクション/式木に触れてみる」でした。 リフレクション、扱いにくいですよねぇ・・・ リフレクションといえば、LangExtシリーズの一つとしてReflectionExtなんてのを作っているんですが、 時間がないうえにいろいろ問題もあって滞ってます・・・ さて、今回は.NETの標準ライブラリと仲良くする話(もしくはBasis.Coreの紹介)です。 はじめに F#は.NET Frameworkの資産が使えるため、標準状態で色々なことができます。 これはF#の利点の一つですが、.NET Frameworkは関数型言語のために作られたわけではありません。 そのため、F#から.NET Frameworkの標準ライブラリを使うと、F#の標準ライブラリとは違った使い心地を体験するこ
オーバーロードって素晴らしいですよね！ - ぐるぐる～
オーバーロード いやぁ、オーバーロードって素晴らしいものですよね。 例えばC#でintを取るメソッドと、stringを取る同じ名前のメソッドを書きたくなったとするじゃないですか。 そんな時でも、C#はメソッドのオーバーロードが出来るので、こう書けるわけですよ。 public Hoge Something(int x) { ... } public Hoge Something(string str) { ... } 素敵ですね！ 関数(Funcデリゲート) では、関数を考えてみましょう。 非ジェネリックなメソッドはreadonlyなフィールドとしても定義できますよね。 public static Func<int, Hoge> Something = ... このSomethingは、他のメソッドと同じように呼び出せます。 SomethingがHogeクラスに定義されていたとしたら、 va
そろそろPower Assertについてひとこと言っておくか - ぐるぐる～
タイトルはもちろん釣りで・・・はない！ ちょっと真面目に、Power Assertについて意見を述べたいのです。 そもそもPower Assertって何？ てきとーに説明すると、 普通の比較演算子で普通にassert書けば、失敗時に各部分式の値を表示してくれる ようなものです。 Groovy製のテスティングフレームワークであるSpockがおそらく本家大本です((要出典。こういう系の発想は割と昔からあったし、Spock以前に実装例がありそうな気がする。そもそも、Spockは最初からPower Assert持ってたのかも調べないといけない。ちなみに、式木を弄ってAssertを組み立てる、というものであれば(PowerAssertよりも情報量は少なくなるものだけど)、自分の知る限りだと2009年6月にこんな記事があります。 http://themechanicalbride.blogspot.j
.NET基礎勉強会でラムダ計算の発表をしてきた - ぐるぐる～
もう一か月以上も前の話ですが、.NET基礎勉強会で(型無し)ラムダ計算の話をしてきました。 .NETと言えばF#、F#の基礎と言えばラムダ計算！ですよね！ 発表資料はこちらです。 ラムダでウィザード 滅せよ手続き、とチャーチは言った (※言ってません) from bleis tift 当日は2 + 3が分からないと好評(?)でした。 当時の様子はこんな感じです。 2+3の計算が難しい @ラムダ計算 #dotNetbase 2013-07-20 14:53:47 via Twitter for Android ぶれいすさんが人間簡約器になり下がっている #dotNetBase 2013-07-20 14:55:49 via Janetter for Mac bleis迷子中 #dotnetbase 2013-07-20 14:58:10 via Twitter for Android 人間簡
なごやまつりでF# Type Providerについて(?)話してきた - ぐるぐる～
してきました。 あれだけの人数が集まって、F# 知らない人が全然いないとかすごい勉強会でしたね。 現実(えくせる)と戦う話 from bleis tift Excel方眼紙、どうにかしたいものですね。 今回作った(作りかけ)コードは、GitHubに置いてあります。 ExcelHouganshi.TypeProvider 現実と戦うためのRealWorldsというorganizationを作ったので、「これも入れて！」というのがあれば考えます。 今のところ、みずぴーさんの作ったblockdiagcontrib-excelshapeもRealWorldsでホストしています。 飛ばしたところをちょっと補足つけて説明します。 TypeProviderのつくりかた 37枚目です。 TypeProviderは、 チュートリアル : 型プロバイダーの作成 (F#) をやれば作れるようになります。 このな
NullableとOptionの違い - ぐるぐる～
このエントリの最新版はGithubにあります。 Optionそのものについてのエントリは書く必要ない(世の中に有用なドキュメントが山ほどあるから)かな、 と思っていたのですが、Nullableとの違いについてはそれなりに需要がありそうなので書いておきます。 ちなみに、個人的な嗜好によりOptionを持ち上げ、Nullableを下に扱う感じになっていますが、Nullableも(仕方なく)使うことはあります。 特別な理由がなければNullable使わずにOptionを使う、ということでもありますが、そこは一つよろしくお願いします。 Nullableとは C#ではnullは参照型でしか使えませんでした。 Nullableは、この制限がない(ように見えるよう特別扱いされている)唯一の値型です。 ジェネリック型になっており、任意の値型を扱うことが出来ます。 // Nullable<int>はint?
LangExtでのOptionの設計 - ぐるぐる～
このエントリの最新版はGithubにあります。 Optionの意味を理解していることを前提に、直和型をC#で実現する方法についてを説明し、 LangExtではどういう方針を採用しているのかと、その理由について明らかにします。 バリアント型のC#での設計方針 Optionなどのバリアント型(VBのVariant型のことではありません)をC#で実現する場合、大まかに次の2つの方針があります。 型の階層で表現する タグを判別する値を持つようにする 一つ目の方法は、Option(もしくはMaybe)型の実現方法としてよく使われている方法です。 +-----------+ | Option[T] | +-----------+ △ ｜ +-----＋-----+ | | +---------+ +---------+ | Some[T] | | None[T] | +---------+ +----
C# 使いから見てうらやましい Java8 の default 実装の使い方 - ぐるぐる～
Java8 から追加されるインターフェイスの default 実装ですが、C# の拡張メソッドに似てますよね。 実際、このどちらも「シンインターフェイス」を定義するだけで「リッチインターフェイス」が手に入ります。 しかし、C# の拡張メソッドと Java のインターフェイスの default 実装には、それぞれの利点と欠点があります。 拡張メソッドの利点 拡張メソッドの利点は、インターフェイスの実装者だけでなく、 インターフェイスの使用者に対してもインターフェイスの拡張が開かれている点です。 既存の型ですら、後付けでメソッドを追加することができるということです。 using System; public static class StringExtension { // インターフェイスでなくても、どんな型に対しても拡張可能 public static int ToInt(this str
LangExt2.0 リリースしました - ぐるぐる～
しました。 パッケージ: NuGet Gallery | LangExt 2.0.0.0 コード: LangExt/LangExt · GitHub メジャーバージョンが上がって、1.xとは互換性のないものになっています。 そこらへんについては、「なぜそうしたのか」等をまとめて公開していくつもりです。 で、リリースしておいてなんですが、使用にあたっていくつかの注意点があります。 標準クエリ演算子(SelectとかWhereとか)を捨ててます。ふつうのC#erにはお勧めしません。 Grouping系のメソッドは未実装です。実装できてないものがいっぱいあって、それを使って実装したいのでまだありません。いつか作ります。 Join系のメソッドは未実装です。え、これ、必要・・・？ Lenはおとーふさんの要望により、Lengthになるかもしれません。自分としてはLenで十分だと思うのですが・・・ →
Java 8を関数型っぽく使うためのおまじないをF#でやってみた - ぐるぐる～
Java 8を関数型っぽく使うためのおまじない - きしだのはてな Java 8を関数型っぽく使うためのおまじないをC#でやってみた - ぐるぐる～ Java も C# も大変ですね。 F# さんは、ラムダ式も関数型も最初から使えたので、似たようなことはすでにできます。 上記の記事のパクリなので、上記の記事をまずは読んでから読むことをおすすめします。 関数型(関数を表す型の方) F# では FSharpFunc という型があります。名前空間や型パラメータまで含めると、Microsoft.FSharp.Core.FSharpFunc<'T, 'U> です。 ただ、この型を直接使うことはありませんし、見ることもそうそうないです。 その代わりに、'T -> 'U という表記が使えます。「'T を受け取って 'U を返す関数」と読みます。 ちなみに、型パラメータの最初に「'」が付いているのが割と大
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
