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

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

レス数が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の仕様により、行頭の半角スペースは表示されません。
　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。
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
パターンマッチがデータ構造の実装を直接触ってるとか
痛いことを言ってる人がいるようだが……

関数型言語からパターンマッチを取ったら、データには関数を通してしかアクセスできなくなり
凡百のオブジェクト指向言語並みの地位に堕するだけだ。
0996デフォルトの名無しさん2007/03/18(日) 18:30:02
その犯人は、Stringableな訳だが。
0997デフォルトの名無しさん2007/03/18(日) 18:32:00
Stringable どう考えてもダメだろ
0998デフォルトの名無しさん2007/03/18(日) 18:42:09
いや、Stringableの様なのをあるべき形でうまく実現できない言語仕様がダメだろ。
0999デフォルトの名無しさん2007/03/18(日) 18:42:19
それよりも次スレ立てないとダメだろ
1000デフォルトの名無しさん2007/03/18(日) 18:42:52
1000取らないとダメだろ
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。