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

関数型プログラミング ..

167:デフォルトの名無しさん
07/11/16 03:27:46
>>164
アロケートされたメモリの数が700MBってことなのだが、実際はgeneration 0に割り当てられた少ないメモリが使いまわされているだけだから、メモリの使用量自体は少ないはず。

168:デフォルトの名無しさん
07/11/16 07:15:29
>>164
OSから確保したのが32MB
実際のヒープオブジェクトの総量が瞬間最大で13,955,072 bytes
コピーGCだからOSから確保した領域の半分以下しか貯められない

169:デフォルトの名無しさん
07/11/16 17:49:52
StateモナドでunsafeInterleaveIO的な関数って書けますか？
do
xs <- interleaveState $ sequence $ replicate 3 get
sequence $ map set xs

で get set get set get setの順になるようなやつ

170:デフォルトの名無しさん
07/11/16 18:08:04
unsafe禁止令

171:デフォルトの名無しさん
07/11/16 18:26:23
xs <- sequence $ replicate 3 $ interleaveState get
の間違いか？
どっちにしても無理だろ

172:デフォルトの名無しさん
07/11/16 18:36:40
>>171
すいません、間違いでした
無理orz

173:デフォルトの名無しさん
07/11/16 22:22:17
モナドと代数的データ型に的を絞って詳しく扱ってるテキストはないでしょうか

174:デフォルトの名無しさん
07/11/17 03:16:48
foo >>= bar
としたときに実際に>>=がどのインスタンスに定義されている>>=の処理を行うのか、
というのはどうやって決まるんでしょうか?

175:デフォルトの名無しさん
07/11/17 07:11:03
>>174
型推論。fooの型とbarの型とその式の使われ方が勘案される。

176:デフォルトの名無しさん
07/11/17 11:11:46
>>175
それはコンパイル時と実行時のどちらでされるものなんでしょうか?

177:デフォルトの名無しさん
07/11/17 11:43:58
>>176
実行時

178:デフォルトの名無しさん
07/11/17 11:57:24
・型推論自体はコンパイル時。
・ただし、型クラスのディスパッチは実行時まで遅延される。
・ただし、どのインスタンスについてのコードを生成すれば良いか静的に決まる場合は、
最適化の一環としてディスパッチを省略する。

こんな感じか。

179:174
07/11/17 12:49:35
>>177、178
なるほど、静的に型をチェックしつつ、動作は動的に決まるんですね。

ところで
数学パズルものまね鳥をまねる―愉快なパズルと結合子論理の夢の鳥物語
URLﾘﾝｸ(www.amazon.co.jp)
E3%82%92%E3%81%BE%E3%81%AD%E3%82%8B%E2%80%95%E6%84%89%E5%BF%AB%E3%81%AA%E3%83%91%E3%82%BA%E3%83%AB%E3%81%A8%E7%B5%
90%E5%90%88%E5%AD%90%E8%AB%96%E7%90%86%E3%81%AE%E5%A4%A2%E3%81%AE%E9%B3%A5%E7%89%A9%E8%AA%9E-%E3%83%AC%E3%82%A4%E3%
83%A2%E3%83%B3%E3%83%89-%E3%82%B9%E3%83%9E%E3%83%AA%E3%83%A4%E3%83%B3/dp/4627019017/ref=sr_1_9?ie=UTF8&s=books&qid=1195271100&sr=1-9
この本を読んだことがある人いますか?関数プログラミングの土台の考え方がわかる本らしいんですが。

180:デフォルトの名無しさん
07/11/17 13:28:59
>>179
途中まで読んだだけだけどコンビネータの話。
S,K,I とか。Yコンビネータも出てきたかは覚えてない。

181:デフォルトの名無しさん
07/11/17 16:07:56
a 1 = "hoge"
a 2 = 2
のような引数によって異なる型の値を返すことはOKなんでしょうか?

182:デフォルトの名無しさん
07/11/17 16:22:37
>>181
template haskell

183:デフォルトの名無しさん
07/11/17 16:25:26
>>181
ダメ

184:デフォルトの名無しさん
07/11/17 16:30:24
2種類の型のどちらかを返したい場合はEitherを使う。
a :: Int -> Either String Int
a 1 = Left "hoge"
a 2 = Right 2

185:182
07/11/17 16:51:52
template haskellじゃなくてgeneric haskellだった・・

186:デフォルトの名無しさん
07/11/17 22:16:41
>>163
今日Haskell始めたばかりのド素人なんだけど、
ones = addlist 1 onesでも、

addlist init xs = init : head xs : tail xs　-- [1,1,1,1,1,1,1,1,1,1]
addlist init xs = init : xs　　　　　　　　　-- [1,1,1,1,1,1,1,1,1,1]
addlist init ~(x:xs) = init : x : xs　　　　　-- [1,1,1,1,1,1,1,1,1,1]
addlist init (x:xs) = init : x : xs　　　　 -- C stack overflow

ってなる。要するに(x:xs)が含まれる部分が先に解釈されるとマズいってことじゃないかな。
単体でのxsはパターンはパターンでも手続き型言語での仮引数と同じ程度の意味しかもたないパターンだから暗黙的に遅延される。
head xsやtail xsも関数だからxsが未確定なら遅延される。
でも(x:xs)というパターンは未確定でも遅延しないでxとxsを照合しようとする。
結果的にinitに値がセットされる前にx:xsを延々と調べ続ける。それではマズいので、(x:xs)を遅延パターンにする、ってことじゃないかな。

187:デフォルトの名無しさん
07/11/17 23:24:01
>>163
明日からHaskell始めるつもりのド素人なんだけど、
関数の仮引数xがconstructor pattern（たとえばy:ys）の場合、
それはcase x of y:ys -> ...という形に変換される。
で、caseの条件式はWHNFまで評価されてしまうので、
遅延させたい時には使えない。

188:186
07/11/17 23:31:58
>>188
あ、なるほどそういうことなのか。
ありがとう。無理して答えた価値あったわ。

189:163
07/11/17 23:59:14
なんとなく理解できました。ありがとうございます。
Haskellの考え方に慣れるまでまだ時間がかかりそうですorz

190:デフォルトの名無しさん
07/11/18 00:28:05
sequence :: Monad m => [m a] -> m [a]
sequence = foldr mcons (return [])
　　　　　　　where mcons p q = p >>= \x -> q >>= \y -> return (x:y)

↑のsequenceの定義を見るとfoldrが使われているんですが、それだと
sequence [putStr "foo", putStr "bar"]　の場合リストの後ろの方、
つまりputStr "bar"の方が先に評価されるのに、実際には
fooの方が先に出力されてしまいます。どうして後ろからではなく、先頭から
評価されるんでしょうか?

191:デフォルトの名無しさん
07/11/18 00:55:14
式の評価順とIOモナドの実行順は別物。

192:デフォルトの名無しさん
07/11/18 01:04:47
sequence [A, B, C]
= A `mcons` (B `mcons` (C `mcons` (return [])))
= A >>= (\x -> (B `mcons` (C `mcons` (return []))) >>= \y -> return (x:y))

よってA, B, Cの順にエフェクトが出る。

193:デフォルトの名無しさん
07/11/18 01:17:35
>>178
Haskell今日始めた人なんだけど
その最適化の一環としてディスパッチが省略された場合ってのは
C++でいうとtemplateによってコード生成された状態と考えていいんですかね

194:デフォルトの名無しさん
07/11/18 02:12:23
main = putStr "hoge" >>= \x -> putStr "foo" >>= \y -> return x
main = putStr "hoge" >>= \x -> putStr "foo" >>= \y -> return y
main = putStr "hoge" >>= \x -> putStr "foo" >>= \y -> return "bar"

↑のように最後にreturnさえすればエラーにならずhogefooと出力されるということは、
IOモナドはMaybeモナドやListモナドと違って、最後に何を返すかではなく、
動作をどういう順に行うのかを決めるための仕組みだと考えればいいんでしょうか?

195:デフォルトの名無しさん
07/11/18 08:09:29
>>193
そんな感じ。

>>194
何を返すかによってmainの型が違う。
上の二例ではIO ()で、最後の例だとIO String。
両方コンパイルが通るのは、mainの型はIO αという形なら何でもよく、
生成されたα型の値は無視されることになってるから。

196:デフォルトの名無しさん
07/11/18 13:45:25
>>178
実行時にならないとどのインスタンスのコードが実行されるか
静的に決まらない場合ってどんな場合？？

197:デフォルトの名無しさん
07/11/18 13:51:59
>>196
クラスのインスタンス一般に対して書かれた関数は全部そう。例えば、
double :: (Num a) => a -> a
double x = x + x
こんな関数を定義したら、これをコンパイルする時点ではどの(+)を使うべきか決まらない。

198:193
07/11/18 13:56:54
>>197
その関数doubleに対して具体的に値を入れたときに
コード生成される(静的に生成？)んじゃないんですかね？

頭がC++脳なのでtemplateのことばっかり頭に浮かんでしまうんですがね…

199:デフォルトの名無しさん
07/11/18 14:08:31
>>198
少なくともGHCやJHCならdoubleが定義されたモジュールをコンパイルする時点でコードを生成する。
そうじゃないと、doubleを使う度に毎回doubleをコンパイルすることになって、
分割コンパイルの恩恵が薄れる。(C++はあえてこれをやってるわけだが)
それから、Haskellの仕様上、完全に静的に済ますわけにはいけない。
newtype P a = P a deriving Show
nq :: (Show a) => Int -> a -> String
nq 0 x = show x
nq n x = nq (n-1) (P x)
こういう関数をtemplate式でコンパイルしようとしたら、無限にnqのインスタンスを生成する必要がある。

あと、実際にはdoubleのような小さい関数はインライン化されるので、ディスパッチが省略される可能性はある。

200:196
07/11/18 14:27:36
>>199
なるほど、値(この場合Int)に依存してどういうインスタンスのコードが
実行されるかが決定する場合があるってことか

201:デフォルトの名無しさん
07/11/18 14:34:20
1:2:3:[] -> [1,2,3]
↑がこうなるのはわかるんですが
1:2:3 -> ?
とやった場合はどんなデータができるんでしょうか?

202:186
07/11/18 14:42:10
3はリスト型じゃないからエラーになるんじゃないかな？

203:デフォルトの名無しさん
07/11/18 14:43:06
あ、名前欄消すの忘れてた……

204:デフォルトの名無しさん
07/11/18 14:46:12
>>201
(:) :: a -> [a] -> [a]

205:デフォルトの名無しさん
07/11/18 14:48:27
>>201
やってみりゃいいじゃん。それで挙動に疑問があったらここでもう一度聞いてみな。

206:201
07/11/18 15:25:47
やってみたんですがテキストに書いてコンパイルしようとするとエラーに
なるのにghciで:t 1:2とやると
1:2 :: (Num t, Num [t]) => [t]
というなんだかよくわからないメッセージが出ます。
:tだと型チェックしないのかなと思ったんですが
:t putStr 1
とやると今度はきちんとエラーが出ます。
・1:2 :: (Num t, Num [t]) => [t]　は一体どういう意味なのか
・なんで:t 1:2はエラーにならないのに:t putStr 1はエラーになるのか
↑2つになる理由は何故なんでしょうか?

207:デフォルトの名無しさん
07/11/18 15:43:17
>>206
GHCは型クラス周辺を微妙に拡張してるからそのせいだろう。
Haskell98では(Num [t])という文脈はありえない。
Hugsで :t 1:2 と入れたらエラーが出たし。

208:デフォルトの名無しさん
07/11/18 15:44:43
ghcはIOの実装も特殊なんだよなー

209:デフォルトの名無しさん
07/11/18 15:53:43
一応解説。
Haskellでは1とか7とかの整数リテラルは(Num a) => aという型を与えられる。
つまりNumのインスタンスなら何にでもなり得る。具体的にはIntでもIntegerでもRationalでもいいし、
未知のユーザー定義型でもいい。
「1:2」という式では、とりあえず「1」の型をtと書くと、整数リテラルだから(Num t)という制約が必要。
(:)の右辺の型は左辺の型のリストだから、「2」の型は[t]。これも整数リテラルだから制約(Num [t])も要る。
式全体の型は右辺と同じで[t]だから、結果として(Num t, Num [t]) => [t]になる。

210:201
07/11/18 16:16:46
やっと理解できました。ありがとうございます。

211:デフォルトの名無しさん
07/11/18 16:19:47
なるほど、どこかで instance Num [Int] のようなことが
書かれていないとも限らない、ということですか。

212:デフォルトの名無しさん
07/11/18 16:44:20
すいません
初歩的な質問でごめんなさい。

main = do
　cs <- getContents
　putStr.unlines $ lines cs

これはコンパイル通るんですが

main = do
　cs <- getContents
　putStr.unlines.lines cs

これは通りませんでした…これって何故なんですか？
てっきりlinesとunlinesというのは対になってるもんだと思ってたんですが…

213:デフォルトの名無しさん
07/11/18 16:50:06
putStr.unlines.lines $ cs
なら通るよ。
関数適用とか演算子の優先順位の問題だね。

f $ g x == f . g $ x /= f . g x

214:デフォルトの名無しさん
07/11/18 16:55:54
うろ覚えだが関数抽象より関数適用のほうが優先されるので、
「putStr.unlines.lines cs」の部分が

putStr.unlines.(lines cs)

って解釈されるはず

main = do
　cs <- getContents
　（putStr.unlines.lines） cs

ならたぶん通る

215:デフォルトの名無しさん
07/11/18 16:58:16
二項演算子の周りにはスペースを入れようぜｗ

216:デフォルトの名無しさん
07/11/18 17:00:37
C言語で、関数と括弧の間にスペース空ける人？

217:デフォルトの名無しさん
07/11/18 17:09:39
いや、そこは詰める
まあ>>215をあまり真に受けないでくれ

218:デフォルトの名無しさん
07/11/18 17:23:42
(.) の周りにはスペースを入れない派なんだが
f.g x.h のように関数が引数を持つ場合にやるとなんか微妙

219:デフォルトの名無しさん
07/11/18 17:25:16
関数合成が関数適用より優先度低いのが許せない。
こう決めた理由はあるの？

220:デフォルトの名無しさん
07/11/18 17:25:37
Haskellの解説文を読んでいて、どっかで見たことある書き方だなぁと
思ったら、数学の教科書とソックリです。

つまり、Haskellは数学ができる人向けってことでしょうか？

221:デフォルトの名無しさん
07/11/18 17:31:13
>>213-214
うお、通りました。ありがとうございます。
関数合成と関数適用の優先順位の問題だったんですね。

222:デフォルトの名無しさん
07/11/18 18:15:00
>>219
関数適用最強の原則を守るためじゃないか？
俺は現状で満足だ。
map (fromMaybe 0 . fst) xs
とか書けるし。

223:デフォルトの名無しさん
07/11/18 18:34:32
>>219
うざい括弧をつけなくて済む

224:デフォルトの名無しさん
07/11/18 20:16:16
　 (f.g) x
　↑↑うざい括弧

225:デフォルトの名無しさん
07/11/18 20:23:03
f.g $ xじゃね？

226:デフォルトの名無しさん
07/11/18 20:42:38
>>224
C言語風には f(g(x))
うざくない？

227:デフォルトの名無しさん
07/11/19 03:14:41
URLﾘﾝｸ(hpcgi2.nifty.com)
このページの2007-07-04の日記を参考にプログラムを書いているのですが
これで横型探索できる理屈がまったくわかりません

228:デフォルトの名無しさん
07/11/19 03:39:03
Stateモナドについて質問なんですが
instance Monad (State s) where
　　　　　　　　　m >>= k = State $ \s -> let
　　　　　　　　　　(a, s') = runState m s
　　　　　　　　　　in runState (k a) s'

↑の式でm >>= k　が m >> kなら、右辺は
State $ \s -> let
(a, s') = runState m s
in runState k s'
((k a)がkだけになる)
という風になると考えていいんでしょうか?

229:227
07/11/19 04:04:21
227ですが一応目処が立ちました。

230:デフォルトの名無しさん
07/11/19 04:24:37
>>228
それでOK。
ただm >>= kとm >> kのkはそれぞれ別の型だってことに注意。

m1 >> m2 = m1 >>= const m2 なので k=const m2 と考えると
runState (k a) s'
= runState ((const m2) a) s'
= runState m2 s'

231:228
07/11/19 10:59:03
うーん、難しい
>>=が一つだけならなんとか頭で理解できるんですが>>=が二つ以上ならんでいたり
do式で表されていたりすると脳味噌が追い付きませんorz

232:143
07/11/19 23:12:23
*GHC-6.6.1のクロスコンパイルについて公式ページのwikiに書いてない部分*

＜ターゲット、ホストに共通＞
デフォルトサーチパスにGNU MPがない場合は--with-gmp-{includes,libraries}で指定する必要があるが、
途中からこの指定（ライブラリサーチパス）を見てくれなくなる上、
できあがったGHCでも-Lオプションを指定しなければいけなくなるので
（少なくともlibgmp.so.*かlibgmp.aファイルのどちらかを）デフォルトサーチパスにシンボリックリンクしておくほうがいい。

＜ホスト＞
ghc-6.6.1/Makefileの
echo ghc-$(ProjectVersion)/libraries/haskell-src/Language/Haskell/Parser.hs >> hc-files-to-go
という行を削除またはコメントアウトする必要がある。

libraries/Cabal/cabal-setup/CabalSetup.hsが作られないので、
cd compiler && make boot && makeの後、
cd libraries/Cabal/cabal-setup
rm CabalSetup.{o,hi} cabalsetup
../../../compiler/ghc-inplace -H16m -O -H32m -package Cabal -c CabalSetup.hs -o CabalSetup.o -ohi CabalSetup.hi -keep-hc-files
../../../compiler/ghc-inplace -o cabal-setup -H16m -O -H32m -package Cabal CabalSetup.o
する必要がある。

make hc-file-bundle Project=Ghcの前に、
make -C rts AutoApply_thr.hc AutoApply_thr_p.hc AutoApply_debug.hc AutoApply_thr_debug.hc
する必要がある。

続く

233:143
07/11/19 23:14:33
*GHC-6.6.1のクロスコンパイルについて公式ページのwikiに書いてない部分* 続き

＜ターゲット＞
いきなり/usr/localにインストールするのではなく、stage1のためのディレクトリにインストールして、
それを利用してもう一度ghcをビルドしたほうがいいと思われる。

*-hc-tar.gzをソースツリーにコピーするのではなく、展開されるghc-6.6.1を手動でソースツリーに上書きする必要がある。

distrib以下のスクリプトに実行権限を与える必要がある。

hc-buildが完了した後、
cd compiler
rm -f *.hs-incl
make primop-can-fail.hs-incl primop-commutable.hs-incl primop-data-decl.hs-incl
primop-has-side-effects.hs-incl primop-list.hs-incl primop-needs-wrapper.hs-inc
l primop-out-of-line.hs-incl primop-primop-info.hs-incl primop-strictness.hs-inc
l primop-tag.hs-incl primop-usage.hs-incl
find . -name \*.o -exec rm {} \;
make boot stage=1 && gmake stage=1
cd ..
make install stage=1
で完了。

ちなみにザウルスのOpenBSD上では16MB以上のテキストセグメントがある実行ファイルは実行できないので
テキストセグメントを32MBに拡張したカーネルを使用しなければビルドできませんでした。
GNU makeがmakeという名前以外（gmakeなど）でインストールされている場合は、適宜読み替えてください。
かなり効率の悪い方法なので、Makefile等をちゃんと読めばもっと最適化できると思います。

古いGHCで新しいGHCをビルドするのはうまくいきますが、
新しいGHCで古いGHCをビルドするのはなかなかうまくいきませんね。

234:デフォルトの名無しさん
07/11/20 08:39:00
一度評価された式をもう一度評価しようとする場合って、再度最初から評価しなおすんですか？

例えば
add x y = x + y
という関数があって、一度
add 1 2
という式を評価した後もう一度
add 1 2
を評価しようとするとき、内部では律儀に 1 + 2 を行うんでしょうか？それとも
add 1 2 = 3
みたいな式が内部で作られてたりするんでしょうか？

235:デフォルトの名無しさん
07/11/20 09:30:04
↑の場合は俺も知りたいです

俺が知ってるのは
f x a b c = a*x*x + b*x * c
という関数に対して
f (1+2) 3 4 5
と呼び出した場合に1+2が1度しか評価されないことくらい…

236:デフォルトの名無しさん
07/11/20 10:20:01
>>234
Haskellの規格では規定されてないけど、普通は評価しなおす。
関数を全部メモ化していたら、救いようのないメモリリークが起こるはず。ただし、
map (\x -> x * add 1 2) xs
のようなコードが最適化されて
let _z = add 1 2 in map (\x -> x * _z) xs
になって、add 1 2が一回しか計算されない、という場合はある。

237:デフォルトの名無しさん
07/11/20 11:41:31
>>234-235
コンパイラのコンパイルオプションによっても動作が違うかな

import System.IO.Unsafe
f n=seq (unsafePerformIO $ putStrLn "hello") n

a=f 1+f 1

main=print a

のようなコードだとGHC6.6.1の場合で最適化なしの場合とありの場合でhelloの表示回数が違ったりする。

238:237
07/11/20 11:44:46
追記

a=f 1+f 2

でも最適化ありで1回表示、無しで２回表示でした。

239:デフォルトの名無しさん
07/11/20 18:31:21
質問なのですが、
ドラキュラとかが眠ってそうな感じの、棺おけ型のベッドというのは市販されているのでしょうか？
冬の暖房の時期に、部屋ごと暖めるのでは効率が悪いので、棺おけの中だけ温度調節できれば
コスト安になると思ったのです。
また、フタをつけるので静かですし、明かりもシャットアウトできてよいと思うのです。

240:デフォルトの名無しさん
07/11/20 19:04:23
ドラキュラとかが眠ってそうな感じの、棺おけ型のベッドというのは市販されているのでしょうか？
（計算をデフォルトで遅延させる機能のある、関数型のプログラム言語は市販されているのでしょうか？）
冬の暖房の時期に、部屋ごと暖めるのでは効率が悪いので、
（評価されない可能性のある式を正格に評価するのは効率が悪いので）
棺おけの中だけ温度調節できればコスト安になると思ったのです。
（必要になってから評価できれば計算コストを削減できると思ったのです。）
また、フタをつけるので静かですし、明かりもシャットアウトできてよいと思うのです。
（一度評価されればメモ化されるので計算量が少なくなりますし、バグの混入もシャットアウトできてよいと思うのです。）

答え：Haskellは無料で公開されています

こうですか！？わかりません！

241:デフォルトの名無しさん
07/11/20 19:27:37
感動した

242:デフォルトの名無しさん
07/11/21 04:31:54
質問です

GHC6.8.1にはHGL入ってないんですか？

243:デフォルトの名無しさん
07/11/22 01:59:38
Windowsアプリ作っていて気づいたんだが、
Win32モジュールにはSetLayeredWindowAttributesのラッパは入ってないんだな・・
自作するしかないんだろうか。

244:デフォルトの名無しさん
07/11/22 07:26:41
書いてパッチを送るんだ！

245:デフォルトの名無しさん
07/11/22 12:20:00
>>244
>書いてパッチを送るんだ！
いや、これってwindows2000以降の機能で、Win32モジュールに入れるべきかどうか正直迷うんだよね。

246:デフォルトの名無しさん
07/11/22 23:16:48
Windows2000以降のラッパをまとめたWin32exモジュールを作ったので公開しました。
ツッコミなどよろしく。

247:デフォルトの名無しさん
07/11/23 09:58:22
>>245
Windowsに詳しくないので間違ってたら済まんが、2000以降のみの関数も
普通にwin32パッケージに入ってないか？setConsoleCPとかfindFirstChangeNotificationとか。

>>246
どこに置いたかも書けよｗ

248:デフォルトの名無しさん
07/11/23 10:06:51
246はPeyton Jonesだ。

場所は、わかるだろ。

249:デフォルトの名無しさん
07/11/26 23:05:20
関数型言語はマルチコア時代にフィットしているという話を聞いたことがあります。
既存の流行している言語は対応できてないと。

これはどういう理由でしょうか？遅延評価とか、その辺のことを指しているんでしょうか。

250:デフォルトの名無しさん
07/11/26 23:13:40
知らんけどミュータブルな値があるとスレッドセーフにならないとかそういうへんの話じゃね？

251:デフォルトの名無しさん
07/11/26 23:23:18
MapReduce の「副作用が無ければ無限にスケールする」というのが
一人歩きしてるだけじゃないかな。実際には何をするにも副作用は
あるし、MapReduce だって Reduce の作業はスケーラビリティが
殆ど無いか少ない。関数型言語には副作用が無いというのと同じ様な
勘違い。ただ副作用が無い＝スケールする部分を奇麗に切り出せる
のであれば有用ではある。

252:デフォルトの名無しさん
07/11/27 11:43:41
ああいう大規模データパラレルとマルチコアはあんまり関係ないじゃん。
>>249の話は伝聞なんで雲を掴むような話だけど。

253:249
07/11/27 11:48:13
ありがとうございます。透過参照性がスレッドセーフというのはよく分かります。

遅延評価っていうのは、別に関係ないんでしょうか。何かそっちの話を聞いた
ことがあるんです。自分の初心者脳では、正格では無限のリソースを前提に
した関数を書けないが、Haskellのような言語だと記述可能、とか思ったのですが、
ちょっと頭悪いですか？ｗ

254:デフォルトの名無しさん
07/11/27 12:16:38
遅延評価や投機実行をうまく使えば、
CPUコアの利用効率を上げられますが、
それには頭のいいスケジューラが必要なわけで。

例えば、
URLﾘﾝｸ(www.fixstars.com)
にプチ解説があるようなstragglersの問題。

ただ実行順序が規定されてないので、
工夫する余地がまだまだ残されているとは言えると思う。
Erlangのような言語が、あまりpure functionalじゃないとはいえ、
一通りの実績を上げていますし。

また、プログラマがスケジューラに自由を与えるような
プログラミングスタイルを強制されているという見方もあると思う。

255:デフォルトの名無しさん
07/12/06 10:41:19
F#のスレは毎日更新されてますが、こちらは静かですね・・・

関数型で今イチバン売れ筋なのはF#なんですかね。

256:デフォルトの名無しさん
07/12/06 17:36:48
Haskell始めてから3週間目の今の感想。
・概念的にはMonadよりArrowのほうが分かりやすいんじゃないか？とか。
・Monadって何？って聞かれるとなんと答えていいかわからないが、
　　Arrowなら『矢印をカプセル化したようなもの』と言える。
　　あとは適当に結合演算とか普通の関数をアロー化する演算とか実装していけばおｋ。
　　脳内のイメージも矢印をつないでいくだけだし。
　　Monadをイメージしようとしてもなんかいまいちピンとこない……。
　　bindにやる夫関数とか適当に名前を付けて無理矢理イメージしたけど。
・Monadのbind演算子(>>=)はm a -> (a -> m b) -> m bで非対称的。
　　Arrowの(>>>)はa b c -> a c d -> a b dで比較的対称性があって気持ちよい。
・Arrowは『計算を結合』しているのが自明的に表現されてる。
　　Monadは別にそうは見えない。……値と計算を結合なのか？意味わかんね。
・そもそも非対称な二項中置演算子はイマイチ気に入らない。
　　リスト結合演算子とか`elem`とかは仕方ないけど、せめてあまり高階にしてほしくない
・Monadの計算部(a -> m b)は結構重要なパーツの一つなのに、名前が付いてない。
　　だから『モナドを返す関数』としかいえねえ。
　　しかもbindした後にはその返り値とは（型は同じだけど）別の奴が帰ってくる。無駄に混乱。
　　その点Arrowは計算部がずばり『Arrow』。カプセル化されていて美しい。
・Monadは(>>=)は左から右へ流すように使えるが
　　普通の関数は右から左。もちろんliftMとかも右から左。
　　(=<<)も右から左。しかし関数を拡張して適用するという見方で見るとこっちが自然という謎さ。
　　結局どっちからどっちへ読むべきか迷う場所が多く、思考停止してしまう。
　　ArrowだったらArrowとして結合されている部分は左から右。
　　普通の関数は右から左で思考が自然に切り分けられる。

257:デフォルトの名無しさん
07/12/06 17:37:32
・Monadでポイントフリースタイルをやろうとするとかなりキモくなるよね。
　　Arrowはまあ基本的にポイントフリーな感じがするし、普通の関数と分けられていいんじゃない？
・Arrowの構造を作ったりする関数は基本的にArrowだけを返す。
　　Monadの関数はなんかリストとかに入ってたりして気味が悪い。モナドのリストって、最中十個入りじゃないんだから。
・Arrowの構造を作る関数はキチンと構造を作ってるように見える。
　　Monadの場合は解読に時間がかかる。なんのためにこんな書き方をしてるんだろうとか……。
・ArrowでStateを自作してみたら比較的分かりやすかった。
　　Monadのは今見ても訳が分からん。というかMonadの対象が関数って何だよ。
・Monadに慣れ親しんでる人はMonadを扱うのに苦労しないだろうから、
　　簡単なものなら短い表記が出来るMonadのほうがいいんだろう。
　　しかし、初心者にいきなり教えるのならArrowのほうが直感的。
　　ポイントフリースタイルを使いまくってムツカシイことさえしなければ。
・Arrow講座みたいな入門編とかでArrowを書くとき、
　　関数がそのままアローになるからってやたら省略しないでいただきたい。
　　アローな部分と普通の関数の部分が綺麗に分かれてるのがいいんだから……
　　それにarrってやっておけばその部分は一般のArrowでも使えるし。
　　SF f >>> SF g = SF (f >>> g)とか出来るからそういう書き方が出来ること自体はありがたいが。
・arr.uncurryとかarr.constってよく出てくるけどそういう関数はないのか……
・Arrow関係ないけどデータ構築子と型構築子が同じ名前って混乱するな。時々イラっとくる。
・aとかbとか何を表してんのか直感的じゃねえよ。型変数だったり、引数だったり……
　　fって名前だから関数かと思いきやArrowだったり。
　　ネーミング規約みたいなものはないのか……
　　Arrowが引数で来たときの名前の付け方とかおもいつかねえけど。
・そろそろふつける買おうかな……。
・初心者のくせに身の程をわきまえない長文失礼しました……

258:デフォルトの名無しさん
07/12/06 17:42:34
>>257
> ・Monadでポイントフリースタイルをやろうとするとかなりキモくなるよね。
もう少し他人のコードを読んでいくと感覚がつかめてくると思いますよ

259:デフォルトの名無しさん
07/12/06 18:11:18
モナドのリストを返す関数なんてそんなに使うか？

しかし「モナドのリスト」って言い方は何か違和感あるな。
[IO]みたいなのを想像してしまう。

260:デフォルトの名無しさん
07/12/06 18:16:50
俺のポリシーではIOはmain内でしか使わない

261:デフォルトの名無しさん
07/12/06 18:25:06
>>258
把握。

>>259
ライブラリを見返してるけどそこまではなかったかも……。
初めて見たときに比べればそこまで疲れないし。
やっぱり慣れの問題なんだろうか。『モナドを返す関数』が普通の関数と同じ地位にいるのがイマイチだけど。
引数の数でバージョンがいくつもあったりするのもなんかいただけない。
でもやっぱり慣れれば気にならなくなるんだろうな……。
なんかJavaやったらCのポインタが理解できた時の気持ちを思い出した。（違うか）

262:デフォルトの名無しさん
07/12/06 18:30:02
モナドなんてステートとIOとリストとMaybe以外はほとんどつかわねーぜ

263:デフォルトの名無しさん
07/12/06 18:30:44
IORefもつかうか。

264:デフォルトの名無しさん
07/12/06 18:38:36
a0 -> a1 -> ... -> m bの形の関数を呼ぶのにはmonadic functionという名前が使えるはず。
日本語だと「モナドな関数」か。

俺のコードの大部分はモナドな関数になってるな。
普通の関数より書きにくいから嫌なんだが、変更に強いコードにするために仕方なく。

265:デフォルトの名無しさん
07/12/08 12:05:09
やさしいHaskell入門での質問です。

URLﾘﾝｸ(www.sampou.org)
> (ここで、同値性といっているのは、「値同値性」のことです。
> 対照的な概念としては、「ポインタ同値性」というのがあります。
> たとえば、Java 言語の == です。
> ポインタ同値性は参照透明性を持ちません。
> それゆえに純粋な関数型言語とは相性がよくありません。)

なぜポインタ同値性は参照透明性を持たないのですか？

266:デフォルトの名無しさん
07/12/08 12:26:42
>>265
ポインタ同値をテストする関数eqがあったとすると、
let v = [1,2] in eq v v
はTrue。一方、vを展開して
eq [1,2] [1,2]
とするとFalseになるかもしれない。
参照透過って言うのはそもそも、こういう展開をしても
プログラムの意味が変わらないってことだから、
eqによって参照透過性が破られたと言える。

267:265
07/12/08 12:37:55
>>266
おー！なるほど。わかりやすい説明ありがとう。
[1,2] が複数箇所に出現する場合、メモリ上に別々に配置されるかもしれないわけですね。
勉強になりました。

268:デフォルトの名無しさん
07/12/09 15:29:39
『A a』っていう表記が使われる場所によって
Aは型構築子、全体は多相型、aはパラメータ
Aはデータ構築子、全体はデータ構造、aはその中身
aは型クラスAのインスタンス、何かの型の一部
って変わるのがちょっとわかりにくいね。もうちっとなんとかならんか。

269:デフォルトの名無しさん
07/12/09 21:35:19
Haskell勉強してなくてよくわからないんですが、
乱数生成器をsplitしていくつかにしてseed固定で乱数を作れといわれました。
どう作ればいいんでしょうか？
初歩的な質問だったらすみません。

270:デフォルトの名無しさん
07/12/10 00:51:19
日本語でおｋ

271:デフォルトの名無しさん
07/12/10 15:07:15
無限リストって便利だけど、末尾を正格に要求する関数について型安全じゃないよね。
でも無限リスト型を再定義するとリストに関して作ったすべての関数について委譲関数を作んなきゃいけなくて現実的じゃない。
結局これは妥協するしかないのか？それともなんらかのテクニックで回避できる？

272:デフォルトの名無しさん
07/12/11 10:46:48
>>271
日本語でおｋ

273:デフォルトの名無しさん
07/12/11 10:52:25
>>271
俺の知る限り、妥協するしかない

274:デフォルトの名無しさん
07/12/11 12:46:45
>>271
評価がとまらないだけで型安全だよ。

275:デフォルトの名無しさん
07/12/11 13:17:06
そう言えば、厳密に言うと無限ループでも型安全なんだな
でも全域関数でない関数が厄介なことは事実だから、何か呼び名が欲しい

276:デフォルトの名無しさん
07/12/11 17:14:07
>>275
よくわかんないけど、チューリングの停止問題のこと言ってるの？

277:デフォルトの名無しさん
07/12/11 17:30:25
>>276
いや、Haskellには失敗し得る関数があるじゃん
例えば、headはリストが空の時例外を飛ばすし、
lengthは無限リストに適用されたら終わらない
一方で、例えばdropみたいに、引数に未定義値が含まれない限り、
あらゆる引数に対してちゃんと値をもどす関数もある
だからこの二つを区別できるように、短い呼び名があれば便利だな、ということ
「型安全」という言葉を使いたくなるけど、これは>>274の言う通り誤用だし

278:デフォルトの名無しさん
07/12/11 17:40:12
>>277
そういう一般的な関数のことを部分関数というんじゃないかね

279:デフォルトの名無しさん
07/12/11 18:03:01
>>278
全域関数も部分関数の一種だから、とか考えてたけどカジュアルに使う分には問題ないか
グダグダですまん

280:271
07/12/11 19:46:50
いや、同じ構造のデータ型でも、
型システムで『無限リストかそうでないか』をカッキリ分けられたら、
そっちのほうが型安全にならないかな？と思って271を書いたんだけど。

たとえば幽霊型とか使ってそういうのが解決できないかとか思ったんだけど、
それじゃ現行の関数を活かせないし、あんまり意味ないなあ、と。

281:デフォルトの名無しさん
07/12/12 01:00:18
>>280
言いたいのは、型システムを使って、
無限リストのフロー解析をして、
プログラムの停止性、正当性などを知ることができないかってこと？
それならリストの有限性の抽象解釈をやるってことになると思うけれど。

282:271
07/12/12 01:16:01
>>281
違う。返り値が無限リストの関数で、その関数の型を明示しておけば、
無限リストに対して使ってはいけない関数の引数にした時に型エラーになるようにしたい。
まあ無理っぽいのでもう諦めてるけどな。

283:デフォルトの名無しさん
07/12/12 02:43:32

※起こりえる全てのリストのうちどれが有限リストかを確かめることは
　無限に長いリストに対して演算を行うことと同じ

ってだれかが言ってた

284:デフォルトの名無しさん
07/12/12 07:57:59
だから誰も自動チェックしてくれって言ってるわけじゃないじゃない……
静的に型推論してくれるんだから、
enumFromにInt a => a -> [a] Inf
って書けるとして
lengthに[a] Ltd -> Int
みたいに指定したらコンパイルエラーになって欲しいとかそういう問題だって。無理だけど。

285:デフォルトの名無しさん
07/12/12 08:17:31
enumFromよりrepeatのほうが良かったな（repeat :: a -> [a] Inf）
あとコンパイルエラーになって欲しいのは『length.repeat x』みたいな文脈な。

286:デフォルトの名無しさん
07/12/12 09:39:03
strictな言語なら、force/delayみたいに陽に指定するんだろうから、
>>281の言うような方法も効果を挙げるだろうが、
lazyな言語だと、リストを生成する全ての関数が、
無限リストを返す可能性があるので>>276でFAだが。

[1..]が無限リストであることも、解析が必要になるし。
うまくできるケースもあるが、希少すぎる。

287:デフォルトの名無しさん
07/12/12 11:18:26
>>271が見事に無視されててワラタ

288:デフォルトの名無しさん
07/12/12 11:39:59
言葉の使い方間違ってるよな。

289:デフォルトの名無しさん
07/12/12 17:16:57
なんというか残念賞な言語だな。
関数言語としてのおいしいところは全てC#3.0に持っていかれてしまった。

290:デフォルトの名無しさん
07/12/12 17:26:09
それはギャグのつもりでいっているのか

291:デフォルトの名無しさん
07/12/12 17:27:04
>>289
関数言語？ｗ
C#3.0？ｗ

292:デフォルトの名無しさん
07/12/12 18:12:14
>>289
F#じゃなくて、C#かよ・・・

293:Wadler
07/12/12 22:26:38
Haskell初心者です。
a->[a]という(型の)monad(仮にDとしましょう)をつりたくて困っています。
どなたか教えてください。
とくにDのmapFにあたる関数も教えていただけれありがたいです。

294:デフォルトの名無しさん
07/12/12 23:11:10
>>293
はい？

295:デフォルトの名無しさん
07/12/12 23:12:01
とりあえず、日本語でおｋと言ってほしいのですか？

296:デフォルトの名無しさん
07/12/12 23:13:50
>>295
日本語でおｋ

297:デフォルトの名無しさん
07/12/13 00:02:02
よくわからんが
data D a = mkD (a -> [a])
instance Monad D where ...
ってことか？
あとmapFってなんだ？fmap？

298:デフォルトの名無しさん
07/12/13 01:20:15
>>293
よくわからんが、釣りってことか？

299:デフォルトの名無しさん
07/12/13 01:23:14
>>297
mkDはなぜ先頭が大文字になってないんだ？
受理されないだろ。

300:デフォルトの名無しさん
07/12/13 01:25:29
なんなんだ？
近頃Haskellerの質の低下が激しすぎるぞ

301:デフォルトの名無しさん
07/12/13 02:15:06
昔からです

302:デフォルトの名無しさん
07/12/13 02:20:10
割と玉石混淆なイメージだね

303:デフォルトの名無しさん
07/12/13 02:23:35
暇つぶしで弄ってる学生がここで暇を潰しているイメージ

304:デフォルトの名無しさん
07/12/13 08:17:19
>>299
>>303
そのとうりですすいません……

305:デフォルトの名無しさん
07/12/13 11:07:28
>>268-304
この辺からおかしくなってきてる

306:デフォルトの名無しさん
07/12/13 11:49:46
なんにしてもHaskellerが増えるのは喜ばしいことだ

307:デフォルトの名無しさん
07/12/13 11:51:12
rubyみたいになるぐらいなら少なくてもいい

308:デフォルトの名無しさん
07/12/13 16:58:02
少数精鋭投入ならこれでいいだろうけど
大人数投入用にｺｰﾄﾞもﾃﾞｰﾀもﾌﾞﾗｯｸﾎﾞｯｸｽにできる仕組み（命令型のｵﾌﾞｼﾞｪｸﾄ指向同等？）誰か作らないのかな

309:デフォルトの名無しさん
07/12/13 17:07:09
大人数投入っていまどき流行らないよ
人海戦術でプログラミングする時代は終わった

310:デフォルトの名無しさん
07/12/13 17:23:49
>>308
ブラックボックス化ってどんなの？
カプセル化なら標準のモジュールシステムがあるけど

311:デフォルトの名無しさん
07/12/13 17:28:42
>>308
そんなにオブジェクト指向がやりたいなら
つ　O'Haskell

312:デフォルトの名無しさん
07/12/13 17:30:17
でも、そもそもオブジェクト指向は型理論に包含されるものだから・・・

313:デフォルトの名無しさん
07/12/13 17:31:50
デバドラ屋と少数のhaskellerがいればたいていのプロジェクトは成功する
・・・夢を見た

314:デフォルトの名無しさん
07/12/13 18:14:01
>>308
そもそもhaskellにはオブジェクト指向は不要なんですよ。
というのも、関数の再利用できる範囲がCやらjavaやらとは桁違いに大きいのが特徴だからです。

315:デフォルトの名無しさん
07/12/13 21:20:25
Haskellでモジュールつかってカプセル化してコード書いている人あまりいないような気がするんだけど気のせいかな。

316:デフォルトの名無しさん
07/12/13 21:22:03
なにを根拠に?

317:デフォルトの名無しさん
07/12/13 21:35:09
>>315
そもそもhaskellを使って実用アプリを公開してる人があんまりいないんだから
仕方ないだろ。

318:デフォルトの名無しさん
07/12/13 22:49:47
Haskellって関数型言語の勉強用じゃないの?

319:デフォルトの名無しさん
07/12/13 23:10:30
それだけのための言語だとどうして思うのですか？

320:デフォルトの名無しさん
07/12/14 00:39:15
GHC 6.8.2が出てるね。
GHCiの機能追加がメインっぽい。

321:デフォルトの名無しさん
07/12/14 00:53:25
HaskellはOOじゃなくて、
generic programing指向だからなあ。
Genericsの世界では最強認定を受けてる。

322:デフォルトの名無しさん
07/12/14 01:21:07
OfficeがHaskellで書きなおされるまで俺はその有用性を認めない。

323:デフォルトの名無しさん
07/12/14 02:29:17
スケーリングのための言語じゃないんだよな
工場制手工業ならOOであることやポピュラリティ（みんなが使ってること）は必須だ。

324:デフォルトの名無しさん
07/12/14 13:26:48
別に必須じゃないし。
今流行ってること取り入れたってどうせちぐはぐになるだけ。

325:デフォルトの名無しさん
07/12/14 13:28:05
っていうかさ、人海戦術の奴隷商売に慣れすぎていて、理性的な考え方を失ったお猿さんですか？

326:デフォルトの名無しさん
07/12/14 14:15:06
ポピュラリティが必須というのは分かるけど、OOが必須というのはおかしくね？
OOは一手法に過ぎないんだから、もっと良いものが知られればそっちが使われるようになるだろ

327:デフォルトの名無しさん
07/12/14 14:21:57
OOは現時点でのポピュラリティの1つって事ならわからなくもないけど、
わざわざ分けて必須って言うほどのものではないな。

328:デフォルトの名無しさん
07/12/14 14:54:59
つーか、OOはstableなlibrary構築にはいいんだけど、
意外とreusabilityが悪いから、
generic programmingが注目されているのが現状です。
Haskellのtype classとかC++のconceptみたいなやつ。

C++はtemplate/traitsでやってましたが、ちょっと非力なので、
Haskellのtype classそっくりの"concept"が入る事になりました。

329:デフォルトの名無しさん
07/12/14 14:59:18
実際これはOOと比べてどうなんだとか思ってたんだけど
実際使ってみたら意外とオブジェクト指向のメリット包含しててＳＵＧＥＥとか思った

330:デフォルトの名無しさん
07/12/14 14:59:57
>>328
日本語でおｋ

331:328
07/12/14 15:35:51
日本語ですよ?

332:デフォルトの名無しさん
07/12/14 15:45:42
決して英語が読めないわけではないが、
不自然だ
読みにくい
目が痛い

333:デフォルトの名無しさん
07/12/14 16:23:51
理論はそのとおりなんだが、残念だがそんな理論を理解出来る人間は少数派なんだよ。
共産主義みたいなもん。高尚な理屈よりも明日パンが、今日のバグを潰せるかが問題なわけだ。

いいじゃない。Haskellは芸術的な小物を個人で作るのに向いてるってことで。

334:デフォルトの名無しさん
07/12/14 17:07:50
>>333
多数のバカよりも少数の優秀な人間でプログラミングしたほうが安く早くできます。

335:328
07/12/14 17:08:28
>>332
そういう意味か。すまん

>>328については、
URLﾘﾝｸ(journals.cambridge.org)
で。探せばピィーディーエフも見つかるようです。

336:デフォルトの名無しさん
07/12/14 17:09:42
>>333
どの辺の理論のことを言ってるの？

337:デフォルトの名無しさん
07/12/14 17:10:46
>>335
不自然だ
読みにくい
目が痛い

お前は日本語文書の常識を勉強したほうがよさそうだな

338:デフォルトの名無しさん
07/12/14 17:16:49
どっちにしろ、今みたいに人気がなくて、そのせいでライブラリも
周辺環境も整っていない状況だと、小物を個人で作るのすら満足にできん。

339:デフォルトの名無しさん
07/12/14 17:43:43
wxhaskellが使いやすい
が、6.8系用が出てない・・6.6系は非公式

340:デフォルトの名無しさん
07/12/14 17:52:21
いまだと.NETやJavaVMに乗せちゃえばライブラリ不足は一挙に解決だな。

341:デフォルトの名無しさん
07/12/14 17:56:18
>>339
普通にdarcs版をビルドできないか？

342:デフォルトの名無しさん
07/12/14 17:56:46
>>340
なんで？

343:デフォルトの名無しさん
07/12/14 19:53:13
conceptの導入をもってHaskellはC++のサブセットになります
つまりこれで全ての言語がC++のサブセットになるというわけです

344:デフォルトの名無しさん
07/12/14 20:54:45
本日をもってHaskellはウジ虫を卒業する
本日からHaskellはC++のサブセットである
兄弟の絆に結ばれる
Haskellのくたばるその日まで
どこにいようとC++は貴様らの兄弟だ
多くはベトナムへ向かう
ある者は二度と戻らない
だが肝に銘じておけ
C++は死ぬ
死ぬために我々は存在する
だがC++は永遠である
つまり――Haskellも永遠である！

345:デフォルトの名無しさん
07/12/15 07:46:00
初心者質問です。

test = flip fun1 . fun2

の場合、

1. test = flip (fun1 . fun2)

2. test = flip (fun1) . fun2

どっちの意味なんでしょうか。(.)が使用されている場合、flipが対象とする
関数がどこまでかかるか分かんなくなってしまいました。

346:デフォルトの名無しさん
07/12/15 08:05:18
(.)よりも関数適用のほうが優先度が高いから答えは一応 2.なんだけど、
括弧の付け方としては (flip fun1) . fun2 のほうが正しい。

347:345
07/12/15 14:13:25
>>346
ありがとうございます。合成関数全体にかかるのかと思ってました。
もう少しいいでしょうか。

URLﾘﾝｸ(ja.doukaku.org)

にある、

attachIndex = map (uncurry (flip zipWith [0..] . ((,) .) . flip (,))) . zip [0..]

がよく理解できないのですが、

(flip zipWith [0..] . ((,) .) . flip (,)) 0 "abc"

の部分は

zipWith (((,) .) $ flip (,) 0) [0..] "abc"

と考えられると思うのですが、何ででしょうか。(flip zipWith [0..] . ((,) .) . flip (,)) の
第一引数"0"がまず部分適応されてflipされるところが理解できません。

348:デフォルトの名無しさん
07/12/15 14:41:26
(flip zipWith [0..] . ((,) .) . flip (,)) 0
から始める。まずこの式は(A . B . C) 0という形だからA (B $ C 0)に直せて、
flip zipWith [0..] ( ((,) .) $ flip (,) 0 )
これはflip A B Cという形だからA C Bと書き換えられて、
zipWith ( ((,) .) $ flip (,) 0) [0..]

349:345
07/12/15 15:29:30
>>348
ありがとうございます。しかし、まだちょっと理解できませんw

1.第一引数"0"の部分適応を行う
2.flip する

の順番の根拠がよく分かりません。

(flip zipWith [0..] . ((,) .) . flip (,)) 0 "abc"

の第二引数が最後に適応されるのは何故でしょうか。

あと、これは変な質問なんですけど、

(flip zipWith [0..] . ((,) .) . flip (,)) 0 "abc"

の形を慣れた方は直接記述できちゃうんでしょうか。それとも、

zipWith ( ((,) .) $ flip (,) 0) [0..] "abc"

の形から変形させていく形でプログラム書いていくんでしょうか。

350:デフォルトの名無しさん
07/12/15 15:37:45
>>349
Haskellでは基本的にどんな順番で簡約しても結果は同じだから、分かりやすい順序でやっただけ。
もっと実装に即した順序でやることもできるけど、面倒なだけな気がする。

>の形を慣れた方は直接記述できちゃうんでしょうか。
俺はできない。読むのも二分くらい掛かった。

次ページ