第一回 ゆるふわHaskell入門会に来ています。Hackathonがメインですが、トークもボチボチありますのでメモります。
究極の手続き型言語Haskell / @fumieval さん
- 関数型言語とは
- 関数を自在に操作、組み合わせて記述
- 手続き型とは
- 手続きを自在に組み合わせられる？
- 違う。命令列をプログラムから扱うのは難しい
- Haskellならできる
- 呼び出しが階層になっている
- 関数を呼び出していいても、APIを直接呼び出している
- 移植性が低くなる
- 冗長な書き方になっている
- できることが多いことはデメリット
- Haskellの場合
- 関数呼び出しではなく、「変形」をする
- レイヤ内で異なる抽象度のコードを混ぜられない
- 階層内の依存がない (任意の層に変換できる)
- 手続きをプログラム内で解釈して実行できる
- それができるのは、「モナド」
- 同じ種類のコードを合成できる操作が保証されている
- 6つに分類できる(ブログのエントリ参照)
- 4回くらいモナドについて再発見
- Haskellで作りたいものを作るライブラリ
- Haskellはいかに問題を解くかではなく、いかに武器を作るか
- Q. モナドの6分類の状態と失敗での分類との対応は？
- A. 「内包と継続」が失敗、「出力、環境、状態」が状態
Haskellと抽象化 / @amkkun さん
- Haskellerは抽象化が大好き
- 対象から注目すべき要素を重点的に、他は無視
- 数値と文字を型による抽象化
- 値の判定、比較、足し算引き算
- Eqクラス、Ordクラス、足し算引き算はNumクラス
- 型はまったく異なるが、性質、操作に共通点が多い
- 型クラス
- 他の言語ではあまりない。オブジェクト指向のクラスとは違う
- 他、Monoid, Category, Arrow, Functorなど
- Monadも型クラス
- まとめ → haskellの抽象化は直感的、数学概念を使いやすい、型クラスは他の言語にない
- Q. 数学が苦手なのですが
- A. 数学を知らなくても書ける。Haskellをやると数学の力がつく
- Q. 数学を使わないと解けない問題はなかったけど、具体例を知りたい
- A. シンプルに書ける
- A. 米田の補題でプログラムが高速化したり
- A. 型とプログラムの推論を型で表していると思うと、数学の力で正当性がチェックされる
- A. 先に型を書いて、型にあわせている。先に証明を書いているのと同じ
- Q. 先に型を書いて証明をしている、とは？
- A. ライブラリの型に合わせてコードを書く。先に型がある
- A. 後付で型をつけることもできる
- A. もし数学のことを知っていれば、それを表現できるってだけ。数学を元に設計された良いライブラリを使うことが大事では
Haskellチュートリアル / @its_out_of_tune さん
資料はこちら。チュートリアルなので、概要のみ書いておきます。
- ghciの起動と四則演算、論理演算
- 関数呼び出し、2項演算、セクション
- 型変数、型クラス
- インデント、何を大文字、小文字ではじめるのか
- 束縛変数、ghciでのlet
- 線形リスト。文字列は文字のリスト
- take, drop, sum, product
- 使いたくない関数
- head, tail, !! :: 例外が発生してしまう(部分関数)
- headの代わりにlistToMaybe、tailの代わりにdropが使える
- [1..100], taku, drop, cycle, repeat, リスト内包表記
- タプル、fst、snd, zip
- タプルとリスト内包表記の組み合わせ
- Q. 内包表記で書く順番は？
- A. 先にxを書いて、その後条件を書く
- ghciの:t、:t 1がNumであることについて
- リストとタプル、式の結果の型の確認
- 型クラス → Show, Num, Bounded
- オブジェクト指向のインタフェースに近い
- ghci の :i
- 「Q. instance宣言を出さず、class宣言だけ見れないか」「A. 今のghciの機能にはない」
- Num と型制約、5 :: Int、5 :: Integer
- Show, Read, Num, Integral, Fractional, Eq, Ord, Bounded, Enum
- ヤバい型クラス → Functor, Applicative, Monad, Monoid, Category, Arrow
- Stringは[Char]の別名
- and, or関数
- 多引数関数の型。(&&), (||)
- (+)と(==)の型
- f :: (Num a, Num b) => a -> b -> aという関数について。型bの値は演算ができないので捨てるしかないだろう
- (1 +)の型。カリー化
- :: で型定義を書く。今後は必ず型を書く
- ifよりパターンマッチが簡単。データコンストラクタなら使える。数値ならNum制約が必要
- リスト、タプルのパターンマッチ
- fst, sndの代わりに
- (x:xs)は[]にマッチしないので注意
- Asパターン、ガード
- whereとlet in。let inは局所的に使える
- case文
- 再起処理 → 実は重要でない
- 階乗、階乗リスト、zip関数の再帰による実装
- 再帰の基底部と再帰部
- クイックじゃないクイックソートの実装
- 怖い人「数値を吐くときは、末尾再帰のほうがいい。リストは気にしなくていい」
- 「評価戦略が違うので、普通の末尾最適化が効くのか」「言語仕様では要求してないが、大抵の処理系はやるでしょう」
- 関数も第一級オブジェクト。数学的な意味の関数→高階関数
- カリー化と部分適用の違い
- 部分適用の例。高階関数の定義
- app :: a -> (a -> b) -> b という型を実装してみる例
- セクションの使い方 (: [1,2,3])、λ記法
- 「ここからがHaskellです」
- curryとuncurryの実装。(ただし、標準関数にある)
- flip、zipWithを型から実装を考えてみる
- map, foldl, foldr
- ($)、(.)の使い方
- ポイントフリースタイルとはなんぞや
参照透明な海を守る会 / @masterq_teokureさん
同人誌売るので、会社休んで買いに来てください！ 著者も募集中。
LT
ゆるふわなHaskell話 / @ruiccさん
- Haskellは簡単にIO実行ができない
- IOはプログラムから制御できないもの
- 現在時刻を得る関数は、制御不可能
- テストが辛い、再利用が辛い、保守が辛い
- Ruby なら Open classで
- 開発環境の時間を変えては？ → 言語の外の部分
- 人間が何かをしなければならない。保守対処が増える
- 外部でIOを実施し、引数で渡せば良い
- 引数の引渡しの問題 → 他の諸問題よりマシでしょう
- よって、IOは隔離すべき
- IOを考えることは設計行為
- 引数引き回しがダサいという風潮？
- ダサいって話より、問題を解くべきじゃ
- Readerモナドを使えば解決できるけど
- IOと切り離せない問題もある
- Graphics, Sound, GUI
- IOを直書きすると、どこで発生するかわからなくなる
- dirtyDeedsDoneDirtCheap : D4C
- いともたやすく行われるえげつない行為
- モナド変換子もliftIOがあるので一緒
- Symantics → 特定のアクションを束ねたもの http://mizondev.net/d/20130420
- Free Monadを使う → 制限されたIOとして使うと、安全(ゆるふわ)
- IOを制限できる言語 → Haskell, Agda, Idris (つまりHaskell)
- HaksellがIOを扱いにくいのではなく、他の言語がIOをまともに使えない
- IOモナドは悪か → IOモナドでがりがり書いても、OCamlなどと同じ安全性
Haskellを仕事でゆるふわに使ってみた / @seizansさん
懇親会
ピザ屋にお金を払うために数分間待機のようです。
