1001コメント379KB

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

■ このスレッドは過去ログ倉庫に格納されています

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の仕様により、行頭の半角スペースは表示されません。
　コードをインデントしたいときは、代わりに または全角スペースを使うことができます。

0360デフォルトの名無しさん

2006/12/22(金) 01:04:25

>>359
そのぷろぐらむだと引数は関係ない。
outを実行すると入力待ちになるから、適当な文字列を何行かタイプする。
入力を終了したくなったら、まず、カーソルが行頭にある状態で
Ctrlとzを同時押しして(^Zという表示が現れるはず)、
つぎにEnterキーを押せば良い。

0361デフォルトの名無しさん

2006/12/22(金) 08:44:55

>>357 どっちもイイね。
Haskell の優れてるところ：型システムによる安心感、純粋関数型なところ
Lisp の優れてるところ: マルチパラダイムなところ、あんま理屈とか考えずに言語を気軽にカスタマイズできるところ

0362デフォルトの名無しさん

2006/12/25(月) 11:44:14

>>357
使い方次第

0363デフォルトの名無しさん

2006/12/25(月) 18:05:58

>>362
日本語でおk

0364デフォルトの名無しさん

2006/12/25(月) 20:14:12

>>361
Haskellの優れているところ：遅延評価、モナド

0365デフォルトの名無しさん

2006/12/25(月) 22:18:13

Haskellの劣っているところ：遅延評価、モナド

0366デフォルトの名無しさん

2006/12/25(月) 23:05:14

遅延評価は言語の進化過程で最新の部類だぞ・・

0367デフォルトの名無しさん

2006/12/25(月) 23:19:58

モナド(というかdo記法)大好き。
優れているかは別として、Haskellでいちばん好きな機能かも。

0368デフォルトの名無しさん

2006/12/25(月) 23:59:33

なにが遅延評価だ
ここはもうﾋﾞﾁｮﾋﾞﾁｮじゃねーか

0369デフォルトの名無しさん

2006/12/26(火) 00:21:36

>>367
doは>>=を使うよりも見栄え良く書けるが、
代入型言語の特徴を残す記法なので、
不満に思う人も多いと思う。

0370デフォルトの名無しさん

2006/12/26(火) 00:54:35

>>369
似たような意見をwebで時々見掛けるが、よく理解できない。
命令的プログラミングをしたいとき、それに適した構文を
使えるのだから、単純に良いことのように思える。
それとも、命令的プログラミングをサポートしない言語の方が
良いという考えなんだろうか。

0371デフォルトの名無しさん

2006/12/26(火) 01:29:44

>>370
「関数」で統一された世界を作れば、何か良いことがあるに違いない
（古風な言い方である自動プログラミング、とか、構造の視覚化がしやすくなる、とか、etc..）
と思う人が多いからじゃないかな？

0372デフォルトの名無しさん

2006/12/26(火) 01:31:33

>>352
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

0373デフォルトの名無しさん

2006/12/26(火) 02:48:41

自分はどするよりコンビネータでモナモナする方がいいな。

0374デフォルトの名無しさん

2006/12/26(火) 14:22:41

どするって流行らせたいの？w

0375デフォルトの名無しさん

2006/12/26(火) 22:44:22

>>=は横に長くなっちゃうのがいまいちだけど、見た目がかっこいいからついつい使ってしまう

0376デフォルトの名無しさん

2006/12/27(水) 00:03:09

do {
a <- hoge;
hoge2 a;
hoge3 a
}

と

hoge >>=
\a ->
hoge2 a >>
hoge3 a

どっちがみやすいですか？

0377352

2006/12/27(水) 01:44:38

>>372
この記事おもしろいねｗ

真実だとしても、結局のところ今はＰＣの性能の上昇とか
言語自体の進化によってオブジェクト指向は機能的で合理的な言語になってるよね？

たしかに、
「あるプロジェクトのコードを再利用した話なんて聞いたことない」とか、
「正しく継承させるためには設計だけでＣの3倍もの時間かかる」とか、
超笑えるねｗ

当たり前に思ってきた（教えられてきた）コトって、
そのまま信じちゃうからこういう記事読むとオラ、ワクワクしてきたぞ

0378デフォルトの名無しさん

2006/12/27(水) 02:04:04

Haskellだと10倍の時間をかけて10分の1の行数ですみます。

0379デフォルトの名無しさん

2006/12/27(水) 02:05:25

数十万行のsoftware開発してきた身からすると
あの内容はあながち冗談に思えなくて泣けてきた。
彼がinterviewであんなこと言うはずは無いだろうけどさ

0380デフォルトの名無しさん

2006/12/27(水) 02:32:15

>>378
ﾁｬｯﾁｬと書けるようになったらダイブ頭よくなってるかな？

0381デフォルトの名無しさん

2006/12/27(水) 03:01:21

何を創ったかによるだろ

0382デフォルトの名無しさん

2006/12/27(水) 03:12:31

だよなー
もっとHaskeりたいんだけど、やさしく教えてくれるかわいいコいないかな

0383デフォルトの名無しさん

2006/12/27(水) 03:14:55

ｷﾞｬﾙにHaskellは引かれるだけ
禁句だ。

0384デフォルトの名無しさん

2006/12/27(水) 22:11:40

アホか
Haskellを教えてくれるギャルを探すんだよ

0385デフォルトの名無しさん

2006/12/27(水) 22:47:06

　　　　　　　　　 ∩
　　　　　　　　　 | |
　　　　　　　　　 | |
　　　　　 ∧＿∧ 　 | |　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　´Д｀）／/　＜　⊥が返ると思います！
　　　　　／　　　 /　　　＼　　　　　　　　
　　　　 / /|　　　　/ 　　　　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　＿＿| | .|　　　　|
　＼　￣￣￣￣￣￣￣＼
　　||＼　　　　　　　　　　　＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　　 .||　　　　　　　　||　

0386デフォルトの名無しさん

2006/12/30(土) 22:17:23

正直、Haskellってオサレだと思うんだけどなぁ。
少なくともVBやJavaやってるよりは確実にイケテルよね？

モナドとかラムダとか遅延評価について語るだけでモテモテな世の中になればいいのに。

0387デフォルトの名無しさん

2006/12/30(土) 22:50:41

>>386
俺もそう思う。

思いたい。

0388デフォルトの名無しさん

2006/12/30(土) 23:04:43

HaskellとConcurrent Cleanはオサレ言語だと思う。思いたい。思わせろ。

普段は泥臭いPerl使ってる俺は死んだらいい。

0389デフォルトの名無しさん

2006/12/30(土) 23:06:56

オサレって言葉はいつから誉め言葉になったんだ？

0390デフォルトの名無しさん

2006/12/30(土) 23:47:59

俺的な言語の分類。主観のみで書いたので脊髄反射は厳禁ｗ

■オサレ言語
Haskell、Clear、その他の純粋関数型言語

■普通の言語
C、C++、C#、アセンブラ、PHP、Perl、awk

■キモい・胡散臭い
Ruby（特にRails界隈）、Ajax、XML、Paython、その他Web2.0に絡む言語すべて

■オッサン専用
COBOL、FORTRAN、PASCAL

■厨言語
Java、VB、BASIC、HSP

0391デフォルトの名無しさん

2006/12/31(日) 00:07:22

lispわー？

0392デフォルトの名無しさん

2006/12/31(日) 01:02:19

>390を勝手に書き換えてみる

■オサレ言語
Haskell、Concurrent Clean、その他の純粋関数型言語

■普通の言語
C++、C#、Java、VB.NET

■泥臭い
Perl

■ハッカー専用
C、アセンブラ、awk、Python

■キモい・胡散臭い
PHP、Ruby

■オッサン専用・過去の遺物
COBOL、FORTRAN、PASCAL

■厨言語
VB、BASIC、HSP、Delphi

■宗教
Lisp、その他Lisp系統

0393デフォルトの名無しさん

2006/12/31(日) 01:06:40

coolLang = [Lisp, Scheme] :: [Language]

0394デフォルトの名無しさん

2006/12/31(日) 01:49:49

(set! coolLang (cdr coolLang))

0395デフォルトの名無しさん

2006/12/31(日) 09:30:38

最近になって Haskell を触り始めたんだけど、
C で言う != みたいな記号ってないん？

環境は WinHugs 使ってる。

0396デフォルトの名無しさん

2006/12/31(日) 10:37:39

>>390
HSPは胡散臭い言語だと思います。

0397デフォルトの名無しさん

2006/12/31(日) 10:43:32

>>395
(!=) :: Eq a => a -> a -> Bool
(!=) = (/=)

0398デフォルトの名無しさん

2006/12/31(日) 13:12:31

Rails は確かに胡散臭い
あと perl はなにげにハッカー言語だと思う

0399デフォルトの名無しさん

2006/12/31(日) 13:25:47

>>398
ハッカーが「つくっている」≠ ハッカー言語

0400デフォルトの名無しさん

2006/12/31(日) 13:35:02

いや、ハッカーが使う言語ってのは泥臭いものだよ
そう言う意味で C やアセンブラは納得できるけど Python はどうかなぁ

0401デフォルトの名無しさん

2006/12/31(日) 16:51:27

>>400
http://www.sauria.com/~twl/conferences/pycon2005/20050325/Python%20at%20Google.html

0402デフォルトの名無しさん

2006/12/31(日) 19:23:05

Haskellって日本語を表示させたりは出来ないんでしょうか?
main = putStrLn "こんにちは!"ってやるとエラーになるんですけれど・・・
あきらめるしかないんでしょうか?

0403デフォルトの名無しさん

2006/12/31(日) 22:24:01

>>397
ありがとう

0404デフォルトの名無しさん

2007/01/01(月) 10:53:25

GHC 6.6 で部分的に UTF-8 に対応したみたいだけど、
putStrLn とかはまだ未対応みたいね。

0405デフォルトの名無しさん

2007/01/01(月) 13:46:12

>>402
Hugsだと動く。

0406デフォルトの名無しさん

2007/01/01(月) 23:29:56

日本語を出力できないのかよ!って思ったけど、プログラムにべた書きしてある場合がだめなのね。

0407デフォルトの名無しさん

2007/01/01(月) 23:41:17

>>402
EUC環境なら普通にできるよ。

0408402

2007/01/02(火) 00:02:38

みなさん、ご返答有難うございます。
>>405
ネイティブなバイナリを作りたいんです。
>>406
標準入力から入力した文字を処理させたいんです。
出来るでしょうか?
>>407
windowsマシンしか持ってないんです・・・

0409デフォルトの名無しさん

2007/01/02(火) 00:23:32

> 標準入力から入力した文字を処理させたいんです。
ただのバイト列としての扱いになるけど一応読み込めて表示できる。

0410デフォルトの名無しさん

2007/01/02(火) 14:03:50

>>406
逆。プログラムには埋め込めるけど入出力ができない。

>>408
http://yogimo.sakura.ne.jp/ssc/index_ja.html
外部ライブラリだけど、とりあえず日本語の入出力はできる。

0411デフォルトの名無しさん

2007/01/02(火) 16:04:51

なんか混乱気味だなぁ。

GHC6.4ではEUCだったらソースコード中に書いてもコンパイル可能。
putStrなどで出力するとEUCのまま出力される。
そのため、WindowsではEUC→ShiftJIS変換を掛けた後putStrしないとうまく表示できなかった。

GHC6.6ではソースコードの文字コードがUTF-8になったため、
UTF-8形式でなら日本語の文字列をソースコードに記述できるようになった。
しかし、putStrなどのIOの基本部分はまだきちんとUTF-8対応してないため、
UTF-8形式の文字列をそのまま出力させることができない。
ただ、6.4のときと同じようにUTF-8→ShiftJIS変換して出力させるのなら表示できる。
410が紹介しているライブラリはそう言った処理を行ってくれる。

0412デフォルトの名無しさん

2007/01/02(火) 17:48:11

この問題はややこしいし、よく出てくるから、テンプレに入れるのがいいと思う。
間違ってるところがあったら指摘してほしい。

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でリテラルを直に
書くことはできない。

(続く)

0413デフォルトの名無しさん

2007/01/02(火) 17:49:24

(続き)

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)が正しく動作しない。

0414デフォルトの名無しさん

2007/01/03(水) 00:32:02

ttp://d.hatena.ne.jp/ha-tan/20070101/1167710733
ttp://d.hatena.ne.jp/ha-tan/20070102/1167722751
このあたりも。

0415デフォルトの名無しさん

2007/01/03(水) 01:24:37

お前ら、開発に加わって連中に国際化を教えてやってください

0416デフォルトの名無しさん

2007/01/03(水) 02:49:12

ずーっと昔のemacsとかXwindow systemみたいだねぇ。

0417デフォルトの名無しさん

2007/01/03(水) 10:33:09

GHCのコアな開発者(少なくともSimon Marlow)は問題を理解してるよ。
問題はむしろSystem.IOを書き直すのが(重要度の割には)面倒だ、というところに
あるんじゃないかと。

0418デフォルトの名無しさん

2007/01/03(水) 11:02:51

質問です。
1関数とアクションは何が違うのでしょうか?
2square n = n*n
というのはnを引数とする関数を定義しているんですよね。
cみたいにn = n*nという代入を表しているんじゃないですよね?(説明が難しい)

0419デフォルトの名無しさん

2007/01/03(水) 12:00:08

>>418
1. アクションとはIO aを返す関数のことです
2. まずは、squareの型を見てみましょう。
square :: Num a => a -> a
ということですから、代入ではありません。

0420デフォルトの名無しさん

2007/01/03(水) 12:00:50

"IO a"は型ね。

0421デフォルトの名無しさん

2007/01/03(水) 12:09:36

1. アクションは副作用を含むことのできる一連の処理を値（IO a 型）として返す関数。
　 main 関数の返す値が最終的に実行される。
　 Perl や JavaScript で、プログラムを内部的に文字列として生成して、
　最後に eval で実行するような状況に少し似てる。

2. 関数 square n と n*n とが等値であることを定義しているだけ。
　数学では = ってのは左辺と右辺が等しいことを表すよね。
　 x + 2y = 4 とか、f(x) = 2x + 1 とか。あれと同じ。

0422デフォルトの名無しさん

2007/01/03(水) 12:13:31

>>419
>アクションとはIO aを返す関数のことです
アクション(動作)はIO a型の値のことじゃないか？
たとえばputStrは文字列を取って動作を返す関数。
putStr "Hello"は動作。

0423デフォルトの名無しさん

2007/01/03(水) 12:48:55

>>422
プログラミング指向の論文を読んでいると、
引数または返値に"IO a"を含むものをfunctionとは呼ばずにactionと呼んでいる事が多いので、
そう書いたんだよ。

0424デフォルトの名無しさん

2007/01/03(水) 12:50:08

あ、ごめん、>>422の方が正しそう

0425デフォルトの名無しさん

2007/01/03(水) 13:05:45

皆さん回答有難うございます。
代入ではないんですね。
どうも混乱してしまって・・・
cでいう
# include <stdio.h>
int main (void)
{
int y = 0;
y = sqare(3);
printf("%d\n",y);
}
int sqare (int n)
{
n = n*n;

return n;
}
のn = n*n;とは別なんですよね?

0426デフォルトの名無しさん

2007/01/03(水) 13:10:07

アクションのことはおっしゃってることは良く分からないですけど
IOっていうのが味噌なんですね。
それとｃのプログラム、関数宣言してないですけど、許してください。

0427デフォルトの名無しさん

2007/01/03(水) 13:41:21

>>425
意味的には似てるけど、
たとえば、Cではsquare(2)とすれば、それがその場で実行されて4という値として扱われるけど、
Haskellでは(square 2)そのものとして扱います。

まず、IO a -> a という事はできません(IOがいったんくっついたら取り外すことはできないの）ので、
Haskellではmainを評価することで実行されますが、
最終的にはmainまで … -> IO aというのを続けて書いていかないとダメなの。
main関数の型は main :: IO () ですよね。

0428デフォルトの名無しさん

2007/01/03(水) 13:42:50

>>425
square n = n * n
に近い書き方は、
int square(int n) { return n*n; }
だね。

逆に、
int sqare (int n) { n = n*n; return n; }
に近いのは
square n
= let m = n * n
　　in m

0429デフォルトの名無しさん

2007/01/03(水) 22:39:29

func x = func x
main = do func 1

これ ghc だと通ったんですけど、この場合の func の型は何ですか？

0430デフォルトの名無しさん

2007/01/03(水) 23:54:51

t -> t1

0431デフォルトの名無しさん

2007/01/04(木) 00:50:26

>>422
よく参照されるやさしい Haskell 入門ですら、
関数自身の事を表す事もあれば、値を表す事もあるんだよな。
http://www.sampou.org/haskell/tutorial-j/io.html

例えば、7.1 の最初の文
＞各 I/O のアクションはそれぞれ値を返します
は関数自身をアクションと呼んでるように見えるし、
その直後の
＞これはアクションを他の値と区別するためです
は値をアクションと呼んでるように見える。

どちらもアクションと呼ぶのか、それともいい加減なだけなのか。
どっちなんだろ？

>>425
square n が n * n と等値。
無意識に square と n の間に理解の区切りを設けてるみたいだけど、
そんなものはないと考えた方がいい。

0432425

2007/01/04(木) 16:24:19

うぉー、皆さん回答本当に有難うございます。
square n = n*nは理解できました!
関数squareは仮引数nを一つとる関数で、その本体はn*nという理解でよいんですね。
関数とアクションの違いは、まだ勉強不足で理解は出来ていないですけど、
IOが味噌なのは分かりました。
話は変わりますけど、文字列が文字のリストなんて、HaskellはCみたいですね。

0433デフォルトの名無しさん

2007/01/04(木) 18:40:30

リストと配列は違うよ。

0434デフォルトの名無しさん

2007/01/05(金) 14:06:19

>>433
すいません、配列とリストって何が違うのでしょうか?
調べてみたんですが良く分かりませんでした。
例えば
# include <stdio.h>
int main (void)
{
char *string = { "Hello"};

printf("%c\n",string[2]);

return 0 ;
}
みたいにリストって言うのは、配列とポインタの組み合わせとその操作と思っていたんですけれど
違うのでしょうか?

0435デフォルトの名無しさん

2007/01/05(金) 14:27:30

Lisp以前の問題

0436デフォルトの名無しさん

2007/01/05(金) 15:04:12

>>434
Haskellでいうリストは「単方向リンクリスト」のこと。

0437デフォルトの名無しさん

2007/01/05(金) 15:41:32

なんか Haskell 勉強する前に勉強しなきゃいけないことがありそうな感じの人だ

0438デフォルトの名無しさん

2007/01/05(金) 16:05:39

Haskellを勉強するのに配列とリストの違いを知っている必要もないような。

0439デフォルトの名無しさん

2007/01/05(金) 16:08:13

>>434
実際のリストは、こんな感じのデータ構造を
適当につなぎ合わせて作られている。

struct Object {
    enum {PAIR, INTEGER, STRING} type;
    union {
        struct {struct Object *head, *next;} pair;
        int integer;
        char *string;
    } body;
};

0440デフォルトの名無しさん

2007/01/05(金) 16:09:53

>>434
http://www.metabolome.jp/ja/biochem/bioinfo/list.pdf/view

0441デフォルトの名無しさん

2007/01/05(金) 16:21:40

>>439
それは余りに違いすぎないか？
型タグはない実装が多いだろうし、その定義だと遅延しない。

0442デフォルトの名無しさん

2007/01/05(金) 16:24:43

リストの中身はイテレータ。

0443デフォルトの名無しさん

2007/01/05(金) 16:39:23

>>441
頭の中のモデルとしてはこれで十分。

っていうか、実装の話をしだしたらキリがないだろ

0444デフォルトの名無しさん

2007/01/05(金) 16:58:38

>>443
わざわざ型タグを含めたObject型を持ち出しているから、実装に忠実な
データ構造を提示しているつもりかと思った。

>頭の中のモデルとしてはこれで十分。
遅延を考慮しないなら十分だろうが、そういう単純化した
モデルとしてなら無駄が多くないか？

struct node
{
void *head;
struct node *tail;
};

で十分だと思うが。

0445デフォルトの名無しさん

2007/01/05(金) 17:18:17

>>444
文字列とかの "本物のデータ" が
どう収まるか説明しないと、
普通はイメージが湧かない思う。
まぁ、その判断は >>434 に任せるが・・・

0446デフォルトの名無しさん

2007/01/05(金) 17:28:41

どう考えても 444 ので十分

0447デフォルトの名無しさん

2007/01/05(金) 17:47:17

同意　十分

0448デフォルトの名無しさん

2007/01/06(土) 14:36:31

検索が定数時間な連想配列を探していて、GHCのData.HashTableに辿り着いた。
でも何でこれってあちこちIO付きなの?

0449デフォルトの名無しさん

2007/01/06(土) 18:59:17

>>448
なぜData.Mapみたいなインタフェースじゃないか、という疑問なら、効率の問題。
Data.Mapのようなインタフェースだと、配列に操作(たとえばinsert)を施した後、
操作前の配列と操作後の配列の両方を操作しえるので、この二つを別々に
保持しておかないといけない。(ナイーブには毎回コピーをとればよい。
もっと低コストな方法もあるだろうが、いずれにせよオーバーヘッドがある)
実際Data.HashTableのようなIOの絡んだインタフェースなら、
常に最新版しか操作できないので、単純なメモリ上の破壊的操作で実装できる。

なぜSTじゃなくてIOなのかという疑問なら、俺にも判らん。

0450448

2007/01/06(土) 23:35:56

>>449
ども。Haskell初学者なので処理系の中の人の気持ちはあまりわからんけど、
破壊的操作を用いて実装すれば実行時効率がよいことは理解できる。ありがとう。

STってのはControl.Monad.STのこと?
GHC付属文書での記述を軽く眺めてみたけど、さぱーりだった…

で、便乗して別の質問。Data.Map的なインタフェースを持つ型について。
その型の変数xがあって、内容を一部変更した値を変数yに格納して、
変数xの内容を完全に破棄したとき、「いつでも全体をコピーしたりはしない」
ことはわりと期待してもよいもの?

0451デフォルトの名無しさん

2007/01/07(日) 11:37:43

リストの質問をした者です。
感謝の言葉が遅くなってしまい申し訳ありません。
>>439,444
実際のコードの提示、有難うございます。
>>435,436,437,438,440,441,442,443,445,446,447
ご助言有難うございます。

リストの事はC言語による最新アルゴリズム辞典という本を買ってきて解決しました。
もうひとつ質問です。
文字のリストと文字列の事についてなのですが、
Haskellではこの二つは全く同じで
ある関数がstringを引数にとるなら文字列として扱われて、
[char]を引数にとるなら、文字のリストとして扱われる、
という理解でよいのでしょうか?(ふつうのHaskell、p68から質問です。)

0452デフォルトの名無しさん

2007/01/07(日) 11:38:11

下位の関数の出力がIOだと上位の関数の出力がIO汚染されてしまうんですけど、
なんとか良いプログラミングスタイルないですか？

0453デフォルトの名無しさん

2007/01/07(日) 11:39:43

IOつかわなければいいとおもうよ

0454デフォルトの名無しさん

2007/01/07(日) 11:39:54

>>451
中身では、
type String = [Char]
ということになってるのかな。
だから、Stringも[Char]も同じ。

0455デフォルトの名無しさん

2007/01/07(日) 11:45:58

下位の関数でIOを返した場合、連鎖的に上位のすべての関数の返値にIOをつけなければならなくなると思うのですが、
そういう場合って、SICPで勧めているプログラミングスタイルだと二度手間になってしまいますよね。

0456デフォルトの名無しさん

2007/01/07(日) 11:58:00

中でやってることが外部に副作用を残さないような処理なら
unsafePerformIOでIOを外しちゃえばいい。

0457デフォルトの名無しさん

2007/01/07(日) 12:23:20

>>455
最初から上位の関数にIOをつけておけば良い。

0458デフォルトの名無しさん

2007/01/07(日) 13:03:05

>>456
たとえば、設定ファイルの読み込みとかの用途だとそれでも良いかもしれないが、
unsafePerformIOだと実行順序が規定されなくなってしまうでしょ？

>>457
すべての関数にIOをつけると、ものすごく再利用しにくくて汚いコードになると思うのですが・・

0459デフォルトの名無しさん

2007/01/07(日) 13:12:29

>>458
全体として実行順序が規定されていなきゃいけない処理なら
IOが必要な部分だからそのままでいいのでは。

■ このスレッドは過去ログ倉庫に格納されています