haskell-jp / code-review #3

VoQnさんので言うと, https://github.com/VoQn/cacco/blob/master/src/Cacco/Ann.hs#L21 がまさにCofreeですね.(Indexed Fixはまだ導入してなさそう?)
Ix* はまだ組み入れてないですね。ラムダ式や関数宣言とかの、AST内部の小分類が必要になってきたら組み込んでく予定です
@takohati0821 has joined the channel
あれは閉じた型族などがなかった時代の苦肉の策なので、今では型レベルリストと型族を活用すれば簡単に実現できます。 extensibleも型族を使っています http://hackage.haskell.org/package/extensible-0.4.7.1/docs/Data-Extensible-Sum.html
型レベルリストってopen unionとかと同じように,sumするやつをリストに突っ込んでおいて,injectする時型レベルのmemberをするやつですか?あんまりよく知らないんですけど,それってかなりコンパイル時間がかかったり,型エラーがえぐくなったりしないですか?
実装が悪いとそうなりますが、extensibleは速いという評判を頂いています。ただ要素数が200くらいになってくるとコンパイルが遅くなる感じがあります。
なるほど,実装見てみます.ありがとうございます.
https://github.com/VoQn/cacco/blob/master/src/Cacco/Syntax/Parser/AST.hs
IxFIx を導入したASTのパーサが一応できました(IxCofree をインジェクションするのはまだ出来ていないので、純粋な構文木をパースするようになっています)
できた
haskellの好きなところ、書き終わった後に「ぜってぇこれもっといいやり方がある」ってモチベ上がるところですね
これって,気になったとこ言っていい系なんでしょうか?
まぁ、 code-review に貼ったぐらいなので何かアドバイスなり意見が欲しいので大丈夫です
ここが(おそらくnat transのtype sigを適用できるようにするためだと思うんですが)f i aの順になっていないために,ixを固定した時に既存のFunctorのAPIを使えないのは残念だなと思いました
https://github.com/VoQn/cacco/blob/master/src/Data/IxFix.hs#L76
後,個人的には UndecidableInstances は避けてる人なので,ちょっと余計なインスタンス宣言が増えますが, deriving (Show (f (Fix f)) => ... の部分は deriving (Show1 f) => ... で書く派なので,そこの部分も気になりました
そうなんですよ。普通のfmapが上手に利用できないというか、評価器を作るところで通常のdoなども利用できないので作りを見直して克服したいところなんです
あ、いや、たしかに逆にするだけで何とかなる?
"indexed" なんだから、型の表記的にも i f と続かせる方が正しいような気もしますね
多分逆にして, deriving Functor すればいい気がしますね
後,結構不要なところに UndecidableInstances が入ってる印象があるので,もし拡張のプラグマをコピペしてる感じだったらむしろ,cabalのdefault-extensionsを使って,モジュール別に必要な拡張だけモジュールごとに指定するのがいいかもしれません()
これも好みの問題かもですが,
* -> `Data.Proxy.Proxy`
* -> `Data.Functor.Const`
* -> `Data.Functor.Identity`
* -> `DeriveTraversable` で代用可能
みたいなのを思いました
それから,一部メッセージを良くunwordsして作ってる印象があったので,
*
*
みたいなのと相性が良さそうな気がしました.
それから, の部分は, GADTsScopedTypeVariables 拡張を加えて,
astFix :: forall t (i :: AstIx). IxFunctor t => AstIxProxy i -> AstIxFixParser t i
astFix proxy d e p t = case proxy of
    DeclProxy -> d'
    ExprProxy -> e'
    PattProxy -> p'
    TypeProxy -> t'
  where
    astFix' :: (forall f. AstIxParser t f j) -> Parser (IxFix t j)
    astFix' f = In <$> f d' e' p' t'

    d' = astFix' d
    e' = astFix' e
    p' = astFix' p
    t' = astFix' t
{-# INLINEABLE astFix #-}

located :: forall f (i :: AstIx). AstIxParser AstF f i -> AstIxParser (IxAnnF Location AstF) f i
located f d e p t = IxAnnF <$> withLocation (f d e p t)
{-# INLINE located #-}

astParser :: AstIxProxy i -> Parser (IxAnn Location AstF i)
astParser proxy = astFix proxy
  (located declAstF) (located exprAstF) (located pattAstF) (located typeAstF)

declAst :: Parser (IxAnn Location AstF AstDecl)
declAst = astParser DeclProxy
{-# INLINEABLE declAst #-}

exprAst :: Parser (IxAnn Location AstF AstExpr)
exprAst = astParser ExprProxy
{-# INLINEABLE exprAst #-}

pattAst :: Parser (IxAnn Location AstF AstPatt)
pattAst = astParser PattProxy
{-# INLINEABLE pattAst #-}

typeAst :: Parser (IxAnn Location AstF AstType)
typeAst = astParser TypeProxy
{-# INLINEABLE typeAst #-}

の感じで書くと,ボイラープレートが増えなくて良いかな?と思いました
Show1使ったことありませんでした… せっかくtransformers使ってんのに…
あ、今はbaseに入ったのか…
はい,baseにあるので気兼ねなく使えますね.GHC 8からいつのまにか,MonadIOとかも入ってました
https://hackage.haskell.org/package/base-4.9.1.0/docs/Control-Monad-IO-Class.html
書いてる途中でコンパイル一時的に通す為に入れたGHC拡張が残ったままになってたりするのか
UndecidableInstances は意識的に入れたつもり無くて、StandaloneDerivingが使いたかっただけ、というパターンとかあります
せっかくProxyを作ったんだからそれを利用すればよかったんだなぁ
@falsandtru has left the channel
@satopen1729 has joined the channel
やっとcompdataとData Types a la carte まで学習が進みました。 http://hackage.haskell.org/package/compdata
compdata ほう こんなものが
http://www.timphilipwilliams.com/posts/2013-01-16-fixing-gadts.html
ここで解説されている「任意のデータ型をFunctorからもう一段階高階の抽象化をして、『Int型しか受け付けない(あるいは評価結果がそうなる)構文』とかをできるようにする」手法が別のワークショップでそのまま実装されていたっていうオチ
ちょうど今 Data Types a la carte ベースでテンプレートエンジン作ってるから気になる
後で見よう
@ywataywatay has joined the channel
@mizunashi-mana さんに指摘された Cofree annotation 、本当に IndexedCofree f a i っていう型を作って出来るか試してみたら出来ました
これだけでもこのチャンネル入って本当に良かった。ありがとうございます
@mizunashi-mana has left the channel
@mizunashi-mana has joined the channel
@shunsuke.masuda has joined the channel
@andes has joined the channel
@shohei.takaichi has joined the channel
@nrskt has joined the channel
@klonoa has joined the channel
すごく簡素なプログラムですが、haskellで書きました。
もしかしたらリリースされるかもしれません。(まだプロトタイプです)
プログラムの目的、利用方法に関してはreadmeを読んでください。
https://github.com/input-output-hk/cardano-diagnosis-program

気になってる点:
1. どのようなテストを行えばいいのかわかりません。(ダミーファイルを作ってそれをパースするとか?)
2. ログを解析する部分(`Classifier.hs`)が総当りに近いです(`isInfixOf` を使って特定の文字をキャッチしています。)本当はregexやパーサーライブラリを使って解析したいのですが、1日かけても全く動きませんでした。これに関してなにか具体例みたいなものがあれば是非紹介して頂きたいです。。
3. LogExtractor(ログファイルの有無を確認し、ある場合には読み込む)に関してOSごとにFilePathを指定する部分が若干不安です(とくにユーザー名に半角英数字以外を使用しているユーザーに対して動作するのか)

その他気づいた点がありましたらお願いします。
ログファイルのサンプルあったほうがいいですよね。夜にアップロードします。
ちょっと覗いた程度ですが,1点だけ気になりました.
https://github.com/input-output-hk/cardano-diagnosis-program/blob/master/app/Main.hs#L38
の部分ですが,こういう場合throwIOを使われるのが好まれると思います.
https://mail.haskell.org/pipermail/libraries/2012-September/018410.html のスレッドが参考になると思うのでどうぞ
ありがとうございます。その点に関しては僕も気になっていたのでさっそく取り組んでみます。
@hiroto.shioi uploaded a file: pub.zip and commented: ログファイルのサンプル
あんまりよく読んでないので心証的な感じで申し訳ないんですが
解析のパフォーマンスについては,どれぐらいの規模なのかよく分からないですが,複数ファイルを1回読み込んでしまうとメモリをかなり食ってGCの回数が増えるとかがあるのではないでしょうか?テストより先にプロファイリング用に余計な処理を省いたベンチマークを作ってみるのがいい気がしました