haskell-jp / questions #45

お二方とも、ありがとうございます！！修正してみます！

部分関数という概念を初めて知ったんですが、「定義されていないパターンマッチが残る関数」って解釈であってますか？

パターンマッチに限った話ではなく、全域で定義されていない関数のことを言うと思います。例えば除算も実は部分関数ですね（0で割る場合に定義されない）

なるほど！理解しました！

純粋な計算は値を求める(だけ)というのに対し，effectもside-effectもそれとは違うという感覚では同じなのですが，effectとside-effectとでは，観点が少々違うという印象です．effectは，計算の環境というか文脈を差し替えるような計算．side-effectは従来の命令的プログラミングにおいては参照透明性のない記述が必要になるような計算という印象です．

呼ばれたような気がする．
:relaxed:
Haskell Sudoku でググルと沢山でてきますよ．ついでにステマ(死語?)
https://amzn.to/2Tg4DcO

純粋関数が言語で、命令言語でいう side-effect をどう扱うかという課題に対し、monad による progiramming with effect が考え出されたという説明になっています。

なので、この文脈では、side effect の一般化が effect ではないかと。effect だと、IO もその振る舞いを狙ってやってるんだみたいなニュアンスが出てるのかも。

Hutton本第二版の謝辞に
Tomoyas Kobayashi
さんという名前があります。
"u"が抜けているのではないかとか、漢字に直すべきですか、とか質問したいのですが、Huttonさんに教えていただいたメールアドレスは user unknown になってしまいました。
この方をご存知の人はいませんか？

同一人物かはわかりませんが Scala mailing list archive にその表記のまま投稿している方がいるので，
http://www.scala-archive.org/template/NamlServlet.jtp?macro=user_nodes&user=15217
Scala界隈にも聞いてみたほうがいいかもしれませんね．
ただ 2008 年以降の投稿は見付からないので，つながらないかも．

申し訳ない、Hutton本というのを読んだことがないので軽く調べた限りでは、 @huskellhutt というハンドルの方がツイッターに居るのですが、おそらくその方と同一なのではないかなと。

それは「Hutton氏が自身の別名義であるTomoyas Kobayashiを謝辞に並べた」「Hutton氏がkazuさんに自身の別名義のしかも無効なメアドを教えた」ってことになるんですが何か元の質問を誤解してませんか？

haskellhuttさんは、著者のHuttonさんのようですね。

この質問の私の理解は、 Hutton本の著者になんとかして連絡したい、連絡先が分かる方はいるか。 ですが。 何か問題ありました？

その解釈だと，メールアドレスを教えて頂いたこともあるHuttonさん=kazuさんにとって既知の人物，を対象として「この方をご存知」かと問うていることになるので，おかしいと思います．
この質問文面でkazuさんが「この方をご存知」か問うに値する対象はTomoyas Kobayashiさんのほうであり，質問は

Hutton本第二版の謝辞に
Tomoyas Kobayashi
さんという名前があります。
"u"が抜けているのではないかとか、漢字に直すべきですか、とか(Tomoyas Kobayashi当人に)質問したいのですが、Huttonさんに教えていただいた(Tomoyas Kobayashiの)メールアドレスは user unknown になってしまいました。
この方(=Tomoyas Kobayashi)をご存知の人はいませんか？

だと読み取ってるんですが，実際どちらが質問の意図なんでしょう？

私は参加したことなくて，これだけの情報から推して知るのも私にはちょっと難しいので参加したことある人に純粋に質問なんですが，どんなコミュニティなんでしょう？

わいわいしゃべりながらめいめいがめいめいの作業をやってる感じです。Haskell-jpもくもく会よりもしゃべる比率がかなり高めでしたね。
あと、Meetupで英語で募集していることもあってか、外国の方が大半を占めることが多いです。

当てこすりのつもりではないですが、実際にHaskellを使うこととはあまり関係のないおしゃべりの割合が多い(私に言わせれば、"なんか違う")印象を受けました。オーガナイザのYasuaki KudoさんがHaskellを使っているところも一度も見たことがないです

notogawa さんの解釈であってますよ。

notogawaさんの情報を見て「Tomoyasu Kobayashi scala」でググったら「Programming in Scala」の謝辞に「Tomoyasu Kobayashi」という方が載っていました。この本は 2011年ですか。

土日はバタバタしていてお返事が遅くなりましたが、ありがとうございました。
Scalaコミュニティにはコネがないので、Twitterで聞いてみます。

構成子が一つの data が、newtype のようにオーバーヘッドなしでは扱われない理由って、何かありますか？

補足：格納する型も1つの場合です。newtype として扱えるのに、なぜそういう最適化がなされないのか知りたいです。

WHNF に違いがあったような
StrictData なら newtype に変えても意味変わらないかもですね

bang 付きとも違うようでした
https://haskell.e-bigmoon.com/posts/2018/06-25-all-about-strictness#newtype-%E3%81%AE%E8%88%88%E5%91%B3%E6%B7%B1%E3%81%84%E3%82%B1%E3%83%BC%E3%82%B9

挙動が変わるので、最適化できないんですね。

@ has joined the channel

皆さんの中で、CRLFでHaskellのソースを書くよ、という方はいらっしゃいますか？いたら :heavy_check_mark: のemoji reactionかこのスレッドに返事をください（押しやすいように私があらかじめ追加しておきます）。
Windowsでエディターの設定を特に変えずに書いている場合も該当する可能性があります。

途中で気付いて、後で一括変換しようと思いながら、今もそのままになってるやつがあります……

日常的にCRLFで書くことを想定してましたが、それはありそうですね。。。
実は本件を聞こうと思ったきっかけが、hsimportというツールを使ってみたら処理したファイルがすべてCRLFになってしまってどうしたもんかと思ったことだったんで、気づかなかったらそのまま私もCRLFでコミットしていたかも... :disappointed_relieved:

git関連なら core.autocrlfをinputにしとけば勝手にCRLFはLFに変換されるので(LFで開発してるなら) 便利ですよ。

「それぐらいエディタの設定でやるわい！」という思いとその手の自動変換への恐怖で避けてましたが、この際それは一案ですね... :thinking_face:

@桐ケ谷和人 has joined the channel

Haskell入門 (本間、類地、逢坂)を読んでおります。p224において、
class Triple a where
triple :: a -> a
instance Triple String where
triple s = s ++ s ++ s
と定義されておりますが、どうやらinstanceではStringはそのままでは定義できないようです。代替として、instanceにおいてStringを入れる方法は存在するのでしょうか。

Stringを newtypeで包んであげるか、 TypeSynonymInstancesのGHC拡張を入れてあげると行けると思います

参考 https://qiita.com/7shi/items/17a1567a635af17fc83f#%E5%9E%8B%E3%82%AF%E3%83%A9%E3%82%B9

どうもありがとうございます。newtypeで出来ました。言語拡張の方法も後に試してみようと思います。

@warugaki_k_k has joined the channel

正誤表にもありました！
https://gihyo.jp/book/2017/978-4-7741-9237-6/support

P.224　下部のリスト
コードの一番上に{-# LANGUAGE FlexibleInstances #-}を追加します。

@ has joined the channel

@ has joined the channel

WSL Ubuntu 18.04 から Visual Studio Code を立ち上げると Editor の default EOL は auto ですから　ほとんどの directories で CRLF になります

それは、さすがに既存のLFなファイルを開いた場合はLFのままですよね？

ふと思ったんですけど、型クラスReadってどれくらい優秀なんですか？
read . show == id
が成り立つデータ型なら、それがどれだけ複雑になったとしてもRead可能なのかなーと気になりました。

逆に
read . show == id
であってもreadできないものってありますか。

標準の Read クラスの場合、 readsPrec の設計思想の範囲でまともなパーザが書けるか？という話になるかと思いますが、たぶん（性能を気にしなければ）ひたすら分岐してやり直す形のパーザならば書けそうだと思います。ただしデータ構造の複雑度のべき乗で遅くなりそうな気はするので、それを「Read 可能」と言っていいかどうか…
で、それだと効率がわるいということで ghc の Read クラスは拡張されてるみたいですね（今調べて知ったのですが^^;）。 http://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.Read.html

おおう、ありがとうございます。このモジュールに書いてあるコメントを読んでみます。

気になった理由としては、Readには地雷があって、いずれ踏み抜くんじゃないかとふと思ったからです。

速さを気にするなら、遅いのでデバッグ用途や書き捨てぐらいの気持ちで使った方がいい気はします

Text.ParserCombinators.ReadP モジュールに気がるに使えるParserコンビネータがあります．これを使って，ReadP a 型のパーザを構成して，readP_to_S :: ReadP a -> ReadS a を使って，ReadクラスのreadsPrecを定義するというのを良くやります．