トップページ⇒tech
1001コメント379KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2006/11/07(火) 21:24:26
haskell.org
http://www.haskell.org/

日本語サイト
http://www.sampou.org/cgi-bin/haskell.cgi
http://shidot.dyndns.org/hs/

過去ログ
関数型プログラミング言語Haskell
Part1 http://pc.2ch.net/tech/kako/996/996131288.html
Part2 http://pc2.2ch.net/test/read.cgi/tech/1013846140/
Part3 http://pc8.2ch.net/test/read.cgi/tech/1076418993/
Part4 http://pc8.2ch.net/test/read.cgi/tech/1140717775/
Part5 http://pc8.2ch.net/test/read.cgi/tech/1149263630/

関連スレは>>2
関連書籍は>>3

・2chの仕様により、行頭の半角スペースは表示されません。
　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。
08968932007/03/08(木) 02:25:45
>>894
ありがとうございます！
Stringの値が必要になったら全読みされちゃわないんですか？
Stringのケツが必要になるまでは遅延される？

>>895
１行ｷﾀ─(ﾟ∀ﾟ)─!!!!　まさに関数型!!!
関数合成ってそう使うんですね。初めてしっくり来ました。
08978932007/03/08(木) 02:55:18
おっとトラップ？
main=getArgs>>=readFile.head>>=(\c->mapM_ (putStrLn.take 30)$lines c)
にしないと、>>882の動きになりませんでした。
このラムダは消せないのでしょうか…？
0898デフォルトの名無しさん2007/03/08(木) 05:30:36
自分なら
main = getArgs>>=readFile.head>>=putStrLn.unlines.map (take 30).lines
とやる。
0899デフォルトの名無しさん2007/03/08(木) 06:30:58
>>897
main = getArgs >>= readFile . head >>= mapM_ (putStrLn . take 30) . lines

ちょっと分かりづらいか･･･。
0900デフォルトの名無しさん2007/03/08(木) 09:28:14
#includeで実現できるのはスタックにすぎない
よって実現できるのはプッシュダウンオートマトンであってTuring機械ではない
（外部スクリプトで複数回CPPをかけていいんならTuring完全になる）

ただしC++ templeteを使っていいならTuring完全になる
09018392007/03/08(木) 09:37:55
lispと比べたhaskellのメリットは

http://practical-scheme.net/wiliki/wiliki.cgi?Lisp%3A%E3%82%88%E3%81%8F%E3%81%82%E3%82%8B%E8%AA%A4%E8%A7%A3&l=en
>なので、C並に速いLispコードは見た目も安全性もC並になる、というのが私 (Shiro) の経験です。

haskellの場合はC並にごちゃごちゃしなくてもC並の速度が実現できるということなのでしょうか？
0902デフォルトの名無しさん2007/03/08(木) 09:56:04
言語同士にはそんな単純に言い切れるほどはっきりとした差がつくもんじゃないよ
おもちゃベンチマークでもなければね

どうして安易な1フレーズの結論に飛びつきたがるのかなぁ
0903デフォルトの名無しさん2007/03/08(木) 10:22:58
>891
Boost だけど template を使ってるわけじゃないんだね。
漠然と、シンボルを結合したりしているのかな、とは思っていたが、うまい方法が思いつかなかったよ。ありがとう。
0904デフォルトの名無しさん2007/03/08(木) 10:38:50
>>900
>>892のリンク先のコード(β簡約器)はincludeを使っていない。
見れば分かるけど、λ式を最大nステップ簡約するマクロはO(log n)個のdefineで書ける。
だから「実質的に」チューリング完全、と書いた。

http://pc11.2ch.net/test/read.cgi/tech/1068359871/
完全にすれ違いなのでレスがあればこっちによろしく。(適当なスレが見付からなかったので)
0905デフォルトの名無しさん2007/03/08(木) 10:55:04
Boost PPの話はここに詳しい人がいると思います

Boostを語れゴラァ part3
http://pc11.2ch.net/test/read.cgi/tech/1158991211/
0906デフォルトの名無しさん2007/03/08(木) 12:15:39
>>899
最後は、mapM_の部分適用…と思って、小一時間悩みました。
最後は、(mapM_ (putStrLn . take 30)) . lines と評価されるんですね。

結合順位重要。関数適用最強…と。　＿〆(。。)
0907デフォルトの名無しさん2007/03/08(木) 16:12:46
GHC使いなら -ddump-parsed をつけてコンパイルしてみるのも手かと。
0908デフォルトの名無しさん2007/03/08(木) 23:48:49
ちょっとやってみたけど


まぁまぁ面白いな
0909デフォルトの名無しさん2007/03/09(金) 03:49:25
>>907
知らなかった…。初心者にはあり難い。
0910デフォルトの名無しさん2007/03/09(金) 12:39:44
main = readLn >>= print . (1+)
を -ddump-parsed つけてコンパイルしてみたら(GHC6.6)

==================== Parser ====================
main = (readLn >>= print) . ((1 +))

って表示されたんだが、このパースは間違ってる。
実際、これをコンパイルすると型のミスマッチのエラーが起きるし。

本来は
main = readLn >>= (print . (1 +))
とパースされるわけで、実際処理系自体はそのようにパースしてるはず。
0911デフォルトの名無しさん2007/03/09(金) 13:05:50
結合の弱い順に演算子を使った
main = a >> b || c && d == e : f + g * h ^ i . j
に対しては
main = ((((((((a >> b) || c) && d) == e) : f) + g) * h) ^ i) . j
となった。どうも、演算子の結合強度を全く考慮していないらしい。
といっても、演算子の結合強度はパースしてみないと分からないので仕方ない。
0912デフォルトの名無しさん2007/03/09(金) 13:11:30
代わりに-ddump-rnを使えば良さそう。
09139072007/03/09(金) 17:16:48
>>912
あー、ほんとだ。こっちの方が正しいね。サンクス。
0914デフォルトの名無しさん2007/03/11(日) 12:39:27
main = writeFile "a.txt" "こんにちは"

GHC 6.6 Windows環境で上記ソースをUTF-8にして実行してみたんですが、
出力ファイル(a.txt)の中身が「S?kao」となってしまいます。
日本語を正しく出力するにはどうすればいいんでしょう？
0915デフォルトの名無しさん2007/03/11(日) 12:42:46
>>914
変換が要る。
>>402-414あたり参照。
0916デフォルトの名無しさん2007/03/11(日) 13:11:16
毛唐に任せてたら対応がいつになるか分かったもんじゃないぜ。
だれか直してパッチ送りつけろ。
0917デフォルトの名無しさん2007/03/11(日) 14:21:50
http://hackage.haskell.org/trac/summer-of-code/ticket/1113
これに応募するとか。
09189142007/03/11(日) 15:47:50
>>915
どもです。IOの標準ライブラリがUTF-8対応されたわけじゃないのですね。

日本語がどうしても必要な時はWinHugs使ってみます。
こちらはこちらでアンインストールできないバグがありますが･･･。
0919デフォルトの名無しさん2007/03/12(月) 00:09:24
これってWindowsAPIとか呼べますか?
0920デフォルトの名無しさん2007/03/12(月) 00:18:43
これってどれよ
0921デフォルトの名無しさん2007/03/12(月) 00:52:28
これっちゃこれよ
0922デフォルトの名無しさん2007/03/12(月) 01:27:08
importsのしたにSystem.WIn32.*ってあるな。
でもリファレンスには載ってない。System.Posix.*は載ってるのに。
0923デフォルトの名無しさん2007/03/12(月) 02:44:10
>>917
それは違うんじゃないか？
＞　* String/ByteString/UTF8String/UTF16String as filename
まあファイル名にも使えて然るべきだけど。
0924デフォルトの名無しさん2007/03/13(火) 16:39:59
>>923
コード変換が実装されない一番の原因は、今のGHCのIOライブラリが拡張しにくい
構造になっていることだから、それをまずなんとかするのが先決だ。
で、なんとかしようというのが>>917の提案だろう。
枠組さえできれば、コード変換を実装する事自体は難しくない。
0925デフォルトの名無しさん2007/03/13(火) 23:15:59

おまえらWindowsでHaskellしてんの？
Linuxの場合、Fedoraはいろいろ対応してるぽいが、
Debian系のUbuntuは使用不可能？
0926デフォルトの名無しさん2007/03/14(水) 02:00:13
>>924
いつのまにか書き換えられてるな。
・Various encodings (UTF8,UTF16...) for text files
もリンク先に増えてる。うしゃ。

しかし、
class Stringable a where
　length :: a -> Int
　concat :: [a] -> a
　....

instance Stringable String
instance Stringable ByteString
instance Stringable UTF8String
instance Stringable UTF16String

なの？個々の文字はどうするんだ？
Charに32ビット使ってるのにUnicode(UCS4)のコードポイントそのまま使うんじゃないの？
つうか、リストじゃないの？そんなのありえるの？
0927デフォルトの名無しさん2007/03/14(水) 15:05:25
>>926
>個々の文字はどうするんだ？
http://darcs.haskell.org/SoC/fps-soc/Data/Stringable.hs
には、
class Stringable a where
  ...
  head :: a -> Char
  tail :: a -> a
  ...
というメソッドがある。

>Charに32ビット使ってるのにUnicode(UCS4)のコードポイントそのまま使うんじゃないの？
>つうか、リストじゃないの？そんなのありえるの？
何が言いたいか全然分からんｗ
もうちょっと詳しく。
0928デフォルトの名無しさん2007/03/14(水) 15:50:23
>>925
自分でコンパイルするとか
0929デフォルトの名無しさん2007/03/14(水) 19:59:59

Haskellの型推論って中の人どんなふうに動いてんの？

Javaにはそんな機能ないけど、
例えばプリミティブ型もIntegerとかにして、
ぜんぶをObject型で扱えば、なんでも突っ込めるようになるはずだけど、
それとはまったく違う？


0930デフォルトの名無しさん2007/03/14(水) 20:36:44
>>929
型推論と多相型をごっちゃにしてないか？
型推論は純粋にコンパイル時の操作で、一旦型が推論されたら、
明示的に型を書いた場合と全く同じようにコンパイルされる。
多相型の実装の話なら、その通りで、Javaのオブジェクトと同様あらゆる型をポインタを介して扱っている。
0931デフォルトの名無しさん2007/03/14(水) 20:44:47
Haskell の日本語の本２冊を一通りみたんだけど、
関数を返す関数が見当たらなかった？ような気がする。
Lisp 等だと普通に lambda を返す様な事をするけど、
0932ごめん。2007/03/14(水) 20:57:49
Haskell の日本語の本２冊を一通りみたんだけど、
カリー化された関数は作成してるけど、
無名関数を明示的に返す関数は無かったような気がする。
そんなのはあんまり書かないのかな？
0933デフォルトの名無しさん2007/03/14(水) 21:09:44
>>931
無名関数を明示的に返すくらいなら、最初からカリー化を利用して
引数を導入しておいた方が楽だからじゃないだろうか。
ただし、すでに名前の付いている関数を返すことはときどきある。
f :: Int -> Int -> Int -> Int
f 0 = (+)
f 1 = (-)
f 2 = (*)
とか。これの延長で無名関数を返すこともあるだろう。
f 3 = \x y -> if y == 0 then 0 else div x y
0934デフォルトの名無しさん2007/03/15(木) 00:52:08
>>927
勘違いしてたらスマンけど…。

Stringable aは、Stringable aであって[Char]じゃない
→リストじゃない→リストを扱う関数が使えないのでは？

UTF8Stringとかってエンコーディング処理が隠蔽されてるんだと思うけど、
今のStringの置き換えにするには、単純な[Char]に比べて性能遅そうな気が。

あと、エンコーディング毎に型が別ってのは、正しいのかも知れないけど、
コンパイル後に対応エンコーディングを増やすってどうやるの？

っていうか、ByteStringってエンコーディングは何？

と、疑問が山ほど。
0935デフォルトの名無しさん2007/03/15(木) 11:29:25
>>934
>Stringable aは、Stringable aであって[Char]じゃない
>→リストじゃない→リストを扱う関数が使えないのでは？
その通り。ただし
toString :: (Stringable a) => a -> String
fromString :: (Stringable a) => String -> a
は簡単に書ける。

>UTF8Stringとかってエンコーディング処理が隠蔽されてるんだと思うけど、
>今のStringの置き換えにするには、単純な[Char]に比べて性能遅そうな気が。
速度が多少犠牲になったとしても、空間効率が[Char]よりずっと良い。
[Char]だとGHCでは一文字あたり約20バイト必要だけど、UTF-8配列なら1〜4バイトで済む。

>あと、エンコーディング毎に型が別ってのは、正しいのかも知れないけど、
>コンパイル後に対応エンコーディングを増やすってどうやるの？
UTF*StringはあくまでStringの代替としての内部コードで、Stringの場合と同様に
入出力時にコード変換する使いかたが想定されているんだと思ったが、ちょっと自信がない。

>っていうか、ByteStringってエンコーディングは何？
本来のByteString(Data.ByteString.ByteString)はWord8の列なのでエンコーディングは関係ない。
ここで問題になってるのはたぶんData.ByteString.Char8.ByteStringで、これはLatin-1。
0936デフォルトの名無しさん2007/03/15(木) 12:13:27
＞[Char]だとGHCでは一文字あたり約20バイト必要だけど、

まじですか。
Charのデータ自体は4バイトだから、
リストノードひとつに１６バイトも必要なの？
でも、ポインタひとつ4(or8)バイト食えばそんなもん…か？

＞UTF-8配列なら1〜4バイトで済む。
UTF-8なら1〜6バイトではないかと。まあ20バイトの比ではないが。
0937デフォルトの名無しさん2007/03/15(木) 12:28:16
Stringのcons
  enter : 4bytes -- クロージャ進入関数へのポインタ
  Char : 4bytes -- headへのポインタ
  String : 4bytes -- tailへのポインタ
Char
  enter : 4bytes
  Char# : 4bytes -- コードポイント値
計20bytes

確かめたわけじゃないけど、これで実測と合う。

>UTF-8なら1〜6バイトではないかと。
Unicodeの範囲(0..0x10ffff)なら4バイト以下で表せる。
0938デフォルトの名無しさん2007/03/15(木) 12:56:40
>>935
Stringable.hsにはtoString, fromStringじゃなくて、toList, fromListが定義されてるのでわざわざ書く必要すらない。
名前が違うだけで型は全く同じ。

>>934
対応エンコーディングを増やすためには適当なデータ型を用意してStringableクラスのインスタンスにしてやればよい。

おおざっぱにはこんな感じ。

data MyString = MyString ByteString

instance Stringable MyString where
empty = MyString empty
head (MyString bs) = (bsから先頭1文字分取り出してChar型の値にして返す処理)
...
0939デフォルトの名無しさん2007/03/15(木) 13:16:51
> toList, fromListが定義されてるのでわざわざ書く必要すらない。

それはわかるけど、リストで使うときとStringableで使うときで
バンバンそんな変換してたら遅いじゃん？
メモリ節約どころの騒ぎじゃないじゃん？

> 対応エンコーディングを増やすためには適当なデータ型を用意してStringableクラスのインスタンスに

そう言う事じゃなくて、プログラムとして、エンコーディングをpluggableに出来ないじゃんと。
例えば、Stringable を使って作られたエディタが配布されてるとする。
そのエディタに対して、対応エンコーディング追加プラグインみたいのが作れないのでは、という事。
あるいはプラグインでなくてもいい。
そのエディタ作者は英語しか出来ずStringableで書いても、入出力はLatin-1しか考えてない。
で、これを作者が存在すらしらない、SJISString, EUCJPString, Big5String みたいのを扱えるようにするには、
どうすればいいの？毎回ソース書き換えてリコンパイル？
0940デフォルトの名無しさん2007/03/15(木) 14:04:02
リスト的な操作をするときにいちいちリストに変換してやるわけじゃないんだけど。
mapとかfoldrとかいった操作は効率の良い定義に置き換えることも出来るようになってる。

pluggableに関しては、今のStringable.hsはそういう作りになってないんだから、書き換えてリコンパイルするしかないじゃん。
0941デフォルトの名無しさん2007/03/15(木) 14:11:15
>それはわかるけど、リストで使うときとStringableで使うときで
>バンバンそんな変換してたら遅いじゃん？
リストとして使いたいなら従来どおりStringを使えば良い。
そのためのinstance Stringable String。
0942デフォルトの名無しさん2007/03/15(木) 17:41:28
リスト一般用の便利なライブラリと、
Stringable用の便利なライブラリがあるとき、
変換せずに両方混在させて使える？

pluggableは、String以前に、Haskellでそもそも可能なの？
コンパイル時に知らないsubtype（クラスのインスタンス）を、
動的にファーストクラス値で指定してロードってできるんだっけ？
0943デフォルトの名無しさん2007/03/15(木) 17:49:20
>リスト一般用の便利なライブラリと、
>Stringable用の便利なライブラリがあるとき、
>変換せずに両方混在させて使える？
使える。Stringはリストであると同時にStringableなので。
0944デフォルトの名無しさん2007/03/15(木) 18:25:47
Haskellは実装の多重継承がokなんだな。
いわゆるダイヤモンド継承問題はどうなってるんだろう？
0945デフォルトの名無しさん2007/03/15(木) 18:49:02
Haskellに実装の継承に相当する機能なんてあったか？
0946デフォルトの名無しさん2007/03/15(木) 21:16:41
これが噂のオブ脳
0947デフォルトの名無しさん2007/03/15(木) 23:51:15
>>943
話の流れからして、StringじゃなくてUTF8Stringとかでそれが出来るかって話だと思うが。
0948デフォルトの名無しさん2007/03/16(金) 00:36:24
>>947
どこをどう読むとそういう話になるんだ？
ともあれ、UTF8Stringはリストじゃないので、リスト操作関数は使えない。
0949デフォルトの名無しさん2007/03/16(金) 02:05:56
>>937
クロージャ進入関数って？
データが関数のポインタを保持するの？
0950デフォルトの名無しさん2007/03/16(金) 02:08:59
結局の所 http://darcs.haskell.org/SoC/fps-soc/Data/Stringable.hs を読めってことになるんだが、
UTF8StringとかのStringableな型ではmap,take,foldrとかのリスト操作的な関数がデフォルト定義として与えられている。
だけどPreludeの同名の関数たちとは型が違うから、単にimport Data.Stringableとすると衝突してしまう。
なので、実際に使う時はimport qualified Data.Stringable as S みたいにして、
Stringable用の関数は S.map, S.take, S.foldr のようにS.を付けて使うことで衝突を回避する。
0951デフォルトの名無しさん2007/03/16(金) 02:40:48
>>949
Haskellではデータ構造の一部が未評価のことがあり得るので、
評価用の関数ポインタを保持せざるを得ない。

>>950
基本的な関数はStringableクラスにもあるけど、
リストにしか対応していないライブラリも多い(例えばParsecとか)。
「リスト操作関数」という言い方が悪かったか。
0952デフォルトの名無しさん2007/03/16(金) 03:03:53
Parsecが使えない文字列なんて…。
っていうか、Stringableとリストのクラスを作るんだよね？(:)とかheadとかtailとか++とか!!とか。
それでも現行のリスト用ライブラリは使えないけど、じきに対応してくれるのを待つ、と。
でも構文的な問題が厳しいか。
0953デフォルトの名無しさん2007/03/16(金) 03:29:21
>>952
>Parsecが使えない文字列なんて…。
何を問題視しているのかさっぱり分からん。
従来ファイル名にはStringしか使えなかったのを、Stringableのインスタンスならどれでも
使えるようにしよう、という互換性を保った拡張であって、Stringで満足しているなら
Stringを使いつづければ良いんだが。
0954デフォルトの名無しさん2007/03/16(金) 03:56:39
Haskell ぼろぼろじゃん
0955デフォルトの名無しさん2007/03/16(金) 09:22:14
コンストラクタになる関数とパターンマッチで使う逆関数を用意したら既存のdataが拡張できるような仕組みがあればいいのに
遅そうだけど
0956デフォルトの名無しさん2007/03/16(金) 09:32:26
extendedList :: (a -> b -> b) -> b -> (b -> Maybe (a, b)) -> (b -> [a], [a] -> b)
extendedList cons nil match = (forth, back)
  where
    forth = unfoldr match
    back = foldr cons nil
0957デフォルトの名無しさん2007/03/16(金) 18:18:58
>>953
　　　　　　　　　　非Latain-1　　リストベースライブラリでの使用
String 　　　　　　×　　　　　　　　　○
Stringable 　 　　○　　　　　　　　　×
望まれる物　　　○　　　　　　　　　○

例えば、（メモリ効率の改善はなくなるが）
バイト列とStringの変換関数だけを提供するという解も有り得るかと。

あるいは、Stringableの方向性でいくなら、
Stringableをリストの「インスタンス」にするか、それが無理なら
リストとStringableを包含したクラスを作って、リストの構文でも扱えるようにすれば、
リストベースライブラリもわずかな修正とリコンパイルだけでStringableでも使用できるようになるのでは？
0958デフォルトの名無しさん2007/03/16(金) 19:26:12
>>957
・Stringという型とStringableというクラスを比較するのはおかしくないか？
・Stringでも非Latin-1の文字は使える。

俺ならこういう表にする。

　　　　　　　Parsec(リストのみ)　現行IO(Stringのみ)　　提案IO(Stringable)
String 　　　　　　○　　　　　　　　　　　○　　　　　　　　　　　　　○
UTF8String 　 　×　　　　　　　　　　　×　　　　　　　　　　　　　○
[Word8]　　 　　　○　　　　　　　　　　　×　　　　　　　　　　　　　×

>>917のリンク先の提案は、「IO」という縦の列の改善提案であって、
例えばUTF8StringがParsecで使えるかどうかとは関係ない話だと思うが。
「リスト的なコンテナ」を表現する型クラスがあっても良いとは思うけど、
それは少なくとも>>917とは別の話題だと思う。
0959デフォルトの名無しさん2007/03/17(土) 03:53:19
とすると、>>917が>>914-916とは別の話題だったということか。

それはともかく、
・Haskell(Hugs/GHC)自体は、FPSは関係なく、ちゃんと
　CharにUnicodeコードポイントを(1byteずつに分けずにまるごと)入れて、
　readFileとかputStrとかが適切にデコード・エンコードしてくれる方向
・ＦＰＳは、それとは直交して、
　効率の良いString(able)クラスを作ろうとしていて、
　エンコーディングも扱う
と理解してＯＫ？

しかし、せっかく作るStringableだが、
Parsecなどのリストベースのライブラリで使えないというのは、勿体ないとは思わない？
リスト派とStringable派にライブラリが分裂しちゃうじゃん。無駄じゃん。

文字エンコーディング機能が、
readFileとかの関数と、Stringableのインスタンスの両方に実装されるのも
DRYじゃないし、テキストを扱う流儀の分裂を招く。
0960デフォルトの名無しさん2007/03/17(土) 10:09:28
ByteStringでもPersecを使えるようにしようって話もあるみたい。
http://hackage.haskell.org/trac/summer-of-code/ticket/59
0961デフォルトの名無しさん2007/03/17(土) 12:27:33
>>959
>とすると、>>917が>>914-916とは別の話題だったということか。
いや、>>917はGHCのIOライブラリを作りなおそうという話であって、Stringableの提案は
その一部に過ぎない。ので全体としては関係あると思う。

>しかし、せっかく作るStringableだが、
>Parsecなどのリストベースのライブラリで使えないというのは、勿体ないとは思わない？
>リスト派とStringable派にライブラリが分裂しちゃうじゃん。無駄じゃん。
確かに。

>文字エンコーディング機能が、
>readFileとかの関数と、Stringableのインスタンスの両方に実装されるのも
>DRYじゃないし、テキストを扱う流儀の分裂を招く。
これは仕方ないような。readFileがやるのは
外部エンコーディング <-> 内部エンコーディング
の変換で、例えばUTF8Stringが行うのは内部エンコーディング間の変換。
0962デフォルトの名無しさん2007/03/17(土) 15:46:20
よくわからんけど
(:)とか[]は
Stringableじゃ使えないのか。
0963デフォルトの名無しさん2007/03/17(土) 16:09:48
例えばUTF8Stringな s に対して 'a':s みたいなことは出来ない。
0964デフォルトの名無しさん2007/03/17(土) 16:25:48
Stringableとリストを共通クラス化しておかないと、
リストを使った実装群と、Stringableを使った実装群に分断される。

将来絶対、混乱や重複実装の元になって問題になるだろ。どうにかしろよ。
0965デフォルトの名無しさん2007/03/17(土) 16:29:23
リスト系関数使えないってかなりまぬけだ
0966デフォルトの名無しさん2007/03/17(土) 16:37:47
はぁ？頭悪い人か
0967デフォルトの名無しさん2007/03/17(土) 16:42:27
>>946
　>>944＝Tucker!
　C++が最高だと思って相手構わず噛み付く痛い人だから
　相手にしなくておｋ

　monadic programming の主旨も理解できてないレベル
0968デフォルトの名無しさん2007/03/17(土) 16:42:50
>>966
使えるのか？
同名の関数があるってオチは無しだぜ？
0969デフォルトの名無しさん2007/03/17(土) 17:30:30
> Stringableとリストを共通クラス化しておかないと、

一応リストっぽい操作を持つ型構築子クラスとしてはData.Foldableってのがある。GHC 6.6で追加された。
ただ、これを使ってUTF8StringをFoldableのインスタンスにすることはできない。
なぜならUTF8Stringは型であって型構築子ではないから。
一旦type UTF8String = UTF8StringC Charみたいなものを考えて
UTF8StringCをFoldableのインスタンスにすることは出来るだろうけど、それってどうなんだろう。
0970デフォルトの名無しさん2007/03/18(日) 03:55:42
型はそれで一応解決？としても、
　:　と [] は言語仕様の方に手を入れるしか。
[]は単なる糖衣としても、 : は？
0971デフォルトの名無しさん2007/03/18(日) 09:58:34
>>969
それだと、UTF8StringC Doubleなんていう型を作れることになるな。
まじめにリストをクラス化するとしたらこうだろう。
class List container element | container -> element where
  nil :: container
  cons :: element -> container -> container
  match :: container -> Maybe (element, container)
  ...
で、
instance List [a] a
instance List UTF8String Char
...
しかし、これってやるに値することなのかな。
型クラスを介して操作するなら、コストの点ではリストに変換してしまうのと大差ないような。
0972デフォルトの名無しさん2007/03/18(日) 10:24:52
うん、そういう変なのが作れちゃうからどうなんだろうって思った。

> class List container element | container -> element where
関数従属って全然使ったことないから思いつかなかったな。
0973デフォルトの名無しさん2007/03/18(日) 11:47:29
これはとんだコードは簡潔だけど記述するのに30倍くらい時間のかかる糞言語ですね
0974デフォルトの名無しさん2007/03/18(日) 11:54:27
>>973
どういうコードを書いているかにもよるが、Haskellじゃなくて
お前が糞である可能性も十分にあると思う。
特に、コードが簡潔なのに書くのに時間がかかる場合、
不慣れなだけな可能性が高いかと。
0975デフォルトの名無しさん2007/03/18(日) 12:06:33
馬鹿を寄せ付けない言語として最強
馬鹿はJavaでもやってろｗｗｗｗｗｗ
0976デフォルトの名無しさん2007/03/18(日) 14:36:27
>>971
>型クラスを介して操作するなら、コストの点ではリストに変換してしまうのと大差ないような。

Stringableも型クラスじゃん。違うの？
どうせ型クラスなら、分断と混乱を防いだ方が良いと思うけど。
0977デフォルトの名無しさん2007/03/18(日) 15:21:01
デフォルト定義をそのまま使うならコストがかかるかも知れないけど、
それぞれの型に最適化した定義で上書きできるからあんまり問題ないと思う。
0978デフォルトの名無しさん2007/03/18(日) 15:58:03
>>976
>Stringableも型クラスじゃん。違うの？
だから俺は今のままのStringableなら要らないんじゃないかと感じている。

>どうせ型クラスなら、分断と混乱を防いだ方が良いと思うけど。
何か混乱してないか？
*型*が乱立すると確かにまずい。ライブラリAが型Tを使い、
ライブラリBがTと似た型T'を使い、しかもTとT'が相互変換できないなら、
AとBとの間に互換性がない訳で、早急に解決すべき問題だ。
一方、*型クラス*の乱立はそんなに深刻じゃない。
ライブラリAがクラスCを使い、ライブラリBがクラスC'を使ったとしても、
CとC'の両方のインスタンスであるような型Uがあれば、Uを使って
AとBを併用できる。つまり相互運用性が保たれる。
型クラスの乱立はない方が良い(コードの重複を招くので)けど、
できてしまったものはしかたないし、躍起になって防ごうとするほどのものでもないと思う。

例えば、提案通りIOライブラリにStringableが採用されたとする。
これでUTF8StringをIOライブラリで使えるようになるが、まだParsecでは使えない。
さらに将来のある時点で、Parsecが>>971のようなクラスを採用したとする。
これでUTF8StringがIOでもParsecでも使えるようになる。
でも、このとき、Stringableを使って書かれたコードを変更する必要はない。
StringableクラスとListクラスは共存できる。
こういう風に、クラスは後付けでもなんとかなるのが特徴だと思う。
0979デフォルトの名無しさん2007/03/18(日) 16:00:09
関数の動的バインディングのコストを言ってるんじゃないの？
HaskellというかGHC?で、この辺どうなのか全然知らないけど。
まあ、Stringableも型クラスなら変わらないから関係ないと思うけど。

誰か、>>971を連中に提案してくれよ。
Stringable should be "List', othewise it shall bring about a civil war in Haskell applications.
みたいな。


でも、>>971じゃ、[] 記法や : でのマッチが解決しないな。
これをStringableでも使えるようにしないとあかんな。
0980デフォルトの名無しさん2007/03/18(日) 16:05:02
リストとして扱えないだけで嫌なんだけど
0981デフォルトの名無しさん2007/03/18(日) 16:09:42
>>>978
解説ありがとう。

>こういう風に、クラスは後付けでもなんとかなるのが特徴だと思う。

なるほど。急ぐ必要はないのか。
でも最初というか早い内からあった方が良いよね？共通クラス。

あと、リストの場合は型の問題（≒関数・演算子の問題）の他、
[]記法と : のマッチの問題があるんじゃない？

それもListクラス導入時に同時に解決すべき問題で急ぐ必要はないのかも知れないけど。
0982デフォルトの名無しさん2007/03/18(日) 16:10:27
>>980
何を批判しているのか明確にしてくれ。
リストを使うのを妨げるような変更は一切話題になっていないと思うんだが。
0983デフォルトの名無しさん2007/03/18(日) 16:11:53
>>982
>>981の
> []記法と : のマッチ
をStringableでも使いたいと言うことでは？
0984デフォルトの名無しさん2007/03/18(日) 16:19:03
hoge (x:xs) = fuga x : hoge xs
をStringableでもやりたいって事かと。
実際、リスト処理はこれで書かれてると思うし。

ただ、[]は不要かな？新規にデータ構築する時だけだし、
文字列処理ではあんま使わないかも？リストが出来るだけで問題ないかも。
0985デフォルトの名無しさん2007/03/18(日) 16:31:37
(:)と[]を変えるなら言語に手を入れなきゃならんからな。
>>971みたいなのを導入するならコードの書き換えが前提だと思ってたが。
0986デフォルトの名無しさん2007/03/18(日) 16:35:29
屁理屈をこねだす初心者は
学習が全然進まない、という好例だな。
0987デフォルトの名無しさん2007/03/18(日) 16:41:07
(:)と[]はリストのデータ構築子だからねぇ。
共通クラスに準拠させるんならhead,tail,foldrとかを使って書いてねって話しになると思う。

hoge [] = []
hoge (x:xs) = fuga x : hoge xs
は
hoge = foldr fuga empty
もしくは
hoge = map fuga
でOK
0988デフォルトの名無しさん2007/03/18(日) 16:45:11
間違えた。
hoge = foldr (\x y -> cons (fuga x) y) empty
じゃないと型が合わない(^^;
0989デフォルトの名無しさん2007/03/18(日) 16:51:08
hoge (x:xs) = fuga x : hoge xs
は、
データ構造の実装を直接触る、汚い・忌むべきコードなんだよ！
hoge xs = cons (fuga.head xs) $ hoge.tail xs
みたいにちゃんと関数で書くべきなんだ！！

もちろん、
bar Just a　 = foo a
bar Nothing　= baz
もダメダメだ！！！
0990デフォルトの名無しさん2007/03/18(日) 16:58:30
それじゃ結局分断は避けられないじゃん。
それとも、>>989みたいな考え方を浸透させて、
hoge (x:xs) = fuga x : hoge xs
みたいのは非推奨にするの？言語として良い解なのかな、それ？
0991デフォルトの名無しさん2007/03/18(日) 17:10:46
Haskellの特長であるパターンマッチングを捨てるのか。
MLに敗北するのか。
0992デフォルトの名無しさん2007/03/18(日) 17:32:19
敗北厨かよ・・・
0993デフォルトの名無しさん2007/03/18(日) 18:01:48
今のHaskellの仕様だとどんなに型クラスとかをいじくりまくってもUTF8Stringをx:xsにパターンマッチさせることは出来ない。
仕様自体を変更しないと無理。
0994デフォルトの名無しさん2007/03/18(日) 18:05:48
あちゃー
もう文字列をリストで表現できるとか他言語に自慢できないのね
0995デフォルトの名無しさん2007/03/18(日) 18:26:34
パターンマッチがデータ構造の実装を直接触ってるとか
痛いことを言ってる人がいるようだが……

関数型言語からパターンマッチを取ったら、データには関数を通してしかアクセスできなくなり
凡百のオブジェクト指向言語並みの地位に堕するだけだ。
レス数が950を超えています。1000を超えると書き込みができなくなります。