haskell-jp / mmlh #4

fumieval
2018-10-30 09:22:56 +0900
定義すれば論理的に正しくすることはできますが、あえてラムダ計算と被る言葉を選ぶ必要はないと思います
fumieval
2018-10-30 09:29:51 +0900
ラムダ計算に関する文献を漁りましたが「変数に値を束縛させる」「変数を値に束縛する」のような表現は一つも見つからなかったので、やはりありえない言い方の可能性が高いです。日本語でよく言うバインディングなら話は別かもしれませんが
fumieval
2018-10-30 09:43:12 +0900
付け加えると、引数へと結びつけるのは確かですが、「xをyに束縛する」という言い方もせず、単に「抽象が変数を束縛する」のであって間接目的語を持たないのが一般的な言い回しのようです
fumieval
2018-10-30 10:14:09 +0900
Haskell 2010 Language Report ()を読んでいましたが、bindingが主語の場合に二箇所、 3.17.2節 "Informal Semantics of Pattern Matching"にも二箇所、値に束縛するという表現がありました。ラムダ計算と混同する心配がない文脈で、バインディングと明記すれば使っても問題なさそうですね
fumieval
2018-10-30 10:18:09 +0900
(3.17.2節は、"Binding does not imply evaluation"と書いてあるにも関わらず、値に束縛されると書いてしまっているのでかなりガバガバな感じですが…)
igrep
2018-10-30 10:22:03 +0900
OK, 調査ありがとうございました。
申し訳ないですが個人的には、このあたりの混乱を整理して全部載せるのはちょっと重すぎるし、何よりmmlhがターゲットとしているユーザーにとって利益があまりないと思っています。
だから、 https://haskell-jp.slack.com/archives/CD87P78HF/p1540857052060800 のとおり、該当のセクションの大半を削除させていただきたいと思います。
ここでの議論も手がかりになるので、（今のところJSONになっちゃうけど）slack-logにおける該当箇所へのリンクも張ります。
fumieval
2018-10-30 10:23:31 +0900
はい、思いのほか混乱が深刻だったので、別件としてこちらでまとめることにします。ありがとうございます
nobsun
2018-10-30 16:32:38 +0900
ここで新たに定義しろというつもりではなくて，「評価する」するとか「解釈する」という文脈において，「環境」という概念が登場したときに，変数と値の対を変数束縛(variable binding)と呼ぶのはよくあると感じています．
let-binding で検索するとたくさんでてきます．

ラムダ変数(出現位置?)は，関数適用をβ変換する際にのみ引数項でのみ代入(置換substitution)するように予約されているわけで，この予約があることを「束縛されている」というのであって，予約の具体化を「束縛する」というのは誤用という主張は理解できます．
fumieval
2018-10-31 00:53:12 +0900
そのような使い方は、正格な意味論の場合に限り可能です。未評価の式に束縛することもできるので、変数束縛を値に関するものと言い切ってしまうのは意味論の誤解を招くと思います
nobsun
2018-10-31 10:00:49 +0900
意味論としては，評価済みかどうかは関係なく，式が表示する値に束縛ということで良いのではという気がしますが．それだと不都合でしょうか？
fumieval
2018-10-31 10:41:02 +0900
表示というのはどのような意味ですか？評価していないものを値とは呼べないような…
nobsun
2018-10-31 14:28:53 +0900
denote(表す)という意味で使いました．項とは別に値を考えれば，項が評価されているかどうかと，値とは別に考えらると思っています．
nobsun
2018-10-31 14:43:32 +0900
「変数xをeval <expr>で束縛する」のはeval <expr>の計算が済んでなくてもできる．と考えられませんか？
fumieval
2018-10-31 15:08:01 +0900
「変数xをeval <expr>で束縛する」はもちろんできると思います。
nobsun
2018-10-31 15:25:13 +0900
とすると，何が不都合だったかが私にはまだ見えないです．
nobsun
2018-10-31 15:27:17 +0900
あっ．記事を書かれたんですね．そちらを読みにいきます．
nobsun
2018-10-31 16:50:14 +0900
記事を読ませていただきました．気になるところがありますので，#random のスレッドのほうにコメントさせて下さい．

ちょっと用事があり，書き込みは夜中になってしまいます．すみません．
2018-10-31 20:02:49 +0900
次どれやりましょう？
igrep
2018-10-31 20:05:28 +0900
@ ありがとう。
https://github.com/haskell-jp/makeMistakesToLearnHaskell#%E9%96%8B%E7%99%BA%E3%81%AB%E5%8D%94%E5%8A%9B%E3%81%97%E3%81%A6%E3%81%84%E3%81%9F%E3%81%A0%E3%81%91%E3%82%8B%E6%96%B9%E3%81%B8 のとおり、
「課題の判定処理の実装」の続きをやっていただきたいです。
具体的には、課題5は現在 mmlh verifyしても回答例が出るだけになっています。
なので、ヒントの判定処理は後回しでいいので、少なくとも正しい答えかどうかチェックする処理を実装していただけると助かります。
2018-10-31 22:38:08 +0900
exercise 4 って mmlh verify コマンドで確認しないタイプの問題ですか？
2018-10-31 23:22:04 +0900
テストの時間が長くて、その間何も出力されていないだけでした。
fumieval
2018-11-01 13:13:05 +0900
(priority:midiumのスペルが間違っていることをこっそり報告します…)
igrep
2018-11-01 13:47:58 +0900
直しました！焦って作ると間違えますね！ :+1:
igrep
2018-11-02 09:32:00 +0900
独り言: Windowsでchcp 932時に課題4の結合テストが落ちるようになった問題は、もともと潜在的に問題があったのかもしれない。
なぜ今回の修正をきっかけに発生しだしたかは不明だけど、Windows側から見たら標準入力の文字コードはCP932になっているはずにも関わらずTextをencodeUtf8で変換して渡しているのはちょっとおかしい。
igrep
2018-11-02 09:35:10 +0900
http://hackage.haskell.org/package/QuickCheck-2.12.6.1/docs/Test-QuickCheck.html#t:PrintableString はドキュメント曰くUnicode全般の印刷文字なので、CP932と非互換な文字列が混ざってもおかしくない。
ASCIIStringの方を使えばよかったんだろうか。。。