初フィルム
厳密にいうと小学校の旅行などで「写ルンです」を使ったりしたことがあるので、初フィルムじゃないんだけど自分で装填するものとしては初ということで。
中野のコイデカメラで自分でプラモデルのように組み立てるカメラを見つけて「なんだこれは!?」と調べていたら Lomography にあてられてどうしても自分でも撮りたくなって中古の Lomography Diana Mini を買った。
それで2本撮ったので現像・スキャンしてもらってきた。(本当はもう1本もあったんだけどダメにした。)
70枚撮った中で奇跡的に手ぶれもなくピントも合っている1枚。
鏡筒の向かって左のレバーがシャッターボタンなんだけどこれがまたぶれやすいのなんの。
いじれるのは、絞りが F8 もしくは F11、シャッター速度が 1/60 もしくはバルブ。写ルンですのような2眼でピントは目測で 0.6m からで 4m 以降は無限遠までパンフォーカス。
フィルムは富士フィルム Superia X-Tra 400 と、Superia Premium 400。日中は ISO 100 でもよかったように思う。
Windows で haskell-ide-engine をビルドする
手順
1. ソースコード取得。
git clone git@github.com:haskell/haskell-ide-engine.git
2. Unicode を扱う ICU の古いバージョンが要るので取得。
自分の使うバージョンの text-icu の changelog を見て、必要な ICU のバージョンを探す。執筆時点では 53 だった。
http://site.icu-project.org/download/53#TOC-ICU4C-Download
任意の場所に展開する。以降、展開先の箇所を $icu と表記する。
$icu\bin64 にある dll の名前を変える。(要らないかもしれない。) 管理者権限の cmd で下記を実行する。
mklink icuuc.dll icuuc53.dll
他の dll も同様に。
うまくバージョンが一致したとき
うまくバージョンが一致したときは上記のかわりに下記でもインストールできる。
stack exec -- pacman -S mingw64/mingw-w64-x86_64-icu
このときはビルド時に --extra-include-dirs
と --extra-lib-dirs
の指定が要らない。
3. ビルド
対象とする GHC のバージョンごとに stack.yaml があるのでバージョンを指定する。(8.0.2 は hie-0.1.0.0 ブランチにある。)オプションで ICU の場所を指定してやる。
stack --stack-yaml=stack-8.0.2.yaml --extra-include-dirs="$icu\include" --extra-lib-dirs="$icu\bin64" install
複数バージョンの GHC に対応できるように、stack path --local-bin
が示すパスに生成された実行ファイルの名前を変える。Makefile を見ればどう変えるか書いてある。
copy hie hie-8.0.2 copy hie hie-8.0
4. dll にパスを通す
実行時に参照する必要があるので $icu\bin64 と stack path --extra-library-dirs
の示すパスの bin ディレクトリーの方にパスを通す。(PATH 環境変数に追加する。)
退職
2013年に新卒で入社した KLab を今日付けで退職しました。
技術書典 4 にサークル参加した
4月22日に開催された『技術書典 4』にサークル参加してきました。
技術書典は1と2に個人で参加して3は会社として参加して今回の4は会社と個人と2サークルにかかわっていました。
超技術書典を抜くと皆勤です。
個人サークル
既刊として『遠回りして学ぶ Yesod 入門』を増刷し、新刊は『手続き Haskell』を持っていきました。
数字
売り上げ部数は、どんぶり勘定ですが(特に Yesod 本のダウンロードカードが完全に記憶による)下記の通りとなりました。
- Yesod 本
- 紙 + PDF
- 30
- PDF
- 4
- 紙 + PDF
- 手続き Haskell
- 紙 + PDF
- 60
- PDF
- 9
- 紙 + PDF
60部は次回イベント頒布も込みでの印刷のつもりでしたが、技術書典自体の来場者が倍になったことで全部捌けてしまいました。
両方とも紙の本はイベント終了の1時間半前から1時間前ぐらいに完売し、あと5冊ずつぐらいあればちょうどよかったかなという感じでした。
どちらも紙 + PDF が1000円、PDF のみが800円でした。正直『手続き Haskell』は30ページないのでちょっと高いかなと思いつつ会計の簡潔さのために切り上げました。値段で買うか悩む人がいなかったわけではないですが、ほとんどの人は、前から思っていましたが、買うか決めた後に値段の確認をするようです。
ただいまを持ちまして、 #技術書典4 閉幕しました!今回の総参加者数は6380人でした。
— 技術書典公式アカウント (@techbookfest) 2018年4月22日
皆さんご来場ありがとうございました。
あと、16時ぐらいまで入場規制がかかっていたせいでポツポツと最後まで買ってくれる人がいて、それは嬉しいんですが、それに加えて会場の混みぐあいとで自分が買いに回ることが全然できませんでした。次も晴れたら、自分と売り子、買い出しの3人で回そう……
支払い方法は下記の通りです。
- 現金
- 多数
- かんたん後払い
- 6
- Square(クレジットカード)
- 0
Square 決済、実は1度もしたことがないので待ってます。(技術書典2のときに1度チャレンジしてくれた人がいたんですがうまく読めなかったことはあります。)
書籍について
新刊の『手続き Haskell』についてブログで説明していなかったのでしておきます。
ちなみに Yesod 本は表紙にポリプロピレンが貼られちょっとだけ品質アップしています。
手続き Haskell
タイトルでネタ本と思われることがあったのですが、大まじめに書いています。
ネタだと思われるという状況を変えないといけないと思っていて、というのも Haskell で手続きを書くのは全くめずらしいものではないです。なぜならそのためにモナド用の do 構文をサポートしているのですから。
世間では Haskell は関数プログラミングをしないといけないという強迫観念のようなものが強いと思います。
Haskell では普通に手続きが書けるのだということが伝われた執筆したカイがあったというものです。
本書にはもう1つ執筆の理由があって、それは入門者によくある「読めるけど書けない」問題の解消です。
入門書を読んで書いてあることは分かるけど Haskell で書こうとすると書けないということが多いように思います。それは、元々手続きプログラミングをやっている人の場合、まず頭に思い浮かぶアルゴリズムが手続き的だからです。なので、それをそのまま Haskell で書けるノウハウを提示したつもりです。
また、Haskell の文法は C 族の言語や Python・Ruby などとはかなり異なります。その上、関数プログラミングをするとなると、入門者は二重に壁があることになります。そこで、関数プログラミングを後回しにすることで、文法を身につけることが容易にすることも狙いです。
とはいえ Haskell らしいソースコードがあるにはあるので最後の章で、両方の書き方を対比しています。
本文中に書き忘れたのですがソースコードは GitHub で公開していますので実際に動かしてみたい方はクローンしていじってみてください。
執筆
今回に合わせて同人活動をまとめたサイトを GitHub Pages で作ったのですが、せっかく Haskell のサークルなので Hakyll を使うように書き換えようと思ったのが時間が溶ける原因でした。
まずテンプレートエンジンが気に入らなく Jekyll と同じ Liquid を使おうとしたら、ライブラリーが完全でなく、まずそれの自作から始めてしまい、まさにヤクの毛刈りですね。
さすがにこのままだと執筆時間がなくなってしまうと、1ヶ月ほど前から執筆を始めました。
時間がすでになくなっているのに、執筆を始めると想定より内容が膨らみ始め、当初は Haskell の文法も解説するつもりでしたが、入門書の副読書と目標を変えることで、なんとか収まりのよい形になったのはよかったと思います。
ただそれでも自己レビューが不十分だなと刷り上がった本を読んで思えたのは反省点です。
執筆で今回よかったのはプリンターを買ったことでした。人にもよるでしょうが、自分の場合は自己レビューする場合、紙で赤ペンを入れていかないとまちがいが見つけられません。これまでは外で刷っていたのですがもう今回思い切ってプリンターを買いました。
プリンターの知識が10年ほど止まっていたので知らなかったのですが、今時はロースペック機以外はスキャナーが付くのですね。
そこでせっかくなので今回の表紙は手書き文字を取り込んでみました。それに合わせて表紙用紙を軽く波打った紙にしてみたのですが、これはよかったと思います。手書き文字とよくマッチしています。
オンライン販売
これまで通り BOOTH でオンライン販売しておりますのでよろしくお願いします。
追記(2018.09.12):『遠回りして学ぶ Yesod 入門』は商業化しましたのでそちらでお買い求めください。詳細はこちら。
会社サークル
会社としては技術書典 3 からの2回目のサークル参加となります。
今回は個人サークルもあるので、会社の方は編集に専念しました。
前回は完全に有志でプライベートや10%プロジェクト時間にやっていたのですが、イベントの後に人事部の方からアプローチがあり、今回は業務として執筆できるようになりました。ありがたい。
また今回は表紙・ダウンロードカードを社内の絵描きの人たちに描いてもらいました。前回はクールな感じにしあがったのですが今回はキュートになりました。大きいポスターも作りました。ポスターがあると大手壁サークル感がありますね。
その他の詳細は会社ブログで公開予定ですのでもうしばらくお待ちください。
技術書典 5
次回がどうなるのか分かりませんが、『俺々言語にだって型推論が欲しい!』という題で書いてみようかなぁと思っています。(大いに変わる可能性がある。)
弊同人サークルのウェブサイトを作りました
なぜ Haskell が好きなのか
自分は Haskell が好きで休日は Haskell を書いています。そういうことを言うと関数型が好きなんですねと言われるのですが、Haskell のよさはそこじゃないと感じているので書き起こそうかと、筆を執りました。
というわけで、この記事は技術的文書というよりもお話です。Haskell を知らない人向けです。
この記事は Haskell Advent Calendar 2017 その3の6日めの記事です。6日が過ぎても担当のいない日だったため担当します。
関数型プログラミングだから Haskell が好きというわけではない
まず、「Haskell というと手続き型とは全然違う関数型なんでしょう?」という印象を持つかと思いますが、一部合っていて一部まちがっていると思っています。
まず、用語の意味を絞っておかないと議論が発散してしまうのでそうしておきます。
ここでは「手続き型」は、先に書いた処理が後に書いた処理に影響を与えるようなプログラムを指すものとします(先や後は、ファイルの先頭に近い方が先、反対が後とします)。C・C++・Ruby などなどよくあるプログラミング言語です。
ここでは「関数型」は、関数がファーストクラスであることが最低条件とします。つまり、Func<T, …, T>
のインスタンスがある C# は満たしていますし、JavaScript や PHP もそうです。あくまで最低条件で実際にはそれらを活用したライブラリーがないと強くはそう言わないと思います。
さて、これら用語でいうと Haskell は「関数型」ですし、ライブラリーのサポートもあるので強くそうです。では、「手続き型」かというと意外に思うかもしれませんが、手軽に手続きも書けます。Web アプリケーションプログラミングなどではバリバリ手続きを書きます。
なので最初の「Haskell というと手続き型とは全然違う関数型なんでしょう?」に対する答としては「Haskell は手続き型であるし、関数型でもあり、それらは全然違うわけではない。」となります。
データの設計がしやすい
Haskell では「代数的データ型」(algebraic data type)を採用しています。代数的データ型は以降 ADT と表記します。代数的データ型は、直和と直積を持つ系です。(Haxe・Rust・Scala・Kotlin・Swift なども有していると聞いています。)
まず、直積について見ていきます。例えば、よくある例で Person
という型があって name
と age
というフィールドがあるとすると、それは Haskell では次のように記述できます。
data Person = Person { name :: String , age :: Int }
値を作るときは次のようになります。
me = Person { name = "Kazuki Okamoto", age = 28 }
次は直和についてです。先の Parson
の例の続きで、実は乗客として人を扱うために Parson
を作ったとしましょう。さて、乗客からの要望により新たにペットも乗せられるようになりました。「乗客」型は、値として「人」もしくは「動物」ということになります。これを Haskell で記述すると次のように記述します。
data Passenger = Person { name :: String , age :: Int } | Animal { species :: String , name :: String }
値を作るときは次のようになります。
me = Person { name = "Kazuki Okamoto", age = 28 } pet = Animal { species = "dog", name = "Max" }
同等のことを C# や Java などでやろうとすると、インタフェース1つとクラスが2つ必要になります。別の相違点として、直和型の場合は乗客は人もしくは動物のみであることは定義から分かりますが、継承でシミュレートした場合はプログラム全体を検索しないと他の種の乗客があるかどうか分かりません。反対に、継承を使った場合は元のコードに手を加えずに拡張ができるということがいえます。
型の定義部でしか値の種類の追加ができないことは、パターンマッチにおいて網羅性チェックができるという利点があります。
case me of Person n a -> {- 何らかの処理 -} Animal s n -> {- 何らかの処理 -} -- 例えば 上記の Animal のパターンがなければ次のような警告が出ます -- warning: [-Wincomplete-patterns] -- Pattern match(es) are non-exhaustive -- In a case alternative: Patterns not matched: Animal
Haskell における手続き
手続きを使ったプログラミングの例として、西暦を入力すると平成何年かを出力するようにしましょう。
import System.IO (hFlush, stdout) main :: IO () main = do putStr "Christian Era: " hFlush stdout christianEra <- readLn :: IO Int let heiseiEra = christianEra - 1988 putStr "Heisei Era: " putStrLn (show heiseiEra)
実行すると次のようになります。
λ stack runghc .\heisei.hs Christian Era: 2017 Heisei Era: 29
C 系との違いとしては、関数呼び出し(関数適用)が括弧なしに関数と引数を並べる点、変数への代入(変数の束縛)が … <- …
と let … = …
の2種類を使い分ける点があり、それを除けば雰囲気で読めるのではないかと思います。
先の例では main
の定義の先頭に do
キーワードが使われていますが、Haskell では do
キーワードを使えば、その式を手続きで書けるようになります。
詳細は省きますが for_
関数を使えばループを書けますし、IORef
などを使えば再代入(再束縛)可能な変数も作れます。
副作用の明示
Haskell で手続きが難なく書けることは示しましたが、ここで Haskell でいいことがあります。それは副作用の種類が型に明示されるということです。
先の例の main
は IO ()
という型になっています。これは IO を副作用として持つことを意味します。他には、Reader r a
というものは、読み取り専用の大域変数(型は r
)があることを意味します。ST s a
は読み書きのできる大域変数があることを意味します。もちろん大域とはいいつつプログラム全体ではなく副作用は局所化されます。(なんか矛盾してるようですけど局所的に大域的なのです。)などなど、アプリ固有の副作用を示す型を作ることもできます。
IO
の手続きの中から IO
の手続きは呼べますし副作用のない関数も呼べますが、反対に副作用のない関数の中から IO
の手続きは呼べません。呼べてしまうと関数に副作用ができてしまうので当然ですね。ST
も ST
の手続きの中から ST
の手続きと副作用のない関数が呼べます。副作用のない関数の中からは ST
の手続きを「実行」することができます。副作用は ST
の中にのみ影響するので ST
全体を実行することには副作用がありません。ST
の中に局所化される副作用しか ST
の中には書けないので入出力などは ST
の中に書けません。
これは、プログラムのまちがいが起こりにくいのは当然、他人のプログラムを読むときも大変有用です。C# や Java などのオブジェクト指向では手続きのカプセル化には成功しましたが、副作用の有無についても隠蔽してしまいました。
せめて pure
修飾子などがあるとよいですね。一番近いのは IntelliJ IDEA で Java を書いたときに付けられる @Contract(pure = true)
ですかね。
まとめ
以上、なぜ自分が Haskell が好きなのかというと次が主要な理由です。
- 代数的データ型、特に直和型があることはモデルの設計が簡単になる
- Haskell で手続きは書きやすいし、実際よく書く
- 副作用が明示されることは、コードのまちがいが減るし、読みやすい