haskell-jp / code-review #2

@highmt has joined the channel

@iruyan_zak has joined the channel

@cdepillabout has joined the channel

@krdlab has joined the channel

@siosio has joined the channel

@fujiyan18 has joined the channel

@maru10tgg has joined the channel

@hrkr has joined the channel

@wat-aro has joined the channel

@n4to4k has joined the channel

@yoshikunijujo has joined the channel

@falsandtru has joined the channel

@hiratara has joined the channel

@tomohiko.okazaki has joined the channel

@masakolee has joined the channel

@yokomotod has joined the channel

@tukejonny has joined the channel

@ice08235523 has joined the channel

@h_hosokawa has joined the channel

@nobuteru.kawano has joined the channel

@h_hosokawa has left the channel

@voqn.tyrant has joined the channel

@kakkun61 has joined the channel

@fujimura has joined the channel

コード晒してよかですか

https://github.com/VoQn/cacco/blob/master/src/Cacco/Lexer.hs
趣味で言語作ってるんだけど、「not haskeller の人が見ても分かるように」っていう意識で書いている

（ウォッチャーがLisperとOcamlerだからっていう理由で）

こういうの便利そう
https://github.com/VoQn/cacco/blob/master/doc/basics.asciidoc#strict-type-literals

モチベの拠り所がユーザーフレンドリーなリテラル持ってる言語を、っていう感じなので

https://github.com/VoQn/cacco/commit/0cb416ca3ea05fe8f8ef746908d61d8f35c059a3
10進数の浮動小数点リテラルのstrict-type-literal 対応した

IEEE 754-2008 binary16 (16bit float) にプリミティブで対応しているのは、遠い目標にwasm経由して直にWebGLのシェーダーにアクセスする為とかですね

枝葉末節なんですが、綴りにいくつか誤りを見つけたのでプルリクを投げました

"block comment is keeping" では意味が通らない、などもありますが、眠いので寝て起きてからにします

typo周りは指摘まじありがたいです！英語力もアレなので 圧倒的感謝

ちなみに、stack.yaml で tasty-1.0 を指定してるんですけど、その前となんか大きく変わったんですか？

@syocy has joined the channel

stack-work に残ってキャッシュが相当古くて、tasty-discover の CLI option の --tree-display を受け付けなかったんですよね。また、0.1x 系から 1.0 系になったという事で、できればメジャーバージョンに上げとこうっていうぐらいでした。

@shin16s has joined the channel

@info has joined the channel

結論としては，(まだちょっと把握できてない部分もあるんですが)見た感じCofree annotationを使う意義は無さそうと言う感じです
https://haskell-jp.slack.com/archives/C4M4TT8JJ/p1519027141000214?thread_ts=1518659662.000031&cid=C4M4TT8JJ

いろいろ説明不足ですみません。
このコード（今型検査にこけるんですが）は、Liquid 用の AST を実行するもので、Jekyll で採用されてたりするんですが、Jekyll 方言があってそれをベース方言のインタープリターをいじらずに拡張できるようにしたいというものです。
で、そのベース方言部分です。

まず，cofree annotationを使う動機から説明すると，構文木を扱う際各木に注釈情報を埋め込みたい時があって(例えば，パース時のソースコード上の位置や，型情報など)，このような情報はコンパイル時どんどん変遷していくため，決めうちじゃなくて何らかの型変数にしておきたいということがあります．

ただ，これを単純に実現すると，
data Expr a = Val Int a | Add (Expr a) (Expr a) a
というように注釈情報を埋め込みたい場所に一々型変数を書かなければいけません．これを何とかしたいというのが動機です

data types a la carteもcofree annotationもデータ型をopenにするという方向では一緒なのですが，それぞれ方向性はdata types a la carteはsumに対してのopen性，cofree annotationはrecursion schemeに関してのopen性みたいな感じで異なるのでそこらへんは注意です(まあ結果的に，これらを併用することが可能なのですが)

で，実際にどのようにcofree annotationが解決するかなのですが，ASTを以下のようにrecursion schemeのBaseで定義しておきます．
data ExprF e = ValF Int | AddF e e
(ここでeは元のaと関係なく，再帰する箇所を表します．まあこの辺はdata types a la carteと一緒で，それが併用できる所以なんですが)

で，通常はこれをFix f = f (Fix f)という原始的なオペレータでfixするんですが，Cofree f a = (a, f (Cofree f a))というオペレータでfixすることで，再帰する箇所全てに後から任意の注釈を埋め込めるようにできるというのがcofree annotatingと言われる手法ですね

ただこのcofree annotatingは，multipleなデータに対して弱くって， https://stackoverflow.com/questions/38462563/how-to-work-with-ast-with-cofree-annotation とか @voqn.tyrant さんが使っていたIndexed functorでそれをうまく扱えるようにするというのが度々話題に上がっています

今回の場合，特に注釈情報は必要なさそうに見えるので(?)，cofreeを導入する必要はなさそうに見えます

(ところで，僕もあまり詳しく無いのですが，Data types a la carteの結構すぐにoverlappingする問題って，みんなどうやって解決してるんですかね？)

あ，あとこれって，その他(cofree使うか以外で)の感想待ちだったりしますか？

cofree については全然知らなくって、「なんか VoQn さんのコードと似てる気がするけど知らない内に cofree 使ってるんだろうか？」という感じで提出したコードでした
まさに

まあこの辺はdata types a la carteと一緒で，それが併用できる所以なんですが

というところで同じなのかなぁと勘違いしたようです
ただ cofree は好奇心を覚えるので説明は咀嚼してみます