haskell-jp / questions #83

@dex10619 has joined the channel
@akkey52417 has joined the channel
@tamba8525 has joined the channel
[yesodweb/serversession: Secure, modular server-side sessions.]()
が少し新しいLTSだとpersistentの破壊的変更でビルドできなくなってるのを直してるんですが,
もうこれは古いぞみたいなことになってたりしますかね…?
それはそうとしてacid-stateがバージョン1を出してくれてないので破壊的変更が何処にあるのかわからなくて非常につらい
とりあえずテストは通しました
[updated: lts to 15 by ncaq · Pull Request #23 · yesodweb/serversession]()
@soumunote has joined the channel
Hackage は semantic versioning じゃなくて PVP なので(メンテナーがちゃんとしたがってるなら)0.x.y でも x が上がれば破壊的変更があるはずですが、メンテナーしだいですね……
@nagata.hbdc has joined the channel
data Term = V Char
            | Abs (Term, Term)
            | App (Term, Term)
--replaceは
replace :: Term -> Term -> Term -> Term 
replace (V x) s r =
    case r of 
            (V y) -> if x == y then s else (V y)
            Abs((V y), t) -> 
                Abs(V y, (replace (V x) s t))
            App(Abs(V y,t),u) -> 
                App(Abs((V y),(replace (V x) s t)), replace (V x) s u)

このようなコードを書いたのですがreplace((V x) s t)のところでParse errorが出てしまいます。なぜこのようなエラーが出てしまうのかわかりません。よろしくお願いします。
挙げていただいた部分をコピペしただけだと問題のエラーは再現できませんね...
これより前の箇所でカッコの対応がとれてないとか、別の箇所で問題が起きているのかも知れません。
もとのコードに戻って再度コンパイルしたところなぜかエラーは出ませんでした。こちらに質問させていただく前にTerm型の値コンストラクタの名前を短いものに変えただけなのですが…。
:confused: なるほど。。。間違えて古いコードをコンパイルしようとしてしまっていたとか、その辺のありがちなミスかも知れませんね。。。 :disappointed:
それかもしれないです。今名前を元に戻してもコンパイルはうまく行ったので。答えていただきありがとうございました。
@rydeen2045 has joined the channel
@yt1997kt has joined the channel
@masahito.keio has joined the channel
@pometarou93 has joined the channel
@sennenn9 has joined the channel
雑談程度ですが、rust コンパイラはghcより高速ですか、それとも同程度でしょうか?
なにかベンチマークはありますか?
ベンチマークではなく個人的なイメージではGHCの方が並列ビルド時のsystem CPU時間もメモリ使用量も多い印象です。もちろん入力となるコードによりますが。言語の表現力や担保する安全性の範囲にも違いがあるので、意味のあるベンチマークを作るのが難しそうですね。
コンパイルタイムならC++、Rust、Haskellが激遅3兄弟なのであんまり気にしないのが吉です。ランタイムはHaskellは遅いんですがC++とRustのどっちが遅いのかについては諸説あるので気にしないのが吉です。
@ohsofty has joined the channel
はじめまして、質問があります!

toInts :: String -> [Int]
toInts = map read . lines

の意味するところが不明です。

linesは改行文字で文字列を区切り、文字列のリストを返す
(lines :: String -> [String])

それと、readを関数合成すると何ができるのでしょうか
こんにちは。
toIntsの優先度をカッコで明確化すると、 map (read . lines) ではなく、 (map read) . lines となります。
なので関数合成しているのは、`map read` と lines になります。
従ってtoIntsは、「 lines の出力結果を、 map read に入力する関数」を表しています。
map read は、入力されたリストの各々に、`read` 関数を適用したリストを返します。
Prelude 代替を何か試してみようかと思っているのですが、RIO が最有力でしょうか? stack の templates に Foundations もあったのでこちらも気になっています。
あんまりalt Preludeはほぼ使ったことがないですがRIOだけはちょっと使ったことがあって、確かにあれはよくできてると思います。
Foundationsは、わざわざStringなどを独自に作っていて、気持ちはわかるけどちょっと野心的すぎない?という印象です。
RIO 愛用してますが、ほかと比べたわけじゃなくなんとなくで使ってます(とくに不満はありません)
ありがとうございます! RIO を試してみようと思います
ありがとうございます。
一般にはrustのコンパイル時間も遅いという認識なのですね。ghcがメモリを使うというのは経験的にありますが。
@tomoya0229 has joined the channel
よく分かりましたありがとうございます
cabal (3.2.0.0) でプロジェクトをビルドする際に、 -threaded-eventlog などのghcオプションをコマンドラインから与える方法はありますでしょうか?やはり.cabalファイルに書き込むべきですかね?
バイナリデータの操作で、グリッチアート生成プログラムを書籍を元に作っていますが、エラーが取れない状況です。

エラー箇所の解決方法を教えてもらえないでしょうか
https://ideone.com/3cgTKo
--PROG-options=OPTS give extra options to PROG とhelpにあったのでghcなら--ghc-optionsになりそうですね
(before,rest) = ... の行と after = ... の行、 newChar = ... の行の行頭をそろえてください。
コンパイルできましたありがとうございます
@yutakatay has joined the channel
以下のような型クラスを含むライブラリってありますか?

class Writable a where
  write :: Handle -> a -> IO ()

また、このような型クラスを使うのは設計としてどうですか?
cerealを採用しない理由はどういうものですか?
cereal は良く知りませんでした。シリアライズのためのライブラリということですね。この型クラスは hPut や hPutStr のような関数を抽象化するためのもので、シリアライズとは少しずれているように私は思っています
とりあえず名前の方に違和感があります
cerealが提案された理由にも繋がっていて
Writerableみたいな名前をつけると他言語の経験から
[std::io::Write - Rust]()

[Writer (Java Platform SE 8 )]()
が連想されて「書き込む先」を抽象化しているように見えます
もちろん WritableWriter は違う名前なのですが一見同じに見えてしまうので

hPutStrLn を抽象化するというのは
[Data.ListLike]()
が達成はしているようですね
https://hackage.haskell.org/package/hakyll-4.13.3.0/docs/Hakyll-Core-Writable.html から引き継いだ名前なのですが、そう取られるんですね。代替として Puttable はどうかなと思ったんですが、これもシリアライズのライブラリの Put とかと混同されそうで怖いですね。
自分がcerealを引き合いに出したのは,どちらかというと機能直交性(serializeすることと,それを何にどう使う/書き込むかは直交している筈)の点で気になるためです
僕も notogawa さんに賛同で,これは出力先が Handle じゃなくても通用する気がして,ByteString に変換できれば良さそうな気がします (ただ,おそらく cereal はオーバーキルな気がしていて,名前的には StringLike みたいな感じなんですよね.僕はこれは,このプロジェクト独自の機能であって抽象化されるべきではない (例えば,String をファイルに書き込むときにエンコーディングの選択などで実装が一意でない) と思うので,このままでいいと思います)
(ついでに,個人的には,これらは Handle の種類や実際のデータ型によって,適切なバッファリング設定が違うはずで,書き込みの抽象化はそういうパフォーマンス面での制御がしにくく逆に結構面倒 (今回はおそらくそこまで IO パフォーマンスを気にするものではないと思うのですが) なので,結構避けてるというのがあります)
Writable で抽象化していたものを ByteString で具象化することを頭の中にいれながら進めていくことにします。答えてくださった皆さん、ありがとうございました。ここに質問して良かったです。
haskellの問題なのかarchlinuxの問題なのかわからないのですが、とりあえず質問です
hackageによると、最新のbaseのバージョンは 4.12.0.0 だと思うのですが、archlinuxでは 4.14.0.0 になっているようなのです。
(ghcのPKGBUILDみてみても確かに 4.14.0.0 を指定している)
これはarchlinux側が単純にミスしている(存在しないバージョンを指定している)のか、それともhackage側に表示されない何かがあるのか、そもそも私が何かを見落としているのでしょうか…
Haskell側で問題なさそうならarchのコミュニティに投げてみようと思っています
https://hackage.haskell.org/package/base
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/ghc#n99
取り急ぎ: Arch側が合ってます
了解です、ありがとうございます