トップページtech
768コメント261KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001潜伏していた1NGNG
何とか生き残れました。
前スレ
http://pc.2ch.net/test/read.cgi/tech/996131288/l50

関連 >>2 以降
0052デフォルトの名無しさんNGNG
>>51
Cのインラインと違うの?
0053デフォルトの名無しさんNGNG
>>52
実行時までどんな関数が来るのか分からない
らむちゃんなんだから全然違うだろ。
0054無名λ式NGNG
>>51
lambda liftingというのは、
一言で言えば、自由変数を除去する変換の事です。
・funarg問題がなくなる
・環境の扱いが簡単になる
・lazinessの境界がはっきりする
などなどの利点があります。
lifterはその変換器の名前です。

Super combinatorというのありました。(これは変換後のλ式の名前)

Prentice-Hallから処理系実装の本が出ていましたが、
> それと関数型言語にある代表的な最適化処理があれば教えてください。
こういう観点で非常にいい読物だと思います。
# 今やMicrosoft Research(CLI!)のSimon P. Jonesのが一冊、
# もう一冊はHughesじゃなかったかな? 教科書になって答えがWebで配布された奴。

驚きなのはcombinatorが非常に古い概念であるにも関わらず、
λ計算において非常に本質的な役割を担うことです。




0055無名λ式NGNG
>>53
> 実行時までどんな関数が来るのか分からない
> らむちゃんなんだから全然違うだろ。

λ式ちゃんは、Lisp野郎ほど酷くないですけどね。
奴の場合、cons, eval, macroと何でもありなので。
0056デフォルトの名無しさんNGNG
> # 今やMicrosoft Research(CLI!)のSimon P. Jonesのが一冊、

http://research.microsoft.com/~simonpj/Papers/papers.html
ここ (の一番上のとこ) から落とせるやつですな。
0057無名λ式NGNG
http://research.microsoft.com/~simonpj/win32-cheat.html
これ面白いよね。この作業苦痛じゃないのかな...
0058デフォルトの名無しさん NGNG
>>57
なんだか大変そうですね。これホントに自分でやってるのかな?(藁
0059デフォルトの名無しさんNGNG
仕事でcygwinを強いられるSimon萌え!
0060デフォルトの名無しさんNGNG
論文発表打ちage
0061デフォルトの名無しさんNGNG
>>54
コンビネータ、結合子ですか?
圏論?λ理論の話でしたか?
うーん難しい。
0062デフォルトの名無しさんNGNG
>>61
理論的には難しいとおもうけど、
"Implementing Functional Languages: tutorial"
には実装についてわかりやすく書いてありますです。
0063デフォルトの名無しさんNGNG
>>62
サイモン パイソン ジョーンズさんがM$用に書いたやつだよね?
どのチャプターに書いてあります?

(ファイルは持ってるんだけどねー。軟弱ものなので読んでません。)
0064デフォルトの名無しさんNGNG
> Peyton
ペイトン
0065デフォルトの名無しさんNGNG
>>63
Lambda lifting については 6章
コンビネータ実装のはなしは
"Implementation of Functional Programming Language"
というよく似た名前の本の方でした。これも、どこかのWEBサイトで公開
されてたとおもうですだす。
0066デフォルトの名無しさんNGNG
>>65
"Implementation of Functional Programming Language"
本の方は簡単に見つかったけどなー。
判らない。くそー。
0067Super CombinatorNGNG
>>66
何がわからないのか、話してみれば?
0068デフォルトの名無しさんNGNG
Peyton Jonesは前に学会で会ったとき、冬のロンドンを裸足で歩いてた…。
別に変人じゃなくてナイスガイなんだけど。発表は楽しいし。
006966NGNG
>>67
コンビネータといえばCL式
どんなCL式でもIKSを組み合わせたものまで分解できるらしいけど
どうやって?

あとSの意味が判らない。どう使うんだろう?

I = \ x -> x
K = \ x y -> x
S = \ x y z -> x z ( y z )

でも相手にしないでください。
頭正規形(hnf)って何?といぐらいのレベルですから。
ラムダ理論も知らないんですから。
0070Super CombinatorNGNG
>>69
> あとSの意味が判らない。どう使うんだろう?
> S = \ x y z -> x z ( y z )

Distributor.

Combinator式は、グラフとして素直に表すことができるから、
部分グラフは、元のプログラムを分割したものと考えられる。
部分プログラムxと部分プログラムyの両方に引数zを渡し適用するのが役割。

x側では引数zは必要なければ、

(K x' z) (y z)

てな感じになる。(x ≡ K x')
(x z)を(y z)に適用するのは、部分プログラム同士を結合する方法が、
「適用」以外にはないから。Combinator logicやlambda calculusでは。

RAM(Random Access Machine)ではメモリ参照で、データを扱うわけだけど、
Combinator logicやlambda calculusでは、どんどん受け渡していくことになる。
# lambda calculusのβ簡約をメモリ参照で直感的に理解している人も多いと思うが。
0071デフォルトの名無しさんNGNG
>>69
I=SKK
Raymond Smullyan の "To Mock A Mockingbird" という本が楽しめます。
翻訳も出ていたと思う。
0072デフォルトの名無しさんNGNG
>>71
『ものまね鳥をまねる』森北出版 isbn 4-627-01901-7
007369NGNG
みなさん、親切な解説有難うございます。
「プログラミング意味論」 横内寛文著
「計算論 計算可能性とラムダ理論」 高橋正子著
と読み理解しようと奮闘中なのですが、計算機屋の私にはさっぱりです。
しかし理論はむずかしーな。
一度ものにしてしまうと効果絶大なんですけどね。
もうちょっと、がんばってみます。

>>71
>I=SKK
む。なるほど。
上の本で書かれていましたが、改めてみると こういう意味だったんですね。
Sの機能が、ちょっとわかった気がしました。

>>70
>Distributor.
>
>Combinator式は、グラフとして素直に表すことができるから、
>部分グラフは、元のプログラムを分割したものと考えられる。
>部分プログラムxと部分プログラムyの両方に引数zを渡し適用するのが役割。
中略
>(x z)を(y z)に適用するのは、部分プログラム同士を結合する方法が、
>「適用」以外にはないから。Combinator logicやlambda calculusでは。

なるほど。
Sで式同士を組み合わせる。
もしくはSで式を分解できるということなんでしょうか?

>>71
>『ものまね鳥をまねる』森北出版 isbn 4-627-01901-7
ttp://www.morikita.co.jp/bunya/kensaku-bunya.cgi?id=67
よさそうな本ですね。購入したいと思います。
0074Super CombinatorNGNG
>>73
> 両方に引数zを渡し

だから'分配器(distributor)'です。
Sはドイツ語だったかの頭文字だったはず。
K=cancel
0075石敢當NGNG
GHC 5.02.3 がリリースされました。

ただいま amortization の勉強中。
分かったような、分からんような・・・
ということは分かってないんだなぁ。
0076Super CombinatorNGNG
>>75
amortizationは、時間のかかる処理を、複数の操作に対してひとまとめにして、
平均の計算量オーダーを下げる手法のこと。
木、ソートされたテーブル、pure functional arrayなどの
再構成、構造調節などで利用される事が多い。

0077デフォルトの名無しさんNGNG
amortizationって何ですか?
どういう物なのか興味あるなー。
教えてSuper Combinatorさん。
0078石敢當NGNG
> amortizationは、時間のかかる処理を、複数の操作に対してひとまとめにして、
> 平均の計算量オーダーを下げる手法のこと。

そのような雰囲気は分かるのですが、「分かったぞ!」という実感が
まだ伴っていません。もう少し勉強します。

.NETというのも名前はよく目にするものの中身はさっぱり分からない
のですが、Hugs98 for .NET というものがリリースされたようです。

http://galois.com/~sof/hugs98.net/
0079デフォルトの名無しさんNGNG
Cormen, Leiserson, RivestのIntro. Algorithmsに
amortized analysisの章がありますよ.
0080デフォルトの名無しさんNGNG
たとえば固定長配列に1ずつ要素を追加していくことを考えます。
満杯になったら新しく大きい配列を用意して全部コピーして追加。
このとき、初期サイズ1で1ずつ大きくして行くとN要素追加するの
に合計コピー回数は1+2+3+…+NだからO(N*N)。定数Cずつ大きく
していくとしても、コピー回数がC分の1になるだけだからO(N*N)
は変わらない。ところが2倍ずつに大きくして行くことにすると、
1+2+4+…+NだからO(N)になるのね。しかし「1個追加するときの
最大計算量」はどの方法でも(その1個であふれた場合はどのみち
コピーするんで)変わらない。逆に言えば、最大計算量を考える
変わりにN個の操作全体の計算量を考えてその平均を取ると
1個追加する際の平均的な計算量はO(1)だよね、っていうのが
amortized analysis。
0081デフォルトの名無しさんNGNG
ttp://www.cs.columbia.edu/~cdo/papers.html
ここに書いてあることかな?
英語が読めない。
0082デフォルトの名無しさんNGNG
なんか今はnot foundになっちゃうけど、それってChris Okasakiのページだよね。>>81
だったら、そうだと思う。

でもこのスレの人でも、英語は壁になるんだ…。自動翻訳希望?
008381NGNG
そうです。
他力本願全開。
0084石敢當NGNG
> 逆に言えば、最大計算量を考える
> 変わりにN個の操作全体の計算量を考えてその平均を取ると
> 1個追加する際の平均的な計算量はO(1)だよね、っていうのが
> amortized analysis。

これは良く分かります。ただ、これだけだと amortization などという
言葉を持ち出すまでもなく、単に「平均」ですよね。(違うのかな?)
もし単に平均コストのことを言っているだけだとすると、
banker's method だの physicist's method (>>79の本では
accounting method と potential method)だのの技法を使い、
多くのページを割いて解説するほどのことじゃないように
思うんです。

>>80の例の場合、配列の確保がサイズに関係なくO(1)で行えると
仮定すると、あふれたときに1度に全部コピーするのではなく、
新しい要素が追加されるたびに要素を2個ずつコピーすることに
すれば1個追加する際の「最大の」計算量がO(1)となります。

結局、amortizationの何が良く分からないのかということを
改めて考えてみますと、amortized analysisで得られた平均
計算量が、平均ではなくて最大の計算量となるような実装が
いつも得られるのだろうか、ということであるような気が
してきました。

まだ良く分かっていません。変なことを書いていたらごめんなさい。
0085デフォルトの名無しさんNGNG
>>84
> これは良く分かります。ただ、これだけだと amortization などという
> 言葉を持ち出すまでもなく、単に「平均」ですよね。

「最悪」の場合の1ステップあたりの「平均」ではないでしょうか。
0086デフォルトの名無しさんNGNG
http://www.teu.ac.jp/kougi/koshida/Prog6/index.html



ない・・・
0087デフォルトの名無しさんNGNG
http://www.brl.ntt.co.jp/people/mizuhito/CS/

 ↑

ここも講義録だったような気がするんだけど、つながらない・・・
0088デフォルトの名無しさんNGNG
>>87
http://www.ipl.t.u-tokyo.ac.jp/~mizuhito/CS/
0089デフォルトの名無しさんNGNG
このスレを見て面白そうだと思いHugsを入れてみた関数型の素人です。
最初はやはり名前を入力させてXXXさんこんにちは、だと思い試したのですが
putStr "123" とか getLine とか単体では動くのに、次のように組み合わせるとエラーになります。

Prelude> putStr getLine
ERROR - Type error in application
*** Expression : putStr getLine
*** Term : getLine
*** Type : IO String
*** Does not match : [Char]

一行入力をそのままエコーすることを意図しているつもりなのですが、何故でしょうか?
0090デフォルトの名無しさんNGNG
>>89
getLine の型は IO String だが putStr は String 型を貰うので
型エラーになります。(IO が付いているかいないかの違いだけど)
getLine >>= putStr とすれば意図してるように動きます。
「>>= って何?」などと思うのでしょうが、説明するのは大変なので
http://www.sampou.org/haskell/tutorial-j/ などを読んでください。
0091デフォルトの名無しさんNGNG
色々試しているのですが、次のコードで
ERROR "ファイル名":3 - Type error in function binding
*** Term : sel
*** Type : a -> IO a
*** Does not match : a -> a
*** Because : unification would give infinite type
というのが消えてくれません。

module Main (main) where

sel x = do putStr "(y/n) ? "; c <- getChar
       return (
        case c of
         'y' -> sel (x + 1)
         'n' -> x
         _ -> sel x)

main = do putStr (show (sel 0))

selの型は Int -> IO Intのつもりなのですが、型を明示しても駄目です。
いじっていると、IO (IO Int)みたいな型がエラー報告で出るときもあります。

このコードはどうすれば通るのでしょうか?
それと、IOを重ねる意味は無いように思えるのですが、IO (IO Int) というのはどういう状態なのでしょうか?

質問ばかりで申し訳ありません。
0092デフォルトの名無しさんNGNG
>>91
case c of
{'y' -> sel (x + 1)
;'n' -> x
;_ -> sel x}

この式の型は何でしょう?
009391NGNG
IO Int …のつもり…です。
それをreturnで返していますから、selの返値もIO Intで、
selの型は Int -> IO Int …

エラーになるということは、間違った理解なのでしょうけれど…
009491NGNG
sel (x + 1) と sel x が IO Intなのに、'n' の時の x がただの Int だからいけない…?
とすれば、ただの Int を IO Int に揃える必要があるということですか?
0095デフォルトの名無しさんNGNG
> IO Int …のつもり…です。
> それをreturnで返していますから、selの返値もIO Intで、

return の型は Monad m => a -> m a です。
>>91 のケースだと m は IO。

> とすれば、ただの Int を IO Int に揃える必要があるということですか?

うん。で、そういう場合に return を使う。

sel x = do
putStr "(y/n) ? "
c <- getChar
case c of
'y' -> sel (x + 1)
'n' -> return x
_ -> sel x
009691NGNG
以下のコードで動作しました。ありがとうございます。

module Main (main) where

sel x = do putStr "(y/n) ? "; c <- getChar
       case c of
        'y' -> sel (x + 1)
        'n' -> return x
        _ -> sel x

main = sel 0 >>= putStr . show

(r <- case …にしてその後にputStr "/"とreturn rを続けて書いたら、'n'を打った時も表示されたので)
この場合returnはcaseから抜けているだけですよね?

doを使っている場合も、returnを書かなくても、最後の式が返値になるのですね。
0097デフォルトの名無しさんNGNG
return は関数であって、命令ではない。
009891NGNG
IO型にするだけで、脱出はしないということですか?
0099デフォルトの名無しさんNGNG
返り値という表現に違和感を感じので。

深い意味はないです。return は、返り値を
もって呼び出し元へ帰る命令ではなく、単に
a 型の値を m a 型の値に写像する関数だと
いってみただけです。
0100デフォルトの名無しさんNGNG
試してみたら、returnの後に文を続けた場合、途中returnに渡した値は無視されて、最後の値が採用されているようです。
成程…Haskellのreturnはreturnしないのですね。
0101デフォルトの名無しさんNGNG
のぶさんのHaskell-MLに登録してみましょう
0102デフォルトの名無しさんNGNG
return とか戻り値をCチックに理解しようとしてる時点でもうダメでしょうって
感じかも。関数型言語の発想が根本からわかってない。
IOモナドって一見して普通の手続き型にも見えますからねえ・・

関数型が全くわからない人は、HaskellのまえにMLを経由した方が良い
というのは正しいのかも。
0103デフォルトの名無しさんNGNG
モナドは手続き型プログラミングの車輪の再発明だって、どっかに書いてあったね
0104デフォルトの名無しさんNGNG
俺、いつもはMLしか使ってなくてHaskellは詳しくないんだけど、
Haskell(特にGHC)って例外処理とか、入出力じゃない副作用も
どんどんIOモナドに入ってるじゃん。

モナドの合成が理論的に難しいかららしいけど、そのうちに現実的な
プログラムだと何でも一つのモナドの中で書くことになって、ほとんど
MLみたくなったりはしないの?(手続き型言語とまではいわないけど、
「どこでも副作用」って感じで)
0105デフォルトの名無しさんNGNG
>>104
モナドは副作用じゃないのでOK OK。
逆に言うとMLの利点がなくなってくる。
0106デフォルトの名無しさんNGNG
ML、Haskellってお互い仲悪いんですか?
0107デフォルトの名無しさんNGNG
ゆーざーがね
0108デフォルトの名無しさんNGNG
仲悪いなんて聞いたこともないぞ。
なかはわるくないです。

MLとHaskelは
ちょっと雰囲気は違うような気はしますけどね。
でもまあそれは両方使ってみれば解ることで。
0109デフォルトの名無しさんNGNG
>106
Haskell-MLというのが有るらしいですYO!
0110デフォルトの名無しさんNGNG
Haskellは、純粋関数型言語だから
MLの不純さが嫌なのかも?
どうなの?>ALL
0111デフォルトの名無しさんNGNG
確かにHaskellの処理系の効率が良くなればMLは不要になる。
0112デフォルトの名無しさんNGNG
MLとHaskellは設計思想自体が全然違う気がします。

ML(Ocaml)は現実的にある程度の副作用を認めている代わりに
使っているとコンパクトな感じがします。
副作用も使えると言うだけで、副作用のある構文を使わずに書く事は
全然出来ますし、遅延評価もコードによって簡単に実現できます。
未だ出来あがっていないものの、ML2000の仕様書では言語自体に
遅延評価など新しい機能がかなり含まれています。

Haskellは純粋を歌ってはいますが、
結局の所モナドというものに問題を押しこんだだけのようにも思え
美しくないようにも思われます。
仕様もわりとごちゃごちゃしている気がします。
言語の性質上ML並みに速くなる事も難しいのではないかと思います。
0113デフォルトの名無しさんNGNG
MLで副作用使わずにどうやってI/Oするの?
0114104NGNG
あーなんか煽りっぽくなっちゃってスマソ。俺はHaskellも大好きだよ。(笑)
WadlerとかPeyton Jonesとか面白い人が多いし。(そういう問題か?)

>>113
一応、MLでもHaskellと同様のmonadicなプログラミングスタイルは可能。
MLだと文法的に面倒で、Haskellを使ったほうが楽だから誰もやらないけど…
0115デフォルトの名無しさんNGNG
副作用のある関数型言語は
中途半端な感じが払拭できないということでいいのか?
0116デフォルトの名無しさんNGNG
Ruby >>>>>>>>>>>>>>>>>>> Haskell
0117デフォルトの名無しさんNGNG
モナドがあまりに手続き型っぽすぎるので、
Haskllを関数型を知らない人に触らせると、
モナドでC言語かよ!ということをやろうとする。
しかして正しく正面玄関から入ろうとすると、難解過ぎる。
MLの方がそういう意味でも適度に関数型な気がする。

純粋関数型を言うならば、遅延ストリームでゴリゴリ書くのが基本に
なってるような言語であるべきかなと思ってみたりする。
0118デフォルトの名無しさんNGNG
いいんじゃねえの?
多目的言語なんだから。
0119Super CombinatorNGNG
>>104
> Haskell(特にGHC)って例外処理とか、入出力じゃない副作用も
> どんどんIOモナドに入ってるじゃん。

最近Haskellの動向は探ってないんだけどこれ本当?

IOErrorがIOモナドmoduleにあって、
HaskellがIOError以外ろくに例外をsupportしないだけなんだと思ってたよ。
0120デフォルトの名無しさんNGNG
勉強中だからよく分かんないけど、state モナドの事?
0121デフォルトの名無しさんNGNG
MLと(Haskellとも)離れますが、
モナドを使うと、手続き型言語を
関数的に解釈することができますか?
0122デフォルトの名無しさんNGNG
>>121
「関数的に解釈」の意味がよくわからない。
Haskellでインタープリタが書けるか?
という意味じゃないよね。

0123デフォルトの名無しさんNGNG
http://sato-www.cs.titech.ac.jp/prism/index.html
0124デフォルトの名無しさんNGNG
>>122
モナドを使うと、どうみても副作用な操作でもfunctionalな
操作と解釈できるわけですが、それと同じように手続き型言
語のプログラムに純関数的な意味を与えることができますか?
という意味です。
0125デフォルトの名無しさんNGNG
>>124
Idealized Algolとかいうのがなかったっけ。
0126デフォルトの名無しさんNGNG
グローバル変数が見当たらないんですが・・・
0127デフォルトの名無しさんNGNG
>>121 >>124
できません。
強引に無理矢理こじつけることならできるかもしれないけど意味無し。
0128デフォルトの名無しさんNGNG
>>124
モナドを使えば、代入、逐次的実行、手続き型ライクなI/O、例外などを
純関数型の枠組みで扱える。gotoくらいならもともとモナドに関係なく
等価な純関数型言語に変換することができる。

Cは無謀だがMINIMAL BASICくらいなら、純関数型とみなすことは可能だろ
う。
0129Super CombinatorNGNG
>>124
Denotational semanticsじゃ駄目?
domainの性質がやっかいになるから、いいことないけど。

そもそも「簡単に」できるくらいなら、関数型言語の存在意義が…
0130デフォルトの名無しさんNGNG
Haskellで書いたプログラムに、関数的意味を与えうるなら、
手続き型の言語のインタープリタを Haskell で書いたら、
その言語の意味を与えたことになる?
ならない?
0131デフォルトの名無しさんNGNG
>>130
なるんじゃない?
きちんとやれば操作的意味論だろ。
0132デフォルトの名無しさんNGNG
結局、Haskellは非正格言語なのが問題じゃない?
実際に各項が何時評価されるか?どういう順番で評価されるか?
ということが予測しづらい(できない)からねー。

その点、正格言語や手続き型言語は評価の順序が一目瞭然だからねー。

Prologにカットオペレータがあるように、Haskellも競争書き込みで
評価の順序を、ある程度コントロールできる様にしたらよいのかな?
0133デフォルトの名無しさんNGNG
>>132
?? 問題なのは結果であって、
順番なんてどうでも良いだろう。

順番じたいが望む結果に含まれる
(例えば入出力とかGUIとか)なら、
そこだけモナド使えば良いしさ。
0134デフォルトの名無しさんNGNG
>>133
133も書いていますがコンピュータの入出力は
ストリームを基本としているものが多いですよね。
しかし、ストリームにとって並び方も結果の内ではないでしょうか?
プログラムは外部と入出力して、なんぼのものだと私は思っています。
ゆえにストリームのようなモノに対して実行順序がコントロールできることは
プログラミング言語にとって重要であると思います。
そうじゃなきゃPrologもカットオペレータなんて付けなかった
と思います。

あと私のような消防には、実行される順序が予測できないと
デバッグしづらいです。(もしかして、こっちが本題か?)
0135デフォルトの名無しさんNGNG
>>134
ほんとに消防だな。Haskellだって
ストリームの順番が狂うわけはないだろう。

ストリームは「いくらでも長くなりうる列」
というデータだ。関数型の基本はデータの値を
求めることなんだから、モナドなんか用いなくたって
ちゃんと求まる。
0136チュウボウNGNG
なんで副作用って困るの? よく聞くはなしでは
 副作用あり=>参照透過性がない=>数理論理的でない
数学って、まったく副作用のない構成になっているの?
0137デフォルトの名無しさんNGNG
> 数学って、まったく副作用のない構成になっているの?

副作用がなんなのかわかってる?
0138デフォルトの名無しさんNGNG
副作用が無ければ、デバッグ簡単
0139チュウボウNGNG
>副作用がなんなのかわかってる?
オレの理解
 状態という一種の記憶域のようなものがあってその値が
 変わること。

数学ではオートマトンとか除けば、状態のような概念は
知らない。
0140デフォルトの名無しさんNGNG
>>136
評価順序に依存してるから
0141チュウボウNGNG
順序なしで考えるより、順序を指定されて考える方が楽じゃない?
0142デフォルトの名無しさんNGNG
>>141
そう思えるのはモノが単純な場合だけ
0143チュウボウNGNG
状態(もの)と動作(働き)があった方が考えやすい気もする。
主語+述語が人間の頭にあってるような気がする。
(状態があるならば副作用があると思ってる)

ペトリネットなんかかじってみてると、そんな気がしてきた。
ttp://www.aichi-pu.ac.jp/ist/~qua/intropn/intropn.html
0144デフォルトの名無しさんNGNG
副作用って、関数が値を返す以外の何かの作用を起してしまうことでしょ。
「なぜ関数プログラミングは重要か」に副作用が無い事のよさが力説されてた。
実感湧かなかったが。
0145デフォルトの名無しさんNGNG
>>143
日本語は主語なんかなくても良い言語だよ。英語カブレめ(w
実際この書き込み(145かな?)のなかに主語のある文は一つもないが、
意味はちゃんと通じるだろ?
01465月病NGNG
オレも人並みにSOE本ながめたりして、haskellの理解に
努めたわけよ。モナドの意味もつかもうとしてがんばった
んだけど、あるときふと、こんなに無理して副作用さけよう
という努力はなんなんだろうと感傷的になるわけよ。
0147デフォルトの名無しさんNGNG
Cでグローバル変数はやめよう、と似たようなもんじゃないの?
0148チュウボウNGNG
>>145
>日本語は主語なんかなくても良い言語だよ
おお、そうであった。日本語は述語だけでつうじるのだ。
日本語こそ真の関数型言語であった。なんてわけないか。
0149デフォルトの名無しさんNGNG
>>146-147
つーか…
プログラムって要するに「入力と出力の関係を記述する」
ってだけで良いはずなのに、状態を持ち出すとよけい面倒に
なることも多いでしょ。
01505月病NGNG
モナドを使い、高階関数を使い、入力と出力の関係だけで
ストイックに記述する。そうすると見えるすばらしい世界
を教えてください。
0151デフォルトの名無しさんNGNG
>>149
> 入力と出力の関係を記述する

時系列的な入力と出力の表現には内部状態があった方が記述が楽。
あと、入力の長さが不定なときも。
だから入力に対して反応するタイプのプログラムでは状態記述がないと不便。

>>145
主語がなくていいのは主語が明らか(容易に推測可能)な時だけだよ。
フォーマルな文章では日本語だって主語が必要。ここはかなりインフォーマルだからね。
ちなみに英語でも命令形などでは明らかな主語が省略されている。
■ このスレッドは過去ログ倉庫に格納されています