haskell-jp / random #31

知らないパッケージを検索した時に見つかる Hackage の URL が、いつも https ではなく http になっているのちょっと不思議 (検索サイトは関係ない模様)

今年の Advenct Calendar は去年に比べたら低調ですね。（去年が多すぎただけか）
「Haskell Advent Calendar 2018」（空席1つ） https://qiita.com/advent-calendar/2018/haskell
「Haskell (その2) Advent Calendar 2018」（空席多数） https://qiita.com/advent-calendar/2018/haskell2

去年は その5 まであったんですね...ｗ

まぁ、多けりゃいいってもんでもないですし、やる気のある範囲でやればよいのではないかと。（私は今回できるかまだ不透明なので登録を先延ばししています :bow:

アドベントカレンダーの数に固執するよりは、一年を通して質の良い記事を発信するほうがコミュニティのためになるとは思います

むしろ、なんで去年はあんなに多かったのか

Haskellのサポートができる日も近いぜよ
https://www.publickey1.jp/blog/18/aws_lambdarubyaws_reinvent_2018.html

このCustom Runtimesに対応したC++とRustの環境をAWSはオープンソースとして公開。さらにPHP、COBOL、Erlangなどのサポートを行うパートナーも発表されました。

COBOL すごい

Haskellがない。

golangのaws lambdaは
https://golang.org/pkg/net/rpc/
これをつかったTCPのサーバーをたてるだけだから
同じような感じでhaskellも動かせるような気がしています。

カスタムランタイムでどんな言語でもできるよ、公式は C++ と Rust の分を作ってOSS化しといたよ
PHP、COBOL、Erlang のもやってくれる人がいるってさ
ぐらいに思ってたので、誰か Haskell やって公開すればいいんですよね

実行ファイルを zip 化して upload する感じなのかな

Custom Runtimes

AWS Lambda の実行環境は Amazon Linux (CentOS) なので、Amazon Linux 向けにビルドした Haskell バイナリを JavaScript の zip に同梱して node API でキックすれば、今までも実はLambda上で Haskell を動かせないことはなかった。
Custom Runtimeというのが実際何をしてくれるのかは把握していないですが。

1, LAMBDAのAPIをたたいてリクエストもらう
2, リクエストに基づいて処理
3, LAMBDAのAPIをたたいて結果を返す
という流れなのですね。
Custom RuntimeというのはLAMBDAのAPI（RESTかなにか）の仕様なんでしょうかね。

:tune:

（igrepさんに「ちゃんとHaskellerしてください」と怒られた気がする）

Haskell は dlopen みたいな機能あるかなあ？もしあったら汎用的な Runtime を作れるかもしれないなあ

plugins というpackageを知ってるけど、でもGHCを必要から、ばかでかくなっちゃう。。。

完全にGHCのランタイムから分離させたものは難しいでしょうね。。。 :disappointed:

Haskell コード同士で FFI を使うという邪道を考えてみた ww :joy:

確かGHCでビルドしたsoファイルをGHCでforeign importするのはできなかったはず（多分、ランタイムの何かが衝突してしまうから）なので、同じ理由でそれも難しそう。。。 :sweat_smile:

rts 二人分で喧嘩しちゃうってこと？

はい、 https://downloads.haskell.org/~ghc/8.4.4/docs/html/users_guide/shared_libs.html#shared-libraries-that-export-a-c-api のWarningで言っていることはそういう意味のはず。

hmmm

... あ、と思ったけど、すぐ上のセクションで書いてある、 Shared libraries for Haskell packages の方法ならHaskellで書かれたパッケージをHaskellのプログラムからdynamic linkできるみたいですね。すみません。

:thinking_face:明日ちょっといじってみよう。。。

でもよく考えたらそうやるメリットが全然ない。。。

WebAssemblyのイメージ図集を描きました。
HaskellもWebAssemblyのバックエンド(Asteriusやdhc)があるので、ここでも共有しておきます:slightly_smiling_face:
（ちょっと忙しくなりそうなので、現バージョンでopenしました。理解ミス箇所等は今後修正します。）
ちなみに、WebAssemblyのreference interpreterは、OCaml製です。

https://takenobu-hs.github.io/downloads/WebAssembly_illustrated.pdf

そういえば、haskell(ghc)は、llvmを吐けるからそれ経由でwasmにできないかなとか思ったけどどうなのかな

asteriusは、GHCから(LLVMを経ずに直接)Binaryen経由でwasmを吐かせているようです。
https://github.com/tweag/asterius

ただ、原理的にはLLVMに持ち込めれば、Binaryen経由でwasmは吐けるのかなと思います。
（LLVM自体がwasm用のバックエンドにBinaryenを使ってるようでした。）

ただ、ランタイムの部分をどうするかが、結構みなさんの工夫と腕力の見せ所のようです。
asteriusは、GHCのランタイムの軽量版をwasm（とJavaScript）で自力で書いたようです。
なかなか凄い腕力です！:star2:

さすがはtweag 変態さんってことですね^^

[fpco/stack-build]() がめちゃ重だったので小さめのDockerイメージ作ってみました：kirisaki/overflow - Docker Hub https://hub.docker.com/r/kirisaki/overflow/

なんでoverflowっていうんですか？

記憶が曖昧なんですが、wasmって使用できる命令はじめいろいろ制限が厳しいので、単純にGHCが吐いたLLVMを変換できるかは怪しかったかと思います。 :disappointed:

確かに。 例えば、単純なgotoが使えないので、asteriusは tail callをwasmで工夫して実装してるようでした:muscle:

昨日話したHaskell同士でFFIで実行したい話し、なんとか出来たみたいけどが、join $ mkFun <$> dlsym dl "library_close" の一行を実行したらなぜか main が実行終わったらSegmentation fault: 11になっちゃう。。。

でも流石に実用性が皆無かなあ。。。

stackなので

ちなみに、単にlibraryをLoadして何もしないのもSegmentation fault: 11。。。やはりあのGHCの制限みたい。。。逆に、Initializeだけするならエラーなく実行できるのはちょっと不思議。。。

なるほどw

小さくするためにどんな工夫をしたんでしょ？

イメージにdebian:stretch使いました。あとstack-buildではいろいろ他にも入ってたみたいなので必要最低限に絞ったり

@yukimemi has joined the channel

GHCのホスティングを、TracからGitLabへ移す先行テストが始まります:haskell:
（GitHubのアカウントがあれば、GitLabへログインして試せます。）
https://mail.haskell.org/pipermail/ghc-devs/2018-December/016613.html

‪Haskell のソースコードの複雑性を、型チェックの際のユニフィケーションの数で測ることを考えたことがあるんだけど、実現できそうですかね‬

意図しているところは (<$>) <$> (<$>) みたいなコードを排除すること