haskell-jp / mmlh #3

わかりました。できるところまでやっちゃってください。
マージできるかと言われるとちょっと厳しいかも知れませんが。。。
優先的に解決しておきたい issue ってどれですか?(僕ができそうな感じなら着手します。
OK, 整理します。
@fumieval has joined the channel
Haskell Dayまでに優先的に片付けたいissueについてpriority:highとpriority:miduimというラベルを着けました。
https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues
私はこれから https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/9 に取り組むつもりでしたが、予定を変えて https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/28 を先にします。
@wado :point_up: issueにしておきました。敢えてpriorityはmidumとしていますが、今すでに取りかかっているならそのままやってみてください。 :pray:
ありがとうございます!何とかしてみます!
ビルド時間の問題は、pandoc依存を一旦あきらめて、insert-ordered-containersへの依存もやめれば大分短くなると思うんだよなぁ。
insert-ordered-containersがlensに依存してるので。。。
ただpandocをやめるとなると、今度はWindowsで https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/9 を解決しつつ正常に表示するのが難しくなる。(`more`コマンドも試してみたけどchcp 65001してもうまく表示されないっぽい...)
時間もないし、Windowsでの #9 の解決は諦めるかな。。。 :disappointed:
:bulb: Pandocの代わりに http://hackage.haskell.org/package/cmark を使うという手があるな。こっちはWindowsでも普通にインストールできたはず。この間仕事でも使ったし。
cmark, windowsでもビルドできた。 :checkered_flag:
branch protectionの設定を変更して、masterにマージするpull requestはappveyorによるビルドも必須にしました。
issue 22 の優先度が高いのでやりたいんですが、windows 環境が無いので、他にやった方が良いやつありますか?
@wado https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/37 の 2つめ
なおかつ(lensに依存している)insert-ordered-containersへの依存をやめる
はいかがでしょうか?
InsOrdHashMapに依存したのは、 https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/7 を解決するときだったんですが、実際格納しているexerciseはたかだか数個なので、そもそもHashMapである必要もないと思われます。
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 についてですが、記述にかなり瑕疵があるように見えます(特に"関数型言語では変数は値に直接束縛されます"のあたり)。ラムダ計算に詳しい方の意見を求めます
私の理解が正しければ、 この定義も示す通り「束縛」というのは変数と抽象の関係であり、決して値レベルの話ではないため、「値に束縛される」というような言い方をした時点で誤りだと思いました
構文の項(Term)とは別に,項の意味として値(Value)というものを考えれば,「評価する」とか「解釈する」とかの文脈において,「変数を値に束縛するという操作」を考えることは妥当な気がしますがどうでしょうか.
何を参考にするかは自由だと思いますが、文献は多い方が良いと思うので色々はりますね。

『計算論理学』講義資料
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 の出現は「束縛されている」という。
ソフトウェア基礎論配布資料 (3)
https://www.fos.kuis.kyoto-u.ac.jp/~igarashi/class/sf04w/resume3.pdf

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