関数型プログラミング言語Haskell Part10

関数型プログラミング言語Haskell Part10 at TECH

1:デフォルトの名無しさん
09/01/14 00:51:13
haskell.org
URLﾘﾝｸ(www.haskell.org)

日本語サイト
URLﾘﾝｸ(www.sampou.org)
URLﾘﾝｸ(www.shido.info)

過去ログ
関数型プログラミング言語Haskell
Part1 URLﾘﾝｸ(pc.2ch.net)
Part2 ｽﾚﾘﾝｸ(tech板)
Part3 ｽﾚﾘﾝｸ(tech板)
Part4 ｽﾚﾘﾝｸ(tech板)
Part5 ｽﾚﾘﾝｸ(tech板)
Part6 ｽﾚﾘﾝｸ(tech板)
Part7 ｽﾚﾘﾝｸ(tech板)
Part8 ｽﾚﾘﾝｸ(tech板)
Part9 ｽﾚﾘﾝｸ(tech板)
・2chの仕様により、行頭の半角スペースは表示されません。
　コードをインデントしたいときは、代わりにまたは全角スペースを使うことができます。

2:デフォルトの名無しさん
09/01/14 00:51:48
関連書籍
・Introduction to Functional Programming Using Haskell
　URLﾘﾝｸ(www.amazon.co.jp)
・Haskell: The Craft of Functional Programming
　URLﾘﾝｸ(www.amazon.co.jp)
・The Fun of Programming
　URLﾘﾝｸ(www.amazon.co.jp)
・The Haskell School of Expression: Learning Functional Programming Through Multimedia
　URLﾘﾝｸ(www.amazon.co.jp)
・入門Haskell
　URLﾘﾝｸ(item.rakuten.co.jp)
・ふつうのHaskellプログラミング
　URLﾘﾝｸ(item.rakuten.co.jp)
・Programming in Haskell
　URLﾘﾝｸ(www.amazon.co.jp)
・Real World Haskell
　URLﾘﾝｸ(www.amazon.co.jp)

3:デフォルトの名無しさん
09/01/14 00:52:14
関連スレ
・関数型言語Part IV
　ｽﾚﾘﾝｸ(tech板)
・【数学者】Haskellはクソ言語【オナニー】
　ｽﾚﾘﾝｸ(tech板)
・純粋関数型言語Concurent Clean
　ｽﾚﾘﾝｸ(tech板)
・関数型言語ML(SML, OCaml, etc.), Part 5
　ｽﾚﾘﾝｸ(tech板)
・Lisp Scheme Part25
　ｽﾚﾘﾝｸ(tech板)
・【入門】CommonLispその4【質問よろず】 --DAT落ち、次スレなし
　ｽﾚﾘﾝｸ(tech板)
・Emacs Lisp 3
　ｽﾚﾘﾝｸ(tech板)

4:デフォルトの名無しさん
09/01/14 00:52:45
・日本語の扱いについて

Haskell98によると、Charは一つのUnicode文字を表す(6.1.2)。
これに従って、比較的新しいHugsやGHC(6.4系を含む)ではCharは32ビット整数になっている。
ただし、どちらも入出力に際しての変換が完全でない。具体的には、
・ソースコード中の文字列リテラル
・System.IOライブラリでの入出力
が問題になる。

1. GHC6.4.2以前
ソースコード・入出力ともLatin-1を仮定する。Latin-1ではバイト値と
コードポイントが一致するので、入力時には外部エンコードの各バイトがそのままCharに
入り、出力時にはCharの下位8ビットのみが出力されるような実装になっている。
このため、あるエンコーディング(Latin-1とは限らない)の入力をgetLineで受け取り、
それをそのままputStrで表示すれば、入力時とおなじエンコードにおいて正しく表示される。
これを利用して、[Char]を、本来のコードポイントの列としてではなく、特定のエンコードの下での
バイト列として使うことができる。ただし文字列リテラルについては、GHCはLatin-1として
不正な文字を受け付けないので、EUC-JPのような例外を除くと、単純にリテラルを使うことはできない。

2. GHC6.6
ソースコードにはUTF-8、入出力にはLatin-1を仮定する。このため、EUC-JPでリテラルを直に
書くことはできない。

(続く)

5:デフォルトの名無しさん
09/01/14 00:53:10
(続き)

3.最近のHugs(非WindowsかつCのwchar_tがUnicodeの環境、というかLinux)
ソースコード・入出力ともロケールのエンコードを利用する。

4.最近のHugs(Windows)
ソースコード・入出力ともLatin-1を仮定する。ただし文字列リテラルにShift-JISを使ってもエラーにならない。

5.最近のHugs(それ以外)
未調査。

・結局どうするか。
規格どおりにCharにUnicodeを入れるか、Charを単なるバイトとして扱うかの二択。

i. CharをUnicodeとして扱う
(3)以外の場合入出力で変換が必要。(2)または(3)以外の場合文字列リテラルでは
明示的なエスケープ(たとえば"\22234")が必要。

ii. Charをバイトとして扱う
(3)ではファイルをバイナリモードで開くなどの対策が必要。(1)でEUC-JPを使う場合と(4)
を除き文字列リテラルでは明示的なエスケープ(たとえば"\143\153")が必要。
lengthやisAlphaのような関数、およびwin32パッケージの関数(win32API)が正しく動作しない。

6:デフォルトの名無しさん
09/01/14 00:53:44
　　　　　　　／/
　　　　　／　 /　　　ﾊﾟｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ　まピョーん☆
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

7:デフォルトの名無しさん
09/01/14 00:54:06
前スレ11 ：デフォルトの名無しさん：2008/05/17(土) 20:00:31
そろそろ、テンプレの GHC 6.6 の日本語の取り扱いについて書き改めて欲しい。
1. ソース中の文字列 hello = "こんにちは" :: String は UTF-8
2. これを ghci で表示することは可能：(ただし、環境変数 LANG を UTF-8 にしておくこと、
また、ターミナルも UTF-8 で入出力できるようにしておくこと)
Main> print hello
こんにちは
Main>
3. 入出力 IO は Latin-1 だが、
package utf8-string (URLﾘﾝｸ(code.haskell.org))
を導入することにより、入出力を UTF-8 にすることができる
4. その他の文字列エンコード(ShiftJIS, JIS, EUC-JP など) は、
package iconv (URLﾘﾝｸ(hackage.haskell.org))
で UTF-8 な文字列にする
とまあ、こういうことで、日本語表示できるわけだ。iconv package は MacOSX と *BSD では
cabal を少しいじらなければいけないことに注意しろよ(iconv.cabal のコメントに書いてある)
よろしくたのむ、な。

8:デフォルトの名無しさん
09/01/14 00:56:06
テンプレここまで。
関連書籍に二冊追加。
Unicodeの入出力について、誰かまとめてくれるとうれしい。

9:デフォルトの名無しさん
09/01/15 18:24:13

　　　　　　　　　　　　　　　　　　　　　　　　　刀、　　　　　　　　　 , ヘ
　　　　　　　　　　　　　　　　　　／´￣｀ヽ／: : : ＼＿＿＿＿＿／: : : : ヽ、
　　　　　　　　　　　　　　,.　-‐┴─‐- ＜＾ヽ、: : : : : : : : : : : : : : : : : : : : : : }
　　　　　　　　　　／: : : : : : : : : : : : : :｀.ヽl____: : : : : : : : : : : : : : : : : : ／
　　　　　,.　-─「｀: : : : : : : : :　:ヽ: : : : : : : : :＼｀ヽ￣￣￣フ: : : : :／
　　　／: :.,.-ｧ: : : |: : : : : : : : :　　　 :＼: : : : :: : : :ヽ　＼　／: : : :／
　　　￣￣／: : : : ヽ: : : . . . . . . . . . . .､＼=--: : : :.i　／　/: : : : :/
　　　　／: : 　　　 ∧: ＼: : : : : : : : : : ヽ: :＼: : : 〃}/　　/: : : : :/　　　　　　　　、
.　　　 /: : /　　. : : :! ヽ: : l＼_＼／: : : : :＼: ヽ彡: : |　　/: : : : :/　　　　　　　 |＼
　　　/: : ｨ: : : : :.i: : | 　＼!___／ヽ:: : : : : : :＼|:.:.:.:/:!　 ,': : : : /　　　　　　　 |: : ＼
　　 / ／ !: : : : :.ト‐|-　　ヽ　　　　＼: : : : : l::::__:' :/　 i: : : : :{　　　　　　　　 |: : : :.ヽ
　　 l/ 　 |: : :!: : .ｌ: :|　　　　　　　　　＼: : : l´r. Y　　 {: : : : :丶＿＿＿＿＿__.ノ: : : : : :}
　　　　　 l: : :ｌ: : :ﾄ､|　　　　　　､＿__,ィヽ: :| ゝﾉ　　 '.: : : : : : : : : : : : : : : : : : : : : : ／
　　　　　 |: : :ﾄ､: |: :ヽ ___,彡　　 ´￣´　　ヽl-‐'　　　　＼: : : : : : : : : : : : : : : : : : イ
　　　　 !: :从ヽ!ヽ.ﾊ=≠'　, /////　///u /　　　　　　　　￣￣￣￣￣￣￣￣
　　　　　　V　ヽ|　　 }///　 r‐'⌒ヽ　　イ〉、
　　　　　　　　　　　　ヽ､______ｰ‐‐' ィ´　/:/:7rt‐---､　　　　　　　こ、これは>>1乙じゃなくて
　　　　　　　　　　　　　　　　　　ィ幵ﾉ　./:/:./:.! !: : : : :!｀ヽ　　　　　ポニーテールなんだから
　　　　　　　　　　　　　　r‐'T¨「 |: | !:.∨:/:./: :| |: : : : .l: : : :＼　　　変な勘違いしないでよね！
　　　　　　　　　　　　 /: : .|: :|　!:.!ィ¨¨ヾ、:.:/　!: : : : l: : : : : :.＼

10:デフォルトの名無しさん
09/01/17 15:11:50
今Emacs使ってHaskellやってますが、引数の型とかに合わせた候補リストみたいなの
出す機能があるエディタってありますでしょうか。

11:デフォルトの名無しさん
09/01/17 15:40:04
>>10
emacsでも出来た気がするけどね。
なんていうモードだったか忘れたけど。

viでもjeditでも出来るよ。
jeditはわりと惜しいエディタでもある。java製だし、プラグインのAPIは洗練されてないし、不安定だし、という理由で。

12:デフォルトの名無しさん
09/01/17 17:21:47
>>11
emacsのhaskell-modeは使ってますけど、型から候補を出したり補完したり
するのは知りませんでした。

13:デフォルトの名無しさん
09/01/17 17:42:09
viで出来るってのも初耳なんだが、どうやるの？

14:デフォルトの名無しさん
09/01/17 21:43:26
vim にはプラグインがあったような。詳細は覚えてないけど、ググればすぐ見つかるはず。

15:デフォルトの名無しさん
09/01/17 23:30:53
haskell for vim のことを言ってるのであれば
そんな高度なことは出来なかった気が

16:sage
09/01/19 12:26:27
>>11
最新の haskell-mode for Emacs には hoogle と hayoo 用のインターフェースがついてる。
ネット経由で、型から関数の一覧をとってこれる。今、試したら hayoo はお休み中みたいだが。
ここ参照な。

Haskell mode for Emacs - HaskellWiki
URLﾘﾝｸ(www.haskell.org)

hoogle
URLﾘﾝｸ(www.haskell.org)

hayoo
URLﾘﾝｸ(holumbus.fh-wedel.de)

17:デフォルトの名無しさん
09/01/28 12:38:00
初心者質問ですが、derivingというのは特定classのみ許される仕様なんでしょうか。

自分でderivableにする方法ってありますか？

18:デフォルトの名無しさん
09/01/28 20:36:35
Haskell98にはない
GHC拡張に似たようなものがある
URLﾘﾝｸ(www.haskell.org)

19:17
09/01/28 22:35:28
>>18
ありがとうございます。拡張なんですねぇ。頑張って理解してみます。

Javaなどの言語をやってきたんですけど、同じ関数名で引数の型が
相違するようなのを簡単に作れないのかなぁ、と思ったのです。組み込み
のclass(Eqなど)で通常は十分、ということなんでしょうかね。

20:デフォルトの名無しさん
09/01/29 00:00:02
>同じ関数名で引数の型が相違するようなのを簡単に
Javaのどういうコードが念頭にあるのか分からんけど、
もし実装の継承がしたいということなら>>18は大して訳に立たないと思う
手でインスタンス宣言を書くしかないんじゃないか

21:デフォルトの名無しさん
09/01/29 00:47:19
単にオーバーロードのことを言ってるように思えるのだが
どっちにしてもderiving関係なくね

22:17
09/01/29 20:03:34
すみません、ちょっと曖昧でした。オーバーロードではなくて、
多相な関数を定義する簡易的な方法についての質問です。

>>18というのは、Lispのマクロ的なものなんでしょうか。

23:デフォルトの名無しさん
09/01/29 22:04:42
本当にderivingが使える型クラスを作りたいなら>>18でいい(ただしできることは限られる)んだけど、
>>19や「多相な関数を定義する簡易的な方法」を聞くと違うような気がする
(Javaにはderivingに相当する機能はないよな？)
なにか具体例を見せてくれれば分かると思うが

derivingの意味を誤解してるかもしれないので念のためまとめると、
・Haskellの型クラスはインタフェースを表現する(Javaのinterfaceみたいに)
・ある型クラスの規定するインタフェースについて、個々の型における具体的な実装を書くのがインスタンス宣言
・定型的なインスタンス宣言を自動生成する機構がderiving

>>18のは、自分で定義したクラスに対してこの自動生成を可能にする方法の一つ
構文的にはderivingというキーワードを使わないけど、やってることは同じ

24:デフォルトの名無しさん
09/01/29 23:07:40
存在型(forall)のことかな？

25:デフォルトの名無しさん
09/01/30 07:46:36
>>22
多相な関数って、例えばこんな関数？

id :: * -> *
id x = x

26:17
09/01/30 11:24:58
>>23
ありがとうございます。どうもJavaのイメージとごっちゃになってる
部分があって、勘違いしてるような気がしてきましたw

型ごとに振る舞いが違う関数であれば、個別にinstanceしなければ
ならないでしょうし、そうでなければ>>25のような形になるわけですね。

27:17
09/01/31 12:06:49
もう一つclass関連での疑問なのですが、そもそも、オーバーロードが必要な場合
には逐一class宣言とinstance宣言が必要だ、というのは何か必然性があるんで
しょうか。class書いてもいいけど、書かなくても裏で同様のつじつま合わせをして
くれてもいいように思えるのですが。

28:デフォルトの名無しさん
09/01/31 14:01:03
>>27
つじつまあわせなんてしたら型推論なんてできなくなる。

型推論は、関数のこの引数はこの型じゃなければならないから･･･
みたいなことを繰り返して型を確定していくのに、
すべての関数がオーバーロードされているかもしれないんじゃ、
型を確定させることができない。

そもそもJavaなどで簡単にオーバーロードができるのは、
引数として渡される値の型が簡単に分かるから。
引数として渡される値の型と、オーバーロードされている関数の型を比較すれば
実際に呼び出すべき関数が簡単に分かる。
しかし、型推論のある言語では、型が簡単には分からないので、
class,instance宣言必須という制限をつけて範囲を限定している。

29:デフォルトの名無しさん
09/01/31 14:26:12
Java的な意味でオーバーロードがしたい場合は単に違う関数名を付けるのが普通
Haskellの型クラスは実行時多態を行うためにある

用語がややこしいけど、
Haskellでいうオーバーロード(クラスを使う) <=> Javaでいうポリモーフィズム
Javaのオーバーロードに対応する機能はない

30:17
09/01/31 14:37:11
>>28
> つじつまあわせなんてしたら型推論なんてできなくなる。

ああ、そうでした。型推論の問題なんですね。納得です。

>>29
> Java的な意味でオーバーロードがしたい場合は単に違う関数名を付けるのが普通

やはりそうなんですね。自分はコード書く際に名前付けるのが一番悩んでしまう
ので、その辺がスッキリならんのかなぁと思ったのですが。そこは仕方ないんですね。

どうもありがとうございました。

31:デフォルトの名無しさん
09/02/05 02:48:48
日本人待望のGHC用Unicode入出力のパッチが来てるな
テスト希望、議論希望、それからWindowsで動かせるようにしてくれたら嬉しいだとさ
URLﾘﾝｸ(www.haskell.org)

32:デフォルトの名無しさん
09/02/05 18:20:14
utf8-string てのが前からあったでしょ？なんか変わったの？

33:デフォルトの名無しさん
09/02/05 18:57:29
普通のStringを普通にputStrして普通に文字が出る
外部コードもUTF-8固定じゃなくて選べるし、デフォルトでロケールに合わせてくれる

34:デフォルトの名無しさん
09/02/07 20:44:03
各種schemeインタプリタのようなaproposはghciにもありますか？
これがあるとシンボルの入力補完のシステムとかが楽に組めて便利なんですが

35:デフォルトの名無しさん
09/02/07 21:09:03
ghciのUIにはないと思う
ghciに補完機能がある以上内部では持ってるはずだから、
やりたいことによってはGHC APIが役に立つかも

36:デフォルトの名無しさん
09/02/09 20:19:27
ちょっと前に2chで関数型ユーザーを叩いてみたのだけど、
やっぱり関数型の内実は80%ほどが幻想だな、という感想を持った。
Lisp,Schemeのユーザーはすぐ折れたがHaskellのユーザーは頑固だった。
まあ純粋で美しいから信者になってしまったのだろうけど、
純粋な美しさでHaskellに勝てるものはいないだろうと思う。
しかし自然言語を目指さず数学的な記述を目指したところでいいプログラムは書けない。
数学は定理を証明するための言語で、プログラミングは定理の証明ではない。
証明出来るならプログラムなんか書く必要ないしな。

37:デフォルトの名無しさん
09/02/09 20:28:06
curry howard correspondence

38:デフォルトの名無しさん
09/02/09 20:29:09
あぁ、あとこのスレは過疎もいいところだから関数型言語叩くならhaskell-cafeにおいで

39:デフォルトの名無しさん
09/02/09 20:46:24
このスレは過疎な訳じゃなくて話題がないだけだろ
見てる奴は多いだろうからいいネタがあれば盛り上がると思うぜ

40:デフォルトの名無しさん
09/02/09 20:52:12
そういやCleanって最近話題聞かないな

41:デフォルトの名無しさん
09/02/09 22:40:16
>>36
Haskellユーザーとは痛み分けだったろ。それにSchemeのほうも一年以上
かかってたじゃねぇか。

42:デフォルトの名無しさん
09/02/09 22:41:35
Haskellの強みを論理的に教えてください。

43:デフォルトの名無しさん
09/02/09 23:15:21
あなたにとっての「強い」を論理的に説明してください

44:デフォルトの名無しさん
09/02/09 23:17:24
>>43
あなたはもう発言しなくてよろしい

次の方どうぞ

45:デフォルトの名無しさん
09/02/09 23:26:37
>>42
チューリング完全なら、ぜんぶ同じでは？

46:デフォルトの名無しさん
09/02/09 23:27:20
瞬殺された>>42が朝まで暴れるとみた

47:デフォルトの名無しさん
09/02/09 23:28:39
>>36は勝利宣言だけかいｗ

48:デフォルトの名無しさん
09/02/09 23:30:41
難しい話じゃなし、疑問があるなら勉強すればいいんだよ
絡みたいだけの奴はやっぱスレに張り付いてんだなあ

49:デフォルトの名無しさん
09/02/09 23:34:37
>>48
言わせてもらいますが、
Haskellの強みをはっきり書いた論文も書籍もありませんよ。

50:デフォルトの名無しさん
09/02/09 23:36:40
関数型言語はなぜあなたのコンプレックスを刺激するのか論理的に説明してください

51:デフォルトの名無しさん
09/02/09 23:39:39
モナドのすべてにでてくる各種モナドがイミフだったから
あれらの定義を仕様を表す論理式から導き出せるようになりたい
使ってるうちに解るとは到底思えないぐらいイミフ

52:デフォルトの名無しさん
09/02/09 23:41:39
IOモナドが意味不明だったので、Lispも糞だと結論付けました

53:デフォルトの名無しさん
09/02/09 23:44:38
攻撃的な発言は発言した内容が自分自身にそのまま当てはまると内心で思っている証拠だということに最近気づいたところなんだよ。

54:デフォルトの名無しさん
09/02/09 23:49:37
だから相手を攻撃するということは自分自身の弱さを曝け出すことにもなるんだよ。

55:デフォルトの名無しさん
09/02/09 23:54:31
こういう話題になると
今までみんなどこに居たんだと思うぐらいレスが付くなあ

56:デフォルトの名無しさん
09/02/10 00:12:59
>>45
全然話の流れと関係ないとこで気になったんだが
チューリング完全なら全部一緒という論調ってどこか違和感がある

CのプリプロセッサとCはどちらもチューリング完全性だと思うが
単純に構文糖衣という意味以上に、能力的にはCのほうが高いと思う。
スケーラビリティの点で。
Cで関数引数nに、簡単に大きな引数を指定出来るのに対し
プリプロセッサで同じことをやろうとすると、
大きな引数nの値と同じ数だけ自分でデータを作る必要が
あったように思う

そういう意味でプログラム自身をデータと見なせるLispは
かなりスケーラビリティ的な意味で能力が高いと思うわ
しかし、プログラム自身をデータと見なせるだけでは
まだスケーラブルにならない世界もあるんじゃ無かろうか
うまく説明できんが、
自然数→整数→実数→複素数の進歩のように

57:デフォルトの名無しさん
09/02/10 01:12:25
どうでもいいところに突っこむが、Cプリプロセッサのための任意長整数ライブラリは存在するよ
URLﾘﾝｸ(sf.net)
とか

58:デフォルトの名無しさん
09/02/10 01:36:36
>>36
Haskellユーザーよりも、Lisp,Schemeの方が、バカの扱いに慣れているって事が分かりました。

59:デフォルトの名無しさん
09/02/10 14:26:27
自然言語を目指すとか10年古い釣りワードが入ってるし

60:デフォルトの名無しさん
09/02/10 14:54:02
10年どころか、30年古いぞｗ