haskell-jp / mmlh #3

igrep
2018-10-28 16:23:15 +0900
わかりました。できるところまでやっちゃってください。
igrep
2018-10-28 16:23:53 +0900
マージできるかと言われるとちょっと厳しいかも知れませんが。。。
2018-10-28 16:28:18 +0900
優先的に解決しておきたい issue ってどれですか？(僕ができそうな感じなら着手します。
igrep
2018-10-28 16:29:12 +0900
OK, 整理します。
fumieval
2018-10-28 16:30:00 +0900
@fumieval has joined the channel
igrep
2018-10-28 16:35:59 +0900
Haskell Dayまでに優先的に片付けたいissueについてpriority:highとpriority:miduimというラベルを着けました。
https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues
igrep
2018-10-28 16:36:42 +0900
私はこれから https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/9 に取り組むつもりでしたが、予定を変えて https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/28 を先にします。
igrep
2018-10-28 18:09:18 +0900
@ :point_up: issueにしておきました。敢えてpriorityはmidumとしていますが、今すでに取りかかっているならそのままやってみてください。 :pray:
2018-10-28 18:17:09 +0900
ありがとうございます！何とかしてみます！
igrep
2018-10-29 08:55:48 +0900
ビルド時間の問題は、pandoc依存を一旦あきらめて、insert-ordered-containersへの依存もやめれば大分短くなると思うんだよなぁ。
insert-ordered-containersがlensに依存してるので。。。
ただpandocをやめるとなると、今度はWindowsで https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/9 を解決しつつ正常に表示するのが難しくなる。（`more`コマンドも試してみたけどchcp 65001してもうまく表示されないっぽい...）
時間もないし、Windowsでの #9 の解決は諦めるかな。。。 :disappointed:
igrep
2018-10-29 08:58:17 +0900
:bulb: Pandocの代わりに http://hackage.haskell.org/package/cmark を使うという手があるな。こっちはWindowsでも普通にインストールできたはず。この間仕事でも使ったし。
igrep
2018-10-29 09:19:34 +0900
cmark, windowsでもビルドできた。 :checkered_flag:
igrep
2018-10-29 16:33:56 +0900
branch protectionの設定を変更して、masterにマージするpull requestはappveyorによるビルドも必須にしました。
2018-10-29 16:39:29 +0900
issue 22 の優先度が高いのでやりたいんですが、windows 環境が無いので、他にやった方が良いやつありますか？
igrep
2018-10-29 16:43:43 +0900
@ https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/37 の 2つめ
なおかつ（lensに依存している）insert-ordered-containersへの依存をやめる
はいかがでしょうか？
igrep
2018-10-29 16:45:46 +0900
InsOrdHashMapに依存したのは、 https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/7 を解決するときだったんですが、実際格納しているexerciseはたかだか数個なので、そもそもHashMapである必要もないと思われます。
fumieval
2018-10-29 19:40:27 +0900
https://github.com/haskell-jp/makeMistakesToLearnHaskell/pull/35#discussion_r228872458 で参考資料として挙がった https://www.fine.cs.kobe-u.ac.jp/members/kamada/old/scheme_web/let_1_2.html についてですが、記述にかなり瑕疵があるように見えます(特に"関数型言語では変数は値に直接束縛されます"のあたり)。ラムダ計算に詳しい方の意見を求めます
fumieval
2018-10-29 19:47:15 +0900
私の理解が正しければ、 この定義も示す通り「束縛」というのは変数と抽象の関係であり、決して値レベルの話ではないため、「値に束縛される」というような言い方をした時点で誤りだと思いました
nobsun
2018-10-29 22:35:56 +0900
構文の項(Term)とは別に，項の意味として値(Value)というものを考えれば，「評価する」とか「解釈する」とかの文脈において，「変数を値に束縛するという操作」を考えることは妥当な気がしますがどうでしょうか．
2018-10-29 23:52:58 +0900
何を参考にするかは自由だと思いますが、文献は多い方が良いと思うので色々はりますね。

『計算論理学』講義資料
http://www.cs.tsukuba.ac.jp/~kam/complogic/main.pdf

このような λ と変数の出現の対応関係を「束縛」と言う。

====

ラムダ計算入門
http://www.kb.ecei.tohoku.ac.jp/~sumii/class/keisanki-software-kougaku-2005/lambda.pdf

λ 抽象の仮引数となっている変数のことを束縛変数といい、

===

コンピュータ・サイエンス入門
http://www.kurims.kyoto-u.ac.jp/~cs/lecture2009/lecture090507.pdf

この位置の x が束縛されているとは、x が (λx. · · · ) によって囲まれている時、つまり
· · · (λx. · · · x · · · )· · ·
となっている時である。

===

ラムダ計算と計算可能性
https://www.math.nagoya-u.ac.jp/~garrigue/lecture/2010_tenbo/lambda.pdf

λx.M では、M の中の全ての x の出現は「束縛されている」という。
2018-10-29 23:55:16 +0900
ソフトウェア基礎論配布資料 (3)
https://www.fos.kuis.kyoto-u.ac.jp/~igarashi/class/sf04w/resume3.pdf

λ 計算において，λx.t の x が変数宣言であり，その有効範囲は t である．t に現われる変数項 xは束縛変数である．
自由・束縛という概念は，より正確には，変数 (の名前) ではなく，変数の出現 (箇所) に対して使われると考えた方がよい．
igrep
2018-10-30 08:48:28 +0900
ここまでのfumievalさんwadoさんの解釈や引用元をまとめるに、変数が束縛されるのは引数の方であって、「変数に値を束縛させる」という言い方自体が不適切なんじゃないか、というように聞こえたんですが、合ってますか？
:confused: そうだとすると、私がよく聞いてきた（例のPRで挙げた参考文献のような）説明も本当は厳密ではない。。。？
igrep
2018-10-30 08:50:52 +0900
正直なところ、もう「代入と束縛の違いについては https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/28 や https://github.com/haskell-jp/makeMistakesToLearnHaskell/pull/35 を見てね」ぐらいで済ませて該当のセクションの大半を消してしまいたい。。。 :cold_sweat: