関数型プログラミング言語Haskell Part30 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
関数型プログラミング言語 Haskell について語るスレです。
haskell.org (公式サイト)
http://www.haskell.org/
前スレ
関数型プログラミング言語Haskell Part28
http://echo.2ch.net/test/read.cgi/tech/1428597032/ Wikipediaの人工知能に適した言語のリストにHaskellがあったけど、やはり最近流行りの統計的なアプローチがされているのかな
LogicTモナドが使えるらしいけどよく分からない 適しているという話は聞いても
使われているという話を聞いた事はない不思議 >>7
村主さんが開発したFormura(Formulaではない)というプログラムを自動生成するプログラミング言語があるみたい
人工知能ではないけど似たものを感じる ディープラーニングはほぼ完全にPythonに食われちゃった 前スレで質問しようとして何か変な風に失敗してしまいました...
再掲させてください
----
aojの問題でわからないところがあるので質問します.
http://judge.u-aizu.ac.jp/onlinejudge/description.jsp?id=0033
二股にわかれた容器に1から10まで番号のついたボールを番号の大小関係の制約を守って並べていけるかを判定する問題なんですが,自分のコードを提出するとruntime errorになってしまいます.
理由も考えたんですがよくわからないので,何がダメなのかアドバイスをお願いしたいです.
main :: IO ()
main = getContents >>= mapM_ (putStrLn . (\arr -> solve (tail arr) 0 (head arr, 0)) . map (read :: String -> Int) . words) . tail . lines
solve :: [Int] -> Int -> (Int, Int) -> String
solve arr index (box1, box2)
| index == length arr = "YES"
| otherwise =
if box1 < box2 then
solve arr index (box2, box1)
else
if arr !! index > box1 then
solve arr (index + 1) (arr !! index, box2)
else
if arr !! index > box2 then
solve arr (index + 1) (box1, arr !! index)
else
"NO" まあHaskellの質問だとHaskellスレで聞かないとスルーされるから
回答してあげるのが優しさってもんよ。 優しい回答例
エラーの原因を探し出しその場所をピンポイントで変更してあげる
優しくない回答例
面倒だから変更できそうな場所は必要あろうがなかろうが全部変更してみろ if arr !! index > box1 then
solve arr (index + 1) (arr !! index, box2)
else
の部分では、box1>box2 なのでどちらの分岐も考えられる
出力の型をBoolに変更し
if arr !! index > box1 then
solve arr (index + 1) (arr !! index, box2) || solve arr (index + 1) (arr !! index, box2)
else
でどうでしょう。で後からTrue,FalseをYES,NOに変えればOK 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) 訂正
if arr !! index > box1 then
solve arr (index + 1) (arr !! index,box2) || solve arr (index + 1) (box1,arr !! index)
else >>15
勘違い。これは原因ではないので無視してください 皆さん
反応ありがとうございます.
Haskellは周りに聞ける人がいなかったので助かります Haskellで競プロは隔靴掻痒という感想
実行制限時間がC++を前提に設定されてるから辛い
しかも Haskell 提出者が少なすぎて、AC 解答を覗いて速いコードを書く知見を獲るということができない
強い Haskeller 先輩各位は競プロサイトにアカウントを作って(競技には参戦しなくてもいいから)暇なときに過去問で誰も Haskell による AC が出てないものを適当に AC していって知見をバラまいてリードしてほしい >>10 の問題は実際のアプリ作りのどういうシーンに応用できるの? アプリの有用性ではなく難易度を研究してるんだろう
例えば人工知能が完成したらどれだけ役に立つかではなく
実際に完成する確率は何パーセントくらいかに興味がある 頓珍漢な質問かもしれませんが
ghciの:sprintでその時点での式の評価の深さを知ることができると思うんですが
評価の深さ自体を扱うプログラムを組むことってできるのでしょうか >>22
評価の深さって何?
浅い評価と深い評価の例を挙げてみてくれないか。
評価の深さ自体を扱うって、具体的には何がしたいの?
特に何かしたい訳じゃなければ、どういうプログラムを想定しているか、
に置き換えてもいいんたが、とにかく何か具体例がないと、
何を言っているのか分からん。 >>23
考えなしに深さという言葉を使ってしまいました
リストの評価についてです
Prelude> let xs = map (*2) [1..5]
Prelude> :sprint xs
xs = _
Prelude> xs `seq` ()
()
Prelude> :sprint xs
xs = _ : _
Prelude> length xs
5
Prelude> :sprint xs
xs = [_,_,_,_,_]
Prelude> xs !! 2
6
Prelude> :sprint xs
xs = [_,_,6,_,_]
Prelude> xs
[2,4,6,8,10]
Prelude> :sprint xs
xs = [2,4,6,8,10]
といったようになりますが
ある時点の評価について二つのリストが同じになる可能性があればTrue、なければFalseを出力するようなことをしたいと思っています。
例として、[_,_]と[_,_]や、_と[_,_]、_:_と[_,_]、[1,_]と[_,2]などはTrue。
[_,_,_]と[_,_]、[_,1]と[_,2]などはFalseになると言った感じです。
似たようなことがスマートにできる方法があれば教えて頂きたいです。 >>24
ghc-heap-viewとかのghcハック関係のライブラリや、それらのソースをあさってみてはどうだろう。
俺も調べてみて初めて知ったが、ghc-visって面白そうだな。 >>25
ありがとうございます!
その辺りを勉強してみます。 すごいとプログラミングの2冊よんだけど次どうすりゃいいの
本殆ど無いし 俺は静的型付けをゴリ押しされたのでHaskellをやってみたけど次はC++かな
静的型付けの本がないならHaskellとC++の本を読む >>27
CUIの家計簿アプリを作る。
それができたら、GUIの年賀状アプリを作る。 普段から家計簿をつけないし
毎年年賀状も出さない
作るならもっと実用的なアプリはないか Real World Haskell って不人気なの? Real World Haskell ってやつで勉強してみるは! >>31
じゃあ部屋の写真や動画から、その部屋の3Dモデルを生成するアプリは?
模様替えとか、新しい友人に紹介する時とかに便利。 質問
stack でドキュメントも同時に生成するようにビルドすると(haddock: true)、
依存してるstackageのパッケージのドキュメントは生成されるけど、
stack.yamlのextra-depsの項に追加したパッケージの物は生成されなかった。
後者のドキュメントも生成して、
~/.stack/snapshots/<arch>/<lts version>/<ghc version>/doc/
に追加したいのだが、何か方法はないだろうか? >>36
haddock-deps: true
でいけると思う >>37
ありがと、できた。
少し前に stack build --help でオプション一覧を見たはずなんだが、
ボケてたのか、すっかり見逃してたみたい。 >>37
できたと思ったら勘違いだった。
プロジェクト内の .stack-work にはドキュメントが作られるが、
~/.stack/snaoshots 内のドキュメントには融合されない。 >>27
プロジェクトオイラーあたりに取り組んでみるとか
アルゴリズム系で骨のある課題がお望みなら「珠玉のアルゴリズムデザイン」をどうぞ >>39
うーん、調べてみたけどわからなかった。
stack build --exec CMD でビルド後にドキュメントをコピーするか
stack build --haddock-arguments ARGS でstackからhaddockに渡るパスを上書きするとか
そういうのは思いついたけど、どっちにしても厳しいハックになると思う。 なんでStringってshowするときに” “ が付くの?
ダブルクォートが付かない汎用的なshowは無いの? >>41
調べてくれて、ありがとう。
こっちでもって調べてみたけど、そもそも同じ悩みを持ってる人が見当たらない。
とりあえず今回は諦めて保留にするよ。 実用上全く考えたこともなかったけど
show "ABC"
って
"\"ABC\""
って出力されるんだなwwwwウケる
show $ show "ABC"
"\"\"ABC\"\""
wwwwwwwwwww >>42
show 2 と show "2" が区別できないと困るじゃん >>42
どうしても欲しいなら作ればいい。
{-# LANGUAGE FlexibleInstances #-}
instance {-# OVERLAPPING #-} Show [Char] where show = id >>19
強いHaskeller先輩「(・・・これC++で提出した方が早いな)」 スペースリークの問題があってまともなコードには使えないというイメージを持ってるんだが
最近はその辺どうなってるのか知ってる?
自分はホームページ出力とかのメモリリークが問題にならないコードにhaskell使ってる
でもスペースリーク解決したらもっと色んなソフト開発に使ってみたい >>49
haskell-masterことtanakhさん! tanakhさんは最近はHaskellどころか競プロにRustで提出しだしてるよ…
tanakhさんはHaskellを見捨てたんだ… そもそもhaskell-masterと名乗って参加してたのがhaskell使えないTopCoderだったしなtanakhさん >>50
他の言語なら、いらなくなった変数にnullを代入することがスペースリークの解決策
nullを代入することには問題があるというイメージだったが
むしろ解決策じゃね?というイメージに最近変わった
その変化に貢献したのがHaskellだった >>50
あなたは何を以てスペースリークが解決されたと見なしてるの?
スペースリークを気にする必要がなくなった=解決なの?
もしそうなら、そんな未来は来ないと思う。
遅延評価を採用している以上、スペースリークは絶対に気にしなければならない。
あるヒープ領域がスペースリークなのかどうか、ランタイムシステムには判断できないんだから。
スペースリークなのかどうかがもっと調べやすくなる未来は来ると思うけどね。 これに関しては遅延評価でも並列処理でも同じこと
処理が終わったらメモリ解放されるが途中で止まったら解放されない問題 昨日の50だけど具体的には
n=1000とか先頭で決め打ちしといてコード書くのは大丈夫でも
上限を与えられるようにするとリークするので大きなnを与えられなかったり
配列の読み書きのコードを逐一doブロックに書くのはokだったけど
<<=を使って書いたらスペースリークしたこともあるし
いちいちこれはリークするのかとか考えながらコードはかけないなと思った
haskellでproject euler 200問弱といたけどその間に思ったことだよ
えっこれがリーク?みたいなのがある
>>55
明確なスペースリーク対策のガイドラインができたらかなぁ
>>54
俺はあれはクソコードが、と思ってた
javaならweakreferenceを使うという手があって
だから最近のapiは進歩しててandroidならsetBackgroundDrawableが非推奨になって
setBackgroundをつかえみたいになってるnull代入しなくてよくなってるような >>57
project euler の何番がスペースリークのせいで解きにくかったか思い出せる?
こっちでも検証してみたい。
思い出せないのなら、1番から順にやってみるけど。 >>58
さすがにそこまでは覚えてないけど後半はコードにスペースリークがあると
すぐセグメンテーションフォルトする
序盤の問題は時間もスペースも気にせず簡単に解ける問題が多いので
その目的なら100番ぐらいから始めた方がいいよ
1番からだとさくさく進んで楽しいけどね >>59
分かった。
100番以降で、かつサイズが決め打ちできないものをやってみる。 Project Eulerでの答えを求めるのには十分でも
HackerRankのProject Euler+の同じ問題でTLEしたりしたことある say :: Show s => s -> IO ()
say s = “Say, ++ show s ++ “!!”
print 1234
=> Say, 1234!!
print “Haskell”
=> Say, “Haskell”!!
ああああああああ!!!(ブリブリブリブリュリュリュリュ!!!ブッチチブブブチチチブリリリブブブゥゥゥゥッッッ!!!) showをユーザー定義する権利を与える代わりに「正しい」定義を決める義務がなくなる
というwinwinの関係 法則を満たしてるか静的にチェックする機構をコンパイラに実装することは理論上
@不可能
A可能(だが現実には困難)
B可能(で鋭意開発中)
C instance Show [Char] と書く方法の他に
instance Show Char の中で showList を定義するという方法もある 最近Haskellの勉強を始めたのですが、
["aa", "bb", f ["cc", "dd"] ] =
["aa", "bb", "cc", "dd"]
となるような関数fはどのように書けるでしょうか
もしくはそのような既存の関数はありますか >>69
やはり書けませんか…
ありがとうございます たぶんその前の時点でアプローチがHaskellのやり方じゃないんだろう どういう文脈でそれをしたくなったのか説明してくれれば
うまい代替案が出てくるかもよ 文脈は知らないが応用問題を作ればなんとなくわかる
length ["aa", "bb", f xs]
の値がコンパイル時に定数になることを証明せよ
または定数にならないような関数fを書け 68です
単なる興味本位で出来ないものかと頭を捻らせていたもので うーん
そもそも、それ許すとバグの温床になるからこその型だしねぇ。。。 Cのプリプロセッサというのを使うというのはどうだろう ["a","b"] ++ (id ["c","d"])
あかんの? Template Haskellの話題ではないのか haskellだと簡潔に書けるので
-shared で .dll(in windows), .so(in linux) を作って使っているのですが、
import Data.Text (or Data.List.Split.Internals)等で関数を書くと
.hsのコンパイルはいけるんですが
-shared の時に 定義されていない参照です, とエラーが出ます。
取り敢えず自分で関数書いてるので問題は無いのですが、haskellの勉強も兼ねて解消したいです。
どなたか教えて頂けないでしょうか FTPだっけ。あれどうなったか知ってる人いる?
length (4,2) == 1
になっちゃうやつ。 path パッケージの Path.parseRelDir 関数で、引数に "." や "../" が指定できないのは何故?
"." や "../" って相対パスちゃうの? > "." や "../" って相対パスちゃうの?
カレントディレクトリからの相対パスだが
そのpathパッケージとやらはカレントディレクトリを認識してるのか? 重城良国
Haskell 教養としての関数型プログラミング
Richard Bird 他1名
Haskellによる関数プログラミングの思考法
Haskell本が今度二冊も出るみたいですね >>88
「カレントディレクトリを認識する」ってのがどういう意味なのか分からんのだが。
たとえば filepath パッケージに System.FilePath があるけど、
こっちのはカレントディレクトリを認識してるって言えるの? >>87
なんかissueで普通ノーマライズするから不要で、そういうルールだとか言ってるが
その割に/をハードコードしてたり
言ってる意味不明だから使わない方がいいぞこれ >>91
path パッケージのラッパーになってる path-io パッケージは良さそうなんだが、
path の方がそんなんでは、どうもな・・・
アドバイスありがと、止めておくよ。 foldrと同じ働きの関数foldr'は
foldr' :: (a -> b -> b) -> b -> [a] -> b
foldr' f v [] = v
foldr' f v (x:xs) = f x (myFoldr f v xs)
で定義できますが、:tで調べるとPreludeのfoldrの型は
foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b
になってます。
foldr'の型宣言を同様に修正するとエラーが出ます。
エラーが出なくするために二行目の空リスト[]を
どう修正したら良いのか分からんとです。 訂正
上の myFoldr は foldr' の間違いです。 Foldableは単にfoldr出来ますよーってだけの型クラスだから
リストなどのインスタンスを持ってこないと具体的には定義できない
(==) :: Eq a => a -> a -> Bool
だけでは定義しようがないのと同じ FTPはとっくに取り入れられてた。base 4.8.0から。気付かんかったわ stackアップデートできねえぞ
atomでエラーでたぞ
ghciってなんでデフォルト一行なの
勉強用なの?ふつうつかわないの?
atomとそのコマンド、パッケージ選び
Gitって初心者なのに入れるの?
ないとターミナルいれられないんだが
ああめんどい
コマンドプロンプト見にくい
フォントきもい
ターミナル必要なのか
ビルゲイツしね
ターミナルってのないとエディタからコンパイルできないの?
コンパイルなし実行できないの?
ライブラリとはなにか、どこにあるのか
アトムから読めんのか
ライブラリよんで勉強するもんなのか
Windowsのディレクトリなにこれ
ユーザー名フォルダの場所とか意味不明
パスってなに、パスの通し方
こんなんググらせんなよ
よくこんなの考えやがったな
やること多すぎ 時間かかりすぎ
おぼえたくない 時間のムダ
技術じゃなくて雑学だな
自動化しとけまとめとけクソクソうんこ
それでもプログラマか
啓蒙する気ゼロだなほんと オブジェクトファイルとインターフェースファイルのこともちゃんとまえもって教えないとダメでしょ
qiitaとか入門云々とかはてなブログとかほんと死ねばいいのよ
なんでもかんでも初心者にググらせてんじゃないよ! コンパイラは難しい
昔の古いインタプリタは簡単だった
確率は1/2じゃなくて実際は9割以上が難解な方を選ぶんだろう 初心者じゃなくなってもなんでもかんでもググってる俺
カン拡張って何?ふむふむわからん Kan拡張?
聞いた瞬間分かるわ圏論由来ってwww
圏論の本読め 紙の本がなくなったら本を読むのもインストールで挫折する時代が来るかも 俺の部屋にはインストールで挫折した本が積み重なっている ネタバレはズルという思想があるよね
タダで教えてもらえるネタバレを全部理解してから本を買うという発想ができない FIT(Framework for Integrated Test)
http://fit.c2.com/
これの Haskell 実装にチャレンジしてる人いる?
そんな人のブログやHP知らない?
試しに GitHub を探してみたけど、見当たらない感じ。 Haskell objectiveってどうなったの?
やっぱダメだった? 使いやすさ的にどうだったのかなって。
作ったの日本人っぽいけど >>111
Haskellでの合成可能なオブジェクトの構成とその応用
https://fumieval.github.io/papers/ja/2015-Haskell-objects.pdf
>この章では、本稿で提案するオブジェクトの定義やその性質について説明する。なお、これから
>示すオブジェクトや関連する構造は、公開している objective パッケージ 1 に格納されている。
> 1 http://hackage.haskell.org/package/objective functor分からんとHaskellは使えないの? 凄いHを一通りやって、今はReal world haskellやってる途中
設計関連がまだよく分かってないな
モナド変換子とか非同期関連もよく分かってないや
関数型の勉強で始めたけど中々難しい
言語としては今の所簡潔で好きではある、ってか他言語の括弧がキモく見えてきた >>114
んな事ない。
と言うか、昔はファンクタ自体無かった。
モナドあるならファンクタも入れろや的な。
モナドも、使うぶんにはいつの間にか使ってる感じ。
モナドとは何か?とか考えると難しいけど、まあモナドもファンクタも型の一種。
そう言う特性の関数や演算子を使うための。
言わば、処理の流れにも型があるとでも思ってくれ。 >>114
実際的に重要なのはFunctorというよりも(そのインターフェースの)fmapの理解かな
多分よく出会うのはListのmapだけど、まずはこいつを使いこなせるようになれば
Haskellらしい、関数型らしい書き方ができるようになってくると思う モナド則は
型と関数と関数合成が満たすべきルール。
ただし自作モナドがモナド則を満たすことを保証する機構はない。 fromIntegralに短縮名つけるのが癖の人っている?
fI = fromIntegral 的な メッセージングシステムを主なアーキテクチャとしているアプリケーションにおいて、
そのメッセージの種類を増やすことでアプリケーションの機能を拡張する際に、
コンパイルすべきモジュールの数を最小限に抑える方法を探しています。
メッセージングシステムというと大げさかもしれませんが、
たとえば Win32API のウィンドウメッセージのようなものを想像してください。
モジュールAとモジュールM、およびモジュールTがあるとします。
モジュールTの中ではMsg型が定義されいます。
data Msg = MsgX String Int | MsgY [Double]
また、モジュールTはモジュールAとモジュールMの両方からインポートされています。
モジュールMの関数はモジュールAの関数を呼び、モジュールAの関数は型Msgの値を返します。
モジュールMの関数はMsgXが帰ってきた場合と、MsgYが帰ってきた場合とでその後の処理を変えています。
ここで、このアプリケーション機能を拡張しようと、Msg型にデータコンストラクタMsgZを追加しました。
そして、MsgZを返す関数を持つモジュールBを新たに作りました(もちろんモジュールTをインポートしています)。
ただし、既存のモジュールAは何も変更していません。
しかしそれでも、これをビルドする際にはモジュールAの再コンパイルが必要です。
インポートしている、つまり依存しているモジュールTが更新されたからです。
このような単純なメッセージングシステムの作りだと、どうしてもアプリケーションを拡張する際にモジュールTの更新が伴い、
それによって、変更していない多くのモジュールの再コンパイルが必要になります。
かといって極端な話、メッセージや付随するデータを ByteString 型にシリアライズすれば再コンパイルの問題は解決しますが、
今度は型の不一致や未定義メッセージなどのバグがコンパイル時に発見できなくなり、それもマズいです。
厳格な型システムの恩恵にあずかりながら、かつ不要な再コンパイルを抑えるようなメッセージングシステムの構築方法はないでしょうか。 javaですら良く分からんやつに
haskellのモナドなど分かるはずも無く ポインタ理解するときもモナド理解するときも小1で自転車補助輪外す時もみんな同じ感覚だった気がする
学習は滴定曲線のように、『気づいたら知って』いた たいていの概念は名前も説明も勿体つけてるが実はたいしたことはない
さらに最悪なのは長々と理屈ついている割に扱いは他の概念と変わらないやつだ
そういうのを世間では屁理屈という お前らってこういうのチェックしてたりするの?
Haskell News
http://haskellnews.org/grouped >>132
Haskellにはループ構文はありません。
一体何と比較した話でしょうか? >>134
Haskellの中で複数のアルゴリズムの比較はできますが、
C言語のforループとの速度の比較はできません。 バイナリを吐かせて逆汗すれば比較できるんでないの?
つっても多くの関数呼び出しはインライン展開されるんだろうが >>132
データ構造やコンパイラによる。
Haskellは基本リストなのでアドレスが連続してるとは限らない。
Cだと同じ処理を配列に施す様なループはSIMD命令に変換される。
Haskellはそう言う命令に変換する為のデータ構造使う。
(データの連続性を保証するためにもデータ構造が別なのだと思う)
IntelC++コンパイラとかだと最新のSIMD命令に対応してる。
gcc程度まではHaskellでも書き方次第では追い付けるだろうけど、CPUメーカー謹製の最新CPU対応コンパイラにまでは勝てない。
入門書レベルではHaskellはCに勝てないけど、いかなる並列・並行処理も否定してない。 そもそもHaskellのfoldとCのforループとでは、
速度を比較するための条件をそろえる事ができません。
たとえばプロセスを立ち上げてから処理し終えるまでの時間、
このレベルであればHaskellとCの比較に意味はあります。
実行環境という条件を同一にできるからです。
(ちなみに、この場合はCの方をHaskellより速くすることができます)
一方HaskellのfoldとCのforというレベルでは、まず計算するために入力するデータが違います。
foldの入力データ型はリスト(Foldableのインスタンス)ですが、同じものをCで再現できますか?
入力データをそろえなければ「関数程度のレベルの比較」に意味はありません。 扱うモナドがファンクタのとき
return . f =<< m
は
f <$> m
とシンプルに置き換え可能なのですね 何年か様子見してたけどやっぱり流行らんな
難しいから底辺には普及しないはわかるが
だったら上位の連中は食いつくかと言えばそんなことはなかった えっ、Modula-2とかCより読み易くて
低レベルのシステム記述も出来たのに
全然普及せんかったでw
政治的理由と思うが突然Turbo Modula-2
の販売が中止になってTurbo-C出たけどね。 普及言語からHaskellに乗り換えに難しく感じる部分
・do記法は関数で構成されるという関数型プログラミングの理解のための学習の邪魔をする(混乱させる)
・型を気にせず書けるスクリプト言語からだと強力すぎる型推論のおかげで型があるという感覚になじめず型に関するエラーでイラ立つ
・C言語系からだとreturnがreturn構文じゃない、if-elseが式である
・イミュータブルしかない、再代入が出来ない、(ように感じ)思うようにコード書けず辛い
・Haskellについて語る書の書き方や視点が数学寄りのものが多く理解が難しい(奴らが言うようなこまけえ数学っぽいこと気にせんでもコードは書けるっちゅうに純粋さにこだわりすぎ) そもそもハスケルの強みって何?
計算時間ではビジュアルスタジオに遠く及ばないだろ?
描画とか数学的処理も他の高級言語使った方がよくね? 仕様記述言語の強み
自分が強くなるために右往左往するよりも
強くなりたいならああしろこうしろと指図して右往左往させる側 右往左往の意味がよく分からんが、自分が考えて手を動かす量が減るということかな? >>151
どのような意味で言っているのかよく分かりません。
もう少し詳しく説明していただけないでしょうか。 遅いと言われようと、フィボナッチ数列をzipWithで1行で書ける言語というところに魅力を感じている
(そんなに何度もフィボナッチ数列を書く機会があるわけではないが表現力の一例として) パスカルの三角形を出したいんだけど、
++使ってるのが気に食わないのだがうまく消せなかった
import Data.List (unfoldr)
pastri :: [[Int]]
pastri = unfoldr (\l -> Just (l, body l)) [1]
where
body xs = 1 : zipWith (+) xs (tail xs) ++ [1]
main = mapM_ print $ take 15 pastri 型に関数型のデータを持たせることはできますか?
GHC.TypeLitsで自然数型のデータをもたせることは出来ましたがどうやら関数型は無いようです
ニュアンスとしては以下のような事をやりたいです
newtypeでaを定義し直しMonoidのインスタンスにすれば同じ処理は出来ますが
冗長性を省いてシンプルに記述したいです
newtype Hoge (f :: a->a->a) (a :: *) = Hoge a deriving Show
instance (Num a) => Monoid (Hoge f a) where
mempty = Hoge 0
(Hoge x) `mappend` (Hoge y) = Hoge (f x y) data Hoge a = Hoge (a -> a -> a) a
これだとHoge f 0とHoge g 0の型は同じになってしまう
引数fをgに変えると戻り値の型が変わるような関数Hogeは動的言語なら作れるかも >>156
長さが異なるリスト同士の zipWith で、短い方の末尾をデフォルト値で補って長さを揃える、
そんな関数 zipWith' を作ってはどうでしょうか。
zipWith' :: (a -> a -> a) -> a -> [a] -> [a] -> [a]
zipWith' _ _ [] [] = []
zipWith' f d [] (y:ys) = f d y : zipWith' f d [] ys
zipWith' f d (x:xs) [] = f x d : zipWith' f d xs []
zipWith' f d (x:xs) (y:ys) = f x y : zipWith' f d xs ys
これを使えば、例えば [1, 3, 3, 1] から [1, 4, 6, 4, 1] は次のようにして作れます。
let xs = [1, 3, 3, 1]
zipWith' (+) 0 xs (0 : xs)
この関数は一方だけでも無限リストだと止まらないので注意が必要ですが、
ときどき役に立つので私は自分のツールボックスに入れています。 パスカルの三角形はロゼッタコードにあるのが限界でしょ
Pascal's triangle - Rosetta Code
https://rosettacode.org/wiki/Pascal%27s_triangle#Haskell >>156
以前にこんなのを書いたことがある
pascal :: (Integral a) => [[a]]
pascal = map (1:) $ (:) (repeat 0) $ zipWith (zipWith (+)) pascal $ map tail pascal
-- pascal =>
[
[1,0,0,..],
[1,1,0,0,..],
[1,2,1,0,0,..],
[1,3,3,1,0,0,..],
..
]
2重リストなんで見た目複雑だけど発想としては
fib = 0:1: zipWith (+) fib (tail fib)
とほぼ同じ ++をネタにする作者の気持ちをスルーしてパスカルの三角形を熱く語る
理系の鑑 pascal = map (takeWhile (/= 0)) $ iterate (\xs -> 1 : zipWith (+) xs (tail xs)) (1 : repeat 0)
http://melpon.org/wandbox/permlink/HLKtAXzGodOF3ZGP ところで・・・
コメントを読まなくても、どのように計算しているのかがぱっと見て分かる、
それが関数型が持つ高い宣言性の良いところ。
また、そのようにプログラムしても、もともとGHCが持つ優秀な最適化能力や、
プログラムの見た目を壊すことなく最適化を促すことができる仕組みのおかげで、
結果的にかなり効率の良い処理がなされる実行ファイルが出力される。
(実用的なアプリケーションで十分に耐えられる)
にも関わらず、そのメリットをあえて潰すようなプログラムをする人が稀にいるが、
純粋関数型のHaskellを使っておきながら、他に優先すべき事項があるのだろうか。
まぁ、縛りパズルをして遊んでいるのなら分かるが。 今ここで言う必要のないものを必要と思い込むことも縛りのパターンの一つ どうしても難解になりがちはワンライナーやコードゴルフで遊ぶのは人の自由だと思うけど遊び以外で使うのはたしかにどうかと思う ポイントフリー教も1変数のパイプみたいなやつならまだ分かるのだが
(中間変数が無くなるから効率が上がるという話もある、
そのくらいGHCが最適化してくれてもよさそうなのに)
2変数以上になると完全に暗号めいてて困る xss = (1 : repeat 0) : [ zipWith (+) (0 : xs) xs | xs <- xss ]
pascal = [ takeWhile (/=0) xs | xs <- xss ]
これは2変数というか2重ループ
それと再帰のために自分自身に名前をつけた時点でポイントフリーは諦めている筈 ポイントフリーって何?こういうこと?
pascal = map (takeWhile (/= 0)) $ iterate ((1 :) . map sum . transpose . take 2 . tails) (1 : repeat 0)
http://melpon.org/wandbox/permlink/bYSi5tfNVy5zfzPg 変数名かんがえたくないときポイフリできたらしちゃうことある ArrowLoopがどういうインターフェイスなのかいまいちよく分からないけど
その定義でどう動くかはfによるとしか・・・ 結局ハードウェアの動きとあまりに乖離しすぎてるってのが
普及しない理由じゃないかと。 量子コンピュータが普及する時は言語どうなるんかな
CPUに合わせた新しい言語になるのか、今の言語をベースにコンパイラに任せるのか
原理とか全く知らなくて言ってるけど メモリとCPUが分離しすぎているおかげでメモリ上のデータ構造に変化がない
OOPははそこを変えようとしたのか
分離するのやめれば破壊的イノベーションが起きるのではと ContrainedなFunctorを実装していて直面した問題です
問題の本質を以下の単純化したコードで例示します
最後2つのインスタンス宣言の間で"Duplicate instance declarations" エラーが発生してしまいます
これは型aがOldAとUsefulFoo両方のクラスのインスタンスである場合どちらのnewHogeを実行すればいいのか区別がつかないからですが
実用上このケースは無意味で意図してコードを書かなければ起こり得ません
OldAとUsefulFooの両方のインスタンスになるような型が存在しないことをghcに伝えられればエラーにしなくても良いと思うのですがそのようなテクニックや言語拡張はあるのでしょうか
{-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
class OldA a where
hoge :: a -> a
class NewA a where
newHoge :: a -> a
class UsefulFoo a where
us :: a -> a
ef :: a -> a
ul :: a -> a
instance OldA a => NewA a where
newHoge = hoge
instance UsefulFoo a => NewA a where
newHoge = us . ef . ul >>179
OldAとUsefulFooとNewAの設計方針が間違っていたのでは? 最新のGHCは簡単な余再帰が末尾再帰に変換されて最適化かかるの? fib_mem :: Int -> Integer
fib_mem = (map fib [0..] !!)
where
fib 0 = 1
fib 1 = 1
fib n = fib_mem (n-2) + fib_mem (n-1)
https://www.packtpub.com/mapt/book/Application%20Development/9781786464217/1/ch01lvl1sec09/Memoization+and+CAFs
フィボナッチは前スレのこれが美しすぎた。
これを見た後では
zipWithのフィボナッチとか完全に霞んで見える。 数式に近いから美しいって言ってるのかもしれないけど
それは
fib_mem :: Int -> Integer
fib_mem x = _fibs !! x
_fibs = map _fib [0..]
_fib 0 = 1
_fib 1 = 1
_fib n = fib_mem (n-2) + fib_mem (n-1)
みたいに一時データがユニークになるって話だから
メモ化されるって言ってもO(n^2)だけどな こんな所で感動しちゃってどうするの
そういうのは万策尽きて神頼みするような時だけいい
数学に感情は不要 初歩的なメモ化で感動できた頃の心の輝きは大切にしていきたい メモ化してトップダウンするより足していってボトムアップの要領の良さが勝つ回 stack new して作ったプロジェクトでライブラリを作りました。
(cabal ファイルに executable の代わりに library の項目を書いた)
stack build して正しくビルドされたことを確認してから stack install しました。
この後、別の stack new したプロジェクトで、先程 stack install したライブラリを使用するには、
どうすればよいのでしょうか。 >>192
出来ました。
ありがとうございました。 前書きだけ立ち読みしたけど
あれ関数プログラミング入門を書き直したものなんだな Bird氏の本の第三版か。
あの人、Functional Programmingの大御所なんだね。
すごいHやGraham氏、その他日本人著者の書いたのをいろいろ読んだけど、
コアな部分を理解するならBird氏の本だと思った。
翻訳第二版のファンシーな表紙をやめて、
原著の表紙の虎を持ってきたのは何かあったのだろうか?ww と思ったらそもそも関数プログラミング入門買ってなかったのでこれを機会に買おう >202
最初から正格、非正格を念頭に置いた上で議論が進んでいく。その時点で既に毛色が違う。
豆知識として、リスト内包表記とdo構文の<-の関係も載ってた。
証明問題が多く、数学がわかんないときつい感じ。 >>205
あぁなるほど、そう言うのを一般に「コア」って言うのか
ありがと 今更すぎる
和訳で知ったのに原文貼って物知り顔するな Haskellにも依存型があと数年以内に組み込まれるらしいですが、使用目的は専ら型安全性を得るためなのでしょうか? これ普通にショックだね。。
本当なの??
https://goo.gl/RB0asw 最新のGHCだと余再帰が可能な限り自動で末尾再帰に変換されて最適化がかかるって聞いたんですけど本当すか? 使う型がInt32なら32を、Int64なら64をコンパイル時に決定してソースコードに埋め込むメタプログラミングな関数を書くにはどうしますか? Int に 対する read が遅くて困っています。
80万個のInt型をreadするのに、10^9付近の整数ばかりの場合と、1とか10とか小さな整数ばかりの場合とで 2 倍も処理時間が違ってきます。(2秒が4秒です!)
もっと速く読み込む方法はありませんか?
(但し標準入力からとします) readIntegerだった
うろ覚えだったすまん >>221
ありがとうございます。10倍速く動くようになりました ひょっとして、foldl か foldl' かよりも、そこに渡す二項関数の方を正格にするか遅延のまま
かが速度に関わっているのでしょうか?
※二項関数は(+)やmaxのように単純であるとする ん、何言ってんだ。二項関数の問題じゃなくて二項関数に渡す『二つの引数が今すぐどちらも値まで評価されるかどうか』が問題なのか。
される場合、foldl'の方がサンクなしの省メモリ(定数空間?)で処理が進むのか。
foldl'で正格に評価するといってもWHNFで止まるんですもんね
サンクが要らないからその部分(サンクの作成と破棄)のオーバーヘッドがなくなってちょっとだけ速くなるのか。でもあくまで foldl' の利点は省メモリの方か 速度の比較をしたいならまずプロファイルを取りなさい V8エンジンで無茶苦茶速くなったことだし、もうTypeScriptでいいやと思うようになった。 教えてください
何らかの型の巨大データがメモリ内にあったとして、データが用済みになった時に手動で解放する方法がHaskellにありますか?
そもそもそういう発想が間違いかも? mark&sweepいらないなと思った時に参照カウントに変更する方法
言語を変えなくてもコンパイラを変えるだけでできそう(できたとは言ってない) >>231
用済みになった時に手動で解放というのが、
1) たとえどこかから参照されていようが強制的に解放する
2) 参照がなく解放できる時にスケジューリングを待たずにGCを強制する
どちらの意味なのか分からん。
前者のつもりなら、たしか方法はなかったような気がする。
この発想は間違っていると思う。
自分が仕込んだメモリリークの問題を隠しているだけ。
後者なら、base パッケージの Systwm.Mem モジュールを調べてみて。
これなら分かる。
例えばゲームで、できるだけステージ途中で時間かかかるGCが起動しないように、
ステージ開始直前に強制的にGCさせたい、とか。 >>233
ありがとう。質問してよかった。
こちらのイメージ的にはCで言うところのfreeで1)が近いと思うが、GCを強制する
発想がそもそもなかったです
断続的にでかいデータを扱うので、次のロードまでにメモリを解放しておく必要
がありまして。
Systwm.Memを調べてみます。 演算子の部分適用の書き方で
演算子との間にスペースを書かないのはHaskellの作法?
(+ 3) (3 +) じゃなく (+3) (3+) って書くじゃんみんな みんなそうしてるから真似してそうしてるだけだろ。
わからないことは調べるのはめんどくさいから真似しておこうとか思ってそう。 >>235
普通に2項演算子として用いている場合は項と演算子とが独立してる感があるが、
部分適用した場合は「3を加える関数」という一塊の概念というイメージが強い
なんとなくだけどそんな使い分けではないかと思ってる GUIには等幅ではないフォントがあるから
1ピクセル単位でスペースを描く作法とかありそう 逆にHaskellでだけスペース挟んだりしたくないだろ 人間は文章を読むのに時間がかかる筈なので、質問と同時にGCを強制発動して、ユーザが質問を理解し返答を入力するまでの間にGCを終えたい 「関数プログラミングの思考法」で勉強してるんですが
「たのしく学ぼう!」は楽しく理解できる内容で
こちらは余計な表現は省いている硬派な文体ですね。
そのため反ってサクサク理解していけるのですが
皆さんどうでしょうか。 >>242
分かる。ノイズが多い本は理解を妨げる面があるよな。 軽妙な喩えならいいんだがセンスない人がやると惨憺コース H本に影響を受けて書かれたE本はセンスないし痛々しいしで読むのが辛かった
変な色気出して慣れないことをしないでくれ >>244
Land of Lisp は何故か許せる ノイズじゃなくて冗長性だろ。
冗長性が多いほど失った記憶を復元しやすいから覚えやすいんだぞ。
そんなことも知らないのか馬鹿だなぁ。 ラノベじゃないんだ。インクと紙の無駄遣いは止してくれ ラノベで気軽にHaskellを覚えられたらいいんだけどな むしろHaskelでラノベ全文を書いたらいいんだけどな >>251
「Haskellを覚える」の意味が分からん
Haskellの何が覚えられないんだ?
文法一覧表とか入門書をいちいち見ないとコーディングできないとか?
それなら、たとえラノベに分かり易く書かれていようと、読むだけじゃ憶えられんぞ Haskellをというか、ライブラリの便利な使い方を覚えるってことかな
ライブラリの型シグネチャとチョロチョロっとした英語の説明読んで、想像力働かせて『これは今までの処理がこうこう、こういう書き方でできるようになって便利ですね』と理解するのが難しい
<* や *> のパーサーでの使い方(認識だけして捨てる)を知った時はアハ体験だった
こういうのをドキュメント読んだだけで気付くということができない 基礎ライブラリは抽象的なので、そこから応用的具象化を想像する能力が足りない
初めてApplicativeのドキュメントを読んでその有用性に気付く奴はIQ高過ぎだろ
頭がpureだった俺は戦意喪失したものだよ 誰かHaskellで萌える関数型プログラミング入門書いてくれ。 >>257
本当に買ってくれるのか?
買ってくれるならKindleで出すかな >>255
ライブラリドキュメントを眺めていて、どんな使い方ができるんだろと想像するのは、そりゃ難しいよ。
それはドキュメントの使い方を間違っていると思う。
俺はアプリケーションを作っている時、
1. こういう引数からこういう結果になる関数が欲しい
2. 1の計算を分解すると A、B、C という計算の組み合わせになりそうだ
3. A、B、C を計算する関数をすでに誰か作っていないだろうか?
という順に考えて、A、B、C をドキュメントから探す、という使い方をしてる。
*> の例なら、誰かがパーサーで認識だけして捨てるのに使っているのを見てアハ体験をするのではない。
そうじゃなくて、初めにパーサーを作っていて認識だけして捨てたいという欲求が湧いてきて、
じゃあどうするかと考えた時に、まず「認識だけして捨てる」とはどういう計算なのかを分析する。
そうして事の本質を捉えてからドキュメントから求めるものを探す。
その時、たまたま既にパーサーの構造を Applicative で表現していれば、
ドキュメントの Control.Applicative モジュールの項を真っ先に探して *> を見つけるだろうし、
別の方法で実装していれば、実現する関数はライブラリには無さそうだなと諦めて自作するかも知れない。
何れにしてもアハ体験の出番はない。
言っておくが、アハ体験が悪いわけではないぞ。
他人の解説やソースコードを見て、そういう使い方もできるのかと学ぶ事は大事だ。
ただ、ドキュメントをそのように使うのは違うだろ、つまり(ライブラリ)ドキュメントは
解説書でも読み物でもないだろ、と言いたいんだ。 本来であれば入門編は有用性ではなく単相型の欠陥に気付かせるべきなんだよ
VectorInt型とかVectorChar型とか再発明を繰り返すループに気付け
その後でパラメータ多相編とアドホック多相編をやるべき 萌は興味を引かせる手段にはなれても、理解を深める手段にはなれんよ Kindleで、標準ライブラリの一つにつき一冊かけて特集した本を電子書籍で出して
抽象的な基礎ライブラリはその応用可能性をねっとりと絡み付くまでに例示して いいっすね読んでみたい
GitBookあたりで無料で HaskellはHOW TO本が少な過ぎる
写経するだけでサクッと実用アプリを作れるような本が欲しいよね
IOが七章や八章から登場する入門書とか
Haskellを普及させる気ねぇだろw >>266
他言語でもそんな本は無いんじゃないか?
「サクッと」と「実用」がどんなレベルか知らんけど。
一応 Beginning Haskell が Web 系で実用的で、
入門者がアプリケーションを作るまでを指導してくれるが、洋書だ。 Pythonなんかは
サンプルコードを書き書きしてるだけで
機械学習が出来ちゃう本なんかが出てるね Haskellでエロイベント満載の
エロゲーを作る入門書が欲しい エロゲー作るのに大事なのはエロ絵だけ、プログラミング言語なんて全く関係ない 圧縮した画像を取り出したりするのはC言語だと思う
他の言語を混ぜても、小規模ならC言語の占める割合が高い
だから他の言語はスケーラビリティがーと言って大規模化しようとする C言語開発はストレスで禿げるから嫌だ
居玉で横歩取りするような将棋は嫌だ >>270
モナディウスあるから作れないことはないけど、C/C++のが向いてる。
Haskellに限らずJavaやC#みたいなGC使ってるのはタイミングがシビアなゲームには向かない。
(やるとしても場面切り替えのタイミングまでGC止めたりと、工夫が必要)
シビアじゃないゲームならUnityの公式言語だったり、PS VitaのSDKもC#だし、ゲームプラットフォームの選択肢多いC#じゃね? とはいえ今時ゲームというばスマホだから
スマホ対応の難しい言語は論外だろうな ゲームとは言わんが、Haskellでスマフォアプリ作れたらなぁ。。。
Webアプリを作って、URLをスマフォの画面に置くのが関の山だろう。
Yesod本の和訳早よ。 同系統の言語のCleanはIDEに標準で付いてくるサンプルに
2D横スクロールアクションみたいなゲームとかTCPとかあるから
そっち使うとかは? Androidで動くHaskellの話はどうなったの? どの言語でも無理矢理Androidで動かす狂人はいるけど
実用性はというと・・・お察しください purescriptとりあえず入れてみたけど、コンパイラしかないのな arrayの要素数を型に含めることはできないの?
それがあれば、行列の積とかで便利だと思うんだけど
オレ頭が悪いんで言っている意味が分からないかな… JVMで動くHaskellことFregeは最近どうなっているのか >>282
要素数2 Bool -> Double
要素数3 Either Bool () -> Double
要素数4 (Bool, Bool) -> Double 仮想機械上にランタイムシステムを敷いて、さらにその上で動かすの?
……遅そう >>259
>事の本質を捉えてからドキュメントから求めるものを探す。
この能力を身につけられるHaskell本はありますか? >>288
それはHaskellプログラマに特有の能力じゃないし、
他言語のプログラマよりも特に優れている訳でもないから、
Haskell本に求めても無駄。
強いて挙げれば「珠玉のアルゴリズムデザイン」。
でも、もっと他の本を読んで実践した方がいい。
例えば「いかにして問題を解くか」シリーズ。 Haskellは数学だから基本は数学本に丸投げだよな
しかしλとか∀とか真面目に説明した数学本は見たことがない 数学の裏付けで支えられてる言語って安心感ある
誰しも学習に費やした時間を反故にしたくないのだ
つぶしが利く共通項目を辿って成長していきたい >>288
むしろそれはプログラマに必須の能力。
Haskellは普通の言語でそれが見えない人にも見える様にしてくれる。
(普通の言語ではプログラマになれなかった人でもプログラマになれるかも知れない言語)
本としてはHaskell本じゃ無いが、プログラミングinOcamlが良かった。
その後にプログラミングHaskell読むと良い。
どうしてもモナド理解したかったらすごいH本も読む。
CやJavaでマージソートのコード読んでも何やってるのか分からんかったが、Haskellだと初心者向けのアルゴリズム本で、マージソートとはこう言う動きをするソートって図解を読んで、自分で書けた。
今にして思えば、他の言語のアルゴリズム本はソートがリスト前提なのに配列でいきなり作るから分かりにくいって気付いたが。
リストで作って、遅いから配列にしたい。
どう書く?みたいな書き方なら他の言語でも分かりやすいのに。 >>292
残念ながら時間が無駄になる確率は0ではない
0が良いというのは数学とは関係ない人間の願望 >>293
C/Java のソートはインプレイスであることが優先されるからね キャッチコピーすごいw
Haskellの美しさを
知っている人は、
人生に絶望することはない。
Haskellで世界を変えたい。
http://www.shuwasystem.co.jp/products/7980img/4806/a.jpg Haskellを学ぶことによりC++の凄さを知りました ちょっとオカルトチックにするのやめて
またHaskell馬鹿にされるじゃん その本めくってみたけど基本的な言語機能を延々噛み砕いて説明してるだけのバカが崇めるためにあるような本だった
インテリアに最適 プログラミング言語を国家か何かのように考えてるやつはみんなオカルト
それをやめさせることができたらノーベル平和賞を取れる Haskellは単なる科学であり魔術でも宗教でもない。余計な飾りは要らない。ただただ成果を出せばよい
というわけでHaskellの成果を挙げて >>302
> Haskellは単なる科学であり魔術でも宗教でもない。余計な飾りは要らない。ただただ成果を出せばよい
正確に言えば「Haskellは単なる技術であり」だな
科学の主たる目的は真理の探究、社会に価値を生み出す(または価値を増加させたり価値の増加を容易にする)のは技術
個々のプログラミング言語、特に実用を目指している言語、は
言語に関する様々な理論(構文の理論や意味論などで、これらは自然科学ではないが数学という科学…形式哲学とでも呼ぶべきもの…の一分野の成果)の
適用としてより「容易にプログラムを書ける」とか「よりバグの発生する可能性を減らす」といった現世的な御利益つまり価値の増大や創造を求めたものだから
> というわけでHaskellの成果を挙げて
うん、技術的成果としてのプログラミング言語に対して、この要請は実に適切だね あのスレの次スレが立ってないからってこっちくるのはヤメレ 成果出まくりのC/C++はどちらかというと嫌われ者なので
C/C++の成果をどうやって否定しようかと知恵を絞っているのが現実
成果主義は机上の空論 HaskellはC++に挑む気はなさそう(代わりにRustが挑んでそう)
Haskellの相手は頑張ってJavaでしょ
Javaクラスのパフォーマンスを少ない労力でパパッと実現みたいな
一応ネイティブで動くみたいだがランタイムシステムの監督の元だし、このランタイムシステムの効率ってのが怪しい
ガベコレ技術なんかJavaのそれに何周も遅れとってそうだし
参照透明だと最適化かけ易いって? 最適化の研究進んでるの? >>306
確かにGHCはあまり性能を追求しないね。
Haskell、OCaml、RacketでGCのレイテンシを測る
http://postd.cc/measuring-gc-latencies-in-haskell-ocaml-racket/
>Haskell:ワーストケースの停止時間は51ミリ秒
>OCaml:多くの停止時間は220マイクロ秒から1ミリ秒の間で、最長は2.7ミリ秒 >>307
OCamlは性能★だけ★が売りだから速くて当然
元祖MLの醜い構文を正しモジュールに関連する諸機能を追加したのがStandard MLで
元祖MLを生み出したRobin Milner自身もStandard MLに入れ込んでいた
(Standard MLのformal semanticsの定義書とかまでMIT Pressから出版したしね)
ところがフランスINRIAの連中がMilnerやPaulsonらイギリスのStandard MLグループに対抗して
昔のMLの醜い構文のまま言語をオブジェクト指向へと拡張して作ったのがOCaml
でっ、実行性能の差で生き残ったのはOCaml
お蔭でMLはグチャグチャでグロテスクな構文のほうが生き残ってしまいましたとさ
だからOCamlは実行性能だけは良くて当然なんだよ、だってそれだけでML界の競争を生き残って来たんだから 『教養としての関数型プログラミングHaskell』とかいう分厚い本どうなの 読んでないが筆者の名前はhackageでよく目にする
謎のオレオレライブラリを作るのが好きな人という印象だ
https://hackage.haskell.org/user/YoshikuniJujo いや純粋に黒くて大きくて書店で異様な存在感を放ってたので気になったんだけどウンコだったのか >>313
Amazonレビューにキツめのがついてたわ 秀○システムは毛の壁本出してしまうという暴挙以来どうもイメージが悪くてな…… タイトルからは計算論やらラムダ計算関係の知識を教えてくれそうな内容に見えるけど、
レビューや内容紹介を見ると「Haskell学習」とかなら良かったんじゃないかな?
と内容も見もせずに思いましたマル 初心者向けにStackの使いこなし、チュートリアルとか書いた方が喜ばれたね。 失望しました。代わりに Chris Okasaki 先生の純粋関数型データ構造買います >>321
純粋関数型データ構造
https://www.amazon.co.jp/dp/4048930567
"Purely Functional Data Structures" の邦訳『純粋関数型データ構造』が発売されます
http://d.hatena.ne.jp/ku-ma-me/20170316/p1
関数型言語での最適を考える:純粋関数型データ構造、Chris Okasaki
http://www.injpok.tokyo/4048930567-functional-data-structure
Edison
http://rwd.rdockins.name/edison/home/
>Edison is a library of purely function data structures
>for Haskell originally written by Chris Okasaki. 関数型言語って pure が付くととたんにマニアックになるんだよなー あ、ホントだ
でも純粋関数型言語って 1とか2とかの数値や、
true/falseのbool値すら関数(ラムダ式)として表現するやつとかあるよね
マニアックが極まってるというか それは関数型言語なら純粋じゃ無くてもそうだが。。。 ごめん
15年以上前のうろ覚えのラムダ計算の知識しかないんだけど、
1 とかの基本型をチャーチ数のようなラムダ式で表す体系は
型なしラムダ計算でしかなりたたなくて、
型付きのラムダ計算は自然数などの基本型はラムダ式では表せないんじゃなかったっけ? うーむ。。。
まず左結合のチャーチ数をどうやって右結合のラムダ式で表現するんだろう?とか、色々イメージが掴めん。。。
確かに整数型は整数としか計算出来ないけど、型変数とかだったらズルイかもだけど行けそう。
私もそんな話は昔読んだ気がするんだが。。。
詳しい人を待ちますかね。
チャーチ数そのものは代数的型で簡単に実現出来るけど、そう言うのじゃないんだよね? 適切な抽象化があれば値がどうやって表されるかなんてどうでもいいよ 関数言語得意なお前らlazy Kとかunlambdaとか得意そう 正直言ってこういうのサッパリ分からん
ラムダ計算で代数的データ型を表現する方法 - @syamino はてなダイアリー
http://d.hatena.ne.jp/syamino/20120524/p1 もはやHaskell関係ないって言いたいところだけど
そう言えばチャーチエンコーディングってfoldr/buildそのものだな Jpegの何バイトめから何バイトがどんな情報とかの仕様教えてくれたら頑張ってみるよ。
テキストなら割と扱えるんだけど、バイナリはデータ構造知らんと何とも。。。
こう言うところでプログラマーになれんかった。 圧縮なんてしない方がアプリを早く作れるよ
GUIも使わない方が早く作れる
それで素早く作ったアプリは原始的なので人に見せない
科学が発達すればするほど最先端に追いつくまでの時間は長くなる GUI使わないプログラム普段おまえら使うのか
いったい何をやっているんだ
科学計算は日常系でないからなしな プログラムの世界でGUI依存なんて基本的に羞恥なんだが素人かな おいらはプログラマーの道をすっぱり諦めたから、当時一番気に入ったHaskellの残留思念だけで書きこんでる。
写真がプログラミング以上に楽しいから、Jpeg弄れるライブラリあったら触ってもいいかな。
HaskellでGUIと言えば、MSがHaskell+WXでGUIのサンプルをpdf(英語)で公開してから、海外のHaskellerは軒並みWX使ってるっぽい。
おいらの時はRWHにgtk2hsが載ってたからそれにしたけど、MSのpdf読む限りWXのがコード短い。。。
RWH恨むぞ。。。 アーキテクチャの話も一切出てこない
俺達は汎用プログラミング言語でいったい何をしているのか デザパタみたいなの?
パターンって程実践で使われてないだろ。
んー。。。
使ってた感触だと、割と行き当たりばったりからの仕様変更でも何とかなるのが関数型言語の強み?と思わなくも無い。
ちょっとの変更にも関数経由するから、自然と既存の関数使い回せないか考えるし、関数型言語もそう言う風に進化して行ってるように感じる。
某スレで話題になったキャットドアクラスも、変な縛りがなければ究極的には機能の組み合わせでドアが開くかどうかの問題なのだから、タプルにBoolを並べれば良い。
ただ、同じBool値ばかりだと違う機能を付いてる(付いてない)と表現しやすいので、適当な型を作ってコンパイラが順番間違えたらエラー出すようにする。
cd = (False,型Aの値)
値が欲しかったら
getA t = snd t
または引数の時点で直接欲しい値にアクセス。
getA (_,x) = x
仕様の拡張に関してはタプルを入れ子にする事とする。
継承というよりは委譲に近い。
理屈では(以前の機能,拡張機能)の形でいくらでも入れ子に出来る。
cdEx = (cd,型Cの値,型Dの値)
cdFX = (cdEx,型Eの値)
基本機能だけなら基本のタプル取り出して使う。
getA $ fst cdEx
拡張機能だけまたは、拡張機能と基本機能の組み合わせは引数の時点で(以下略)
getC (_,x,_) = x
getAD ((_,x),_,y) = x + y
ただ、関数型言語は元々多くの状態を管理するのに向かない。
例の通り、構造が複雑になると扱い難い。
HTMLなりXMLなりXAMLなりに状態管理は任せた方がいい。
んじゃ、おいら夜勤明けなんで寝るわ。
お休みzzz... しかし多くの状態を楽に管理できなきゃ、
ゲームも商支援系ソフトもクリエイター系ソフトも何もまともに作れん
作れたとしても、後のメンテが辛くなるコードが出来上がる
向いているのは自身で状態を維持変化しなくてもいいような、
フィルターとしてモデリングできるものしかなくなる
たとえば linux の簡単なコマンドや web アプリ、FX自動取引システムくらいか
処理速度の問題は実用的にはほとんど気にならないレベルだと思うし、
メモリリークの問題はそれがHaskellだから諦めて、せいぜい気をつけろと言える
が、状態管理のしにくさは、これが解決すれば
爆発的にユーザーが増えそうなだけに、何か発明がほしいな 抽象的な状態遷移はできるでしょ
ただ具体的な現実の状態を忠実に再現しろと言われるとよくわからない
忠実さを競う意味がわからない おはー。
そこよな。
IORefとかで状態管理出来るけど、それだとデフォルト引数とかある普通の言語の方が楽。
どっちかと言えばWebプログラミングみたいにHTMLやDBに状態持ってもらって、ここの項目をこう加工したいって時だけHaskell的なのが良いと思う。
奇しくもMVCとかMVVMのモデル。
キャットドア問題みたいなのは問題自体の使いどころが判らん。
おいらは問題を解決したいのであってクラスを作りたいんじゃ無い。
オブジェクト指向でなぜ作るのかって本のジャンケンを一対一から多人数に拡張みたいなのが問題として本質を突いてると思う。
本当の仕様変更って、一旦根本から考え直さないといけない事があって、解決したいのはそこだからね。
オブジェクト指向だと、結局一旦全部壊してクラスで表現して解決。
関数型言語だと一旦バラしてリストとか加えて使い回せるのは使い回す。 関数型を選択することで、あるレベル以上の密結合を完全に禁止できる?? >>346
禁止と言うのが、言語仕様としてコンパイラに弾かれるという意味なら、禁止にはできない。
そもそも、結合度と関数型とは何も関係ない。 そんな大規模なの作った事ないけど、少なくともクラスみたいにデータと手続きが密接に関係してるものよりは使い回しが効くよ。
ただ、それは関数型言語だからって訳じゃないと思う。
Cがグローバル変数の問題解決して、ジェネリック(テンプレート)導入すればそれで済む。
Goが一番それに近いのかな?(でもジェネリック無いんだよな。。。)
関数型言語はグローバル変数が読み込み専用で、問題になり難いから解決し易かっただけ。
私は文法の美しさでHaskellに惚れてるだけで、Haskellが絶対の解では無いと思ってる。
手続き型にはデフォルト引数とか、メッセージ引数と言う、引数の数や順番を減らしたり入れ替えても問題無い仕組みがある。
それぞれのメリット/デメリットをうまく組み合わせれば良い。 正の整数が1万個格納されたリストAの中に偶数が2個以上あるか調べたいです
手続き型だとcount=0みたいな変数を用意してループを回してcountが2になったらループを打ち切るという形になると思うのですが、
haskellだとどう書けばいいでしょうか?
filterしてから数を数えることも考えたのですがそれだと2つ見つかってからも処理が続くので少し非効率的な気がしてます
初歩的な質問で申し訳ありませんがご教授いただければ幸いです >>349
haskellは遅延評価だからtakeとfilterで無駄なループしない
length . take 2 $ filter even [1..] その手続き型でのカウンタ変数を蓄積引数にするだけ
solve = solve' 0
where
solve' 2 _ = True
solve' _ [] = False
solve' n (x:xs) = solve' (if even x then (n+1) else n) xs
main = print $ solve [1,3..1000001] >>350
>>351
なるほど…ありがとうございます
どうしても手続き型の考え方に引っ張られてしまってダメですね
精進します 遅延評価が必ずループを打ち切る保証はない
length (repeat ()) >= length [] --> ⊥
longer (repeat ()) [] --> True
longer [] _ = False
longer (_:a) (_:b) = longer a b
longer _ _ = True 入力が無限でその中にevenがなけりゃtakeでも止まんないっしょ でも人間にとって無意味な手をコツコツ打って勝つ戦略って最近の人工知能がやりそうだ >>355
そんな例だと遅延評価関係なく解決不可能だろう >>355
ちゃんと1万個って言ってるのに、どうして自分の都合の良いように前提条件変えちゃうの?
人の話聞こうよ! ゾイゾイ言ってないでさあ! 型でガッチガチに固めてコンパイルエラーで危険なコード通すの阻止してくる関数型言語の姿勢ってフールプルーフ? ハスケルの発音はどこにイントネーションを置けばいいですか? YouTubeをhaskellで検索かけりゃいくらでも聞けるだろ haskellでキーボードから入力した値をそのまま出力する場合、必ず
n <- getLine
putStrLn n
のように一旦変数に束縛する必要がありますか?
一行では書けないのでしょうか main = getLine >>= putStrLn ちなみに
main = do
____n <- getLine
____puStrLn n
と
main = getLine >>= \n -> putStrLn n
と
main = getLine >>= putStrLn
は、等価。
do形式はモナド形式を手続き型っぽく見せる糖衣構文に過ぎない。
最後のはモナド形式とカリー化を利用した部分的用で見た目の変数を無くしただけ。
モナド形式だとプログラム全体が一つの式だと言うのが良く分かる。 ___n は誤解を招く
_korehaTsukaimasen getLine >>= putStrLn じゃなくて interact はダメなん? >>378
interactは変数に束縛してごにょごにょする処理を隠蔽してるだけだから
「必ず一旦変数に束縛する必要がありますか?」の答えとしては若干嘘かも 束縛ってコード(人間の視認性)レベルの話で、コンパイラが吐くバイナリではキャンセルされてるんじゃないの?
バインドで(ポイントフリーみたいに)やったのと変わらないようになってんじゃないの Haskell 教養としての関数型プログラミング 単行本 ? 2017/4/15
重城良国 (著)
https://www.amazon.co.jp/dp/4798048062/
824ページって超大作だな
Haskell本の決定版か? Haskellによる関数プログラミングの思考法 単行本 ? 2017/2/28
Richard Bird (著), 山下伸夫 (翻訳)
https://www.amazon.co.jp/dp/4048930532/
こっちはどうなのだろう?
感想求む >>383
>>201
数独ができるようになるけど、ワイはすごい本の方が好きや getLineでコンソールから手動入力する時、バックスペースとかで修正出来ないのってhaskeline使う以外に何か方法無いのかな? Comonadでオブジェクト指向を実現できるって聞いたけどほんと? スレ違いかもしれませんが、2つのリストに一致する項目だけ抜き出したリストを作るみたいな問題があったとき、
集合論だと集合Aと集合Bの積集合A∩Bを求めるような解き方をすると思うのですが、Haskellのようにラムダ計算が
基になっている関数型言語だとそもそもの考え方や物の見方が違ったりするのでしょうか?
Haskellを学び始めたはいいんですが、結局他言語のパラダイムを無理やりHaskellに適用させているだけのような気がして不安です >>391
質問に答えるだけの知識を持ち合わせていないので一応コードだけ
intersect :: Eq a => [a] -> [a] -> [a]
intersect xs = filter (`elem` xs)
リスト内包表現でも書けるけど関数型っぽいのはこういう書き方なのかも >>391
チューリング完全という意味で、他言語とHaskellは等価というのが数学的な見方だな
もし言語が複数存在する原因を知りたいなら、数学的な見方はほとんど役に立たないな >>392
>>393
ありがとうございます
チューリング完全でさえあればそれ以上は計算モデルより言語仕様に合わせた方が良さそうですね
いろいろ試してみて、一番スマートに書けるように精進します
今のところHaskellが一番面白いです >>392
ちなみに、mapやfilterとリスト内包表記は内部的にはここが違うとか、パフォーマンスが
違うとか、あるいはこういうときはこっちの方がいいとかはあるのでしょうか? リスト内包表記はconcatMapを使うからネストできる
[f x y | x <- xs, y <- ys, p x y]
== concatMap (\x -> concatMap (\y -> if p x y then [f x y] else []) ys) xs
パフォーマンスは実際にghcがどういうコードを吐くかだけど
そのままconcatMapでもmapやfilterと同じような最適化が行われるし
必要なければリストの結合も行われない リスト内包のほうがパフォーマンスでるらしいけどHaskellのパフォーマンスチューンングは難しいから当分気にしないほうがいい
待ってる間に線形型で楽々チューニングできるようになるかもしれないし >>396
>>397
ありがとうございます
ネストの有無などで自分なりに考えながら使ってみます 内包表記と再帰を組み合わせることも可能。
夢が広がりング。 Web系でもいいのですが、フリーウェア(できればオープンソース)のアプリケーションで、
Haskellで作られたものって何かありますか?
Haskellプログラマだけでなく、一般の人も使っているもので。
もしくは、みなさんならHaskellでどんなアプリケーションを作ってみたいですか? あとはShellCheckだな。bash初心者はとにかくこれ使えって話題のシェルスクリプト更正ツールだ。 オーケーグーグル
Haskellで日本語文字列(Shift-JISやEUC-JP)のファイルを正しく処理する方法 みんな夢がないね。
ぼくなんてHaskellプログラム一つでお城のような家が建てれたよ。 >>400です。
ありがとうございます。
Haskellで作られたアプリケーションの方は2、3個紹介されるかなと思ってましたので、
まぁ予想通りです。
ですが、作りたいアプリケーションのレスが1日経っても皆無なのは驚きました。
(>>403 がいまいち分からない。これは私へのレスですか?)
私は年賀状の宛名をデザインするWebアプリを作りたいと思い、
「Beginning Haskell」を読んでWebアプリの勉強中です。
皆さん、作りたいものは何もないんですか?
ゲームとかオーサリング系とか、マストドンをhackするツール(crackではなく)とか... GitHubとかでHaskellで検索かけりゃ何か出てくるんじゃねーの? 論理に基づく人工知能を作るならHaskellがぴったりじゃないかと思うんだけど、プログラミングの技能も論理学の知識もないから作れない
細々と勉強はしてるけど 達人プログラマーになりたい欲求はあるけど何かを作りたいっていう欲求は薄いわ やはりゲームだな。あとはGUIアプリ。なにかのエディタのようなものがいいな。
Haskellで複雑な状態を扱うのは困難、と言ってる人らに反論したい。
実際のところはどうなのか想像する前に、まずはそういう状況に直面する必要がある。 EmacsのプラグインもHaskellで書きたい。正格データと遅延データを色分けして表示できたら嬉しそうだ。
GHC API を使えばできるかもしれない。
なんにしてもHaskellでやりたい。俺はもうLispは嫌だ… >>409
どういうことですか?
私が知っている達人プログラマ、要するにハッカーですが、
彼らはみな何かを作ってました(ます)。
なので、作ることに関心が無い達人プログラマというのが想像しにくいのですが。
あ、競技プログラミングのトッププレーヤーとかですか? >>411
Haskellでエディタ書いてくれ
common lispで書いたエディタもあることだし 作る以外に改造とかに気合入れる人とかもいるんじゃね? >>413
今は外部言語でかけるしくみがあるから、エディタそのものを置き換えなくてもいいんだ。
それが現実的だと思う。Emacsのような巨大なものは厳しい。見上げるだけで首が疲れるよ。先人は偉大だね。 >>400
写真が趣味だから、Jpegのカラー画像をモノクロやセピアに変換するツール作りたくてHackage漁ったら使い易そうなのがCライブラリ使ってるんで、そう言うの入れやすいLinux導入。
暇があったらチマチマ作りたいけど、暇がない。。。 itchynyタソがcamを作った時、一部の画像ファイルが(ライブラリのせいで)読めないのに腹を立てて
だったらhaskellで書いてやると一念発起したのがcamh。いまでも活躍してます。
lesspipeに組み込むとか。ちなこれはimlib2を使ってるので大抵の画像は読める。 haskellを業務でつかうような仕事に転職すればOK 仕事では使わんが、概念というかエッセンスはめっちゃ役に立ってるな
興味本位で触っといて良かったとマジ思う >>419
その手の話ここで時々聞くけど、Haskellの何が何にどう役だったのか、
具体的な話を聞いたことが一度もない。
$$$な状況でHaskell未経験のヤツは***だったけど、経験者の俺は###できた、とか。
そういう事を具体的に語ったブログとか無いんかな?
英語でも構わないんだけど。 比較するなら同一のものに対して、Haskell でのアプローチと
その他のアプローチをする必要があるので、
そんな贅沢な時間の使い方するやつはユーザ数が多くないと現れないんじゃないかな? tanakhにhaskellやっててよかった話を要求するか C++やC99以降みたいな「どこでも変数宣言」を嫌うようになった
宣言した位置と使う位置が離れるのは書き方が悪いからだ、というかなんか 高階関数を多用する様になったとか、関数の純粋さを気にして関数分割する様になったとか
設計やコードが以前より分かりやすくなってテストもしやすくなったと思う
カリー化や部分適用がもっと簡単に出来たらってモヤモヤする事も多いけど 別に関数型プログラミングって今まで出来なかったことが出来るようになる手法じゃないしな
コードを直感的に書けるようにすることでプログラムの全体的な質を高める手助けをしてくれるような感じ
メリットを語れと言われたら一晩中でも絡めちゃ語れる 関数型とは月極、定礎に匹敵する巨大グループだがそれが存在する証拠はない
統計学的には母集団が実在する証拠を出す義務はない 私は、Windowsで大きなランタイムとか必要なく
実行形式のバイナリを作れるのが助かってる。
小さいバッチプログラムとか。 ghcmod-vimってstack環境で動かないのな haskelは使わないけど関数型の勉強はすごいためになる
ライブラリが提供する地雷メソッド見抜けるようになった 意識的にオブジェクトをモノイドにしたりするようになった 皆の言う関数型の経験が生きた事をアドバイスしてるオブジェクト指向の本が出ないのは何故か その内容で一冊書きたいならそれをテーマにした小説にしてページを埋めないとだな
いいものはみんな本になるはずという前提がそもそも間違ってる >>432
楽かどうかの話じゃなくて、皆の言ってる事はここ数年の関数型の特長じゃないじゃん
ずいぶん昔から変わらない関数型の特長でしょ
関数型のいいところを手続き型(オブジェクト指向)にも取り入れようとし出したのもかなり昔の話だし
なのに、ここ数日このスレで挙げられた事が本になっていないのが不思議なんだよ
和書はともかく洋書でも無いじゃん >>431
うーん。。。
関数型言語じゃなくても気を付ければ出来るし、それがデザパタとかMVC/MVVMになってるからじゃないかな。
だから関数型言語はエッセンスを触接理解するのに使って、実用は普通の言語。
特にHaskellはIOと純粋関数が分かれてるからコマンドアプリでさえファイル=M、コマンドアプリ=VM、コンソール(ターミナル)や出力するGUI部品=Vって非常に明確。
使ってて、ああ、MVVMってこう言うことかって思った。
何つーか、MVCよりもMVVMはもっとCを広く解釈してるからVMなんだなぁとか。 C++でわからんでJAVAで半分誤解して
ruby使ったときにオブジェクト指向理解したのとよく似てるな 経験上思ったのはオブジェクト指向は先手先手で先を読んだ設計が重要。
(だからオブジェクト指向設計とかがプログラミング以外にも必要)
関数型言語はわりと行き当たりばったりでもどうにかなるし、それはオブジェクト指向じゃない普通の言語(CとかPascal)でも活かせる。
だから、メソッドチェーン使った宣言的なオブジェクト指向よりも泥臭い手続き的なプログラミングに新たな視点(設計の幅)を与えてくれる感じ。
(要するにメソッドの中身を書くときに役立つ) OOPはプロパティの値を書き換えてなんぼ、インスタンスの振る舞いをメソッド内で完結させて
なんぼだからまぁそりゃメソッド内くらいにしか関数型のパラダイムは取り入れられないよね >>439
プログラム組む前に紙と鉛筆でじっくり図書いたことないかえ?
ライブラリ使うだけの時も恐怖でそうしてた。 >>431
二つ以上の言語を使いこなす事をアドバイスしてる本ならあるよな
例えばシェルスクリプトとC言語の二つ
ここらへんではオブジェクト指向は必要ないし >>436
stack使うならどっちでも楽じゃない? >>442
ほとんど知識のないまっさらの状態
ならそうだけど、
Cは覚えること山ほどあるぞ シェルはCのmain関数を呼び出すだけだからよかった
なぜmainではない任意の関数を呼び出す必要がないのか
なぜHaskellはCの任意の関数を呼び出すのか
答えを暗記する前によく考えてみれば、覚えることが減るんじゃないか >>440
うーん。。。
上手く説明しきれてないな。。。
メソッドの中身書いてる時、手続き的なコード書く事多いけど、
設計変更の際に手続き的なコードだと破綻して新たにクラスを作ってオブジェクト指向的なコードに変える事があるんだけど、Haskell視点が入る事で一見破綻したコードでも、何とか破綻させずに改修できる目処が立つ事が増えた。
何つーか、手続き的なコードからオブジェクト指向的なコードへの切り替えを遅らせる。
手続き的なコードを延命する事が出来るようになったって感じかな。 >>446
Cはコンパイラというかリンカのオプションが多い
JITコンパイラは覚えることが少ない Haskellは初めからデザパタを、それと気づかないまま強制されているような窮屈さを感じる 代数的データは単なるVisitorパターンではなく遅延評価にも関係がある
だが同時に、型クラスで抽象化しろ、具体的な代数的データを教えるなというのがやばい ポイントフリースタイルにこだわった方がHaskellっぽいですか?
flip関数まで使い出すと非常に混乱するのですが… >>453
その考え方は本末転倒だと俺は思うよ。
プログラムコードで大事なのは関数型っぽいとか手続き型っぽいとかじゃなく、
プログラマ(自分)が読みやすい、意味が理解しやすいかどうかだよ。
Haskell を使うんだから関数型に合ったアルゴリズムはこだわるべきだけど、
その実装方法、つまり書き方は自分が読んで分かるように書こう。
そんな事はないだろうが、くれぐれもカッコイイとかで流されないように。
ただ、他人のコードは読めるようになった方が良いから、
そういう意味では多少トリッキーなポイントフリーにも慣れておいた方が良いかもね。 >>454
ありがとうございます
アルゴリズムを気にしながらもまずは自分と他人が読みやすいように書いていきます ポイントフリーはこれが本質的な処理だ!おれは本質的なことだけ書くぜ!というカッコ良さがあるからな
珠玉のアルゴリズムとか読むと、つい憧れてしまう
しかしflipを使いまくって解読不能にするのは本末転倒 uncurryなんかもカッコいいなぁ (かなり使った
ただポイントフリーは、一度くっつけたのをまたバラす時に頭が痛くなる
一種の(視覚的な)最適化なので、頻繁に組み替えてる最中にはやりたくない >>458
最適化でインライン展開されるんじゃない? ポイフリしたら型シグネチャ添えてる。本末転倒かね? >>461
それを本末転倒かもと考える事が本末転倒だよ。
大事にするところがおかしい。
コードスタイルを決めるのは何にもまして読みやすいか、考えやすいかどうかだよ。
(もちろん誰が読む、考える人かによる)
型シグネチャを添えるかどうかは本質的にはポイントフリーしたかどうかに関係ない。
・そもそも添えないと(意図したように)コンパイルできないから添える。
・添えた方がコードを読みやすい or 考えやすいから添える。
・添えない方がコードが読みやすい or 考えやすいから添えない。
これ以外の理由ってある?
(書籍に載せるのに紙面を節約するため、という理由は排除)
ちなみに俺個人は、添えた方が読みやすいし考えやすい。
どんな関数でも本体を定義する「前」に型シグネチャを書く(と言うか思い浮かべる)。
OOPにおけるインターフェース志向設計みたいなもの。 いやおかしくないでしょ。
ポイントワイズなコード にするか、型シグネチャ付けるかは悩んでもいいでしょ。
コードは短い方が読みやすい。冗長でない方が読みやすい。
しかし一時変数や型注釈は別のレベルでの理解しやすさを与えてくれる。
それらを使うか、使うならどっちか、両方か、はケースバイケースだし職人芸的な深みがあると思うよ。
場合によっては関数名の類似だけで事足りることとかあるでしょう。
個人的なバランス感覚としては、なるべくポイフリするがflipは使わない、トップレベルの型シグネチャはほぼ付ける、ただし書き捨てコードは別。
(ルークよ、セクションを使え…) 使い捨てやモナドの途中でletした関数も漏れなく型シグネチャ付けるの? >>464
俺(>>462)に言ってるのかな。
俺は内部関数にはシグネチャーは基本的に書かない。
(内部関数自体、ほとんど使わないけど)
ごめん、どんな関数でもと言ったのは、トッブレベル関数のことだ。
あと、今のコーディングスタイルにしてからは、
Haskellでいわゆる使い捨てコードというものを書かないようになった。 >>464
俺は書くときもある。でもそういう時は大抵、設計を練り直すハメになる。
なるべく上の層を充実させたいよね。
>>465
使い捨てコード書かないのは、どうなんだ。
ちょっとした実験というかお遊び的プログラミング、粘土コネコネはしないのかい。
いやでも、作っても結局設計しっかりしてないと長持ちしないなら、初めから気合い入れて製作すべきなのか。
その方がトータルのコストは節約できるということか。ううむ。 >>466
実験は基本的にちょっとしたものでも捨てない。
結果的に後で捨てることになるかもしれんが、
捨てるつもりで実験はしない。
実験の目的や結果などをメモって残しておく。
実験の時も本番の時も思考の順は同じだから、まず型から考える。
だからシグネチャは書く。
お遊びは、ごめん、その状況がよく分からん。
コードを書くことを遊びにできる心は、揶揄でも何でもなく素直に感心する。
羨ましい。
粘土は要するに実験と同じだよね。
だからシグネチャは書くよ。 入門者のおれには勉強になる。
Stateとか使って型推論させると、MonadState使ったかなり複雑なシグネチャが出てくるんだけど、
あれはなるべく汎用的なシグネチャにしておくのがいいのかな?それとも具体的なシグネチャにするほうがいい? >>465の言ってる「使い捨てコード」は単に無名関数くらいの意味合いじゃない? >>468
そりゃ、汎用的な関数を定義したかったら汎用的なシグネチャを書くし、
具体的な関数を定義したかったら具体的なシグネチャを書くよ。
モナドトランスのスタックがいつく積まれていようが関係ない。
あと、スタックがいくつも積まれた姿を常に目にしていると思考しにくい時もある。
そんな時は type で別名を付けて分かりやすくする。
すべては自分が考えやすく、書きやすく、読みやすくするため。
>>469
無名関数にシグネチャって
map ((\x -> if even x then 1 else (-1)) :: Integer -> Int) [1..9]
みたいにか?
それは無いでしょ。
>>464 がそんなことを聞いてるとは思えん。
まぁ、書かなきゃコンパイルできない場合もあるかもしれんが、
今のところ、そんな状況になったことは一度もない。
>>464 のレスを見て俺が想像した使い捨てコードはまさに >>466 の言うような「捨てる前提の実験コード」だよ。
それはやらなくなったから >>465 で捨てコードは書かなくなったと言ったんだ。 圏論を学んでみたい Haskeller、学ぼうとしたけど入門辺りで挫折してしまった Haskeller へ。
「圏論勉強会」なる一連の動画が youtube にアップされている。
(第13回まであって、それぞれ約2時間ある)
何年か前からアップされているので、知ってる人も多いと思う。
時々、Haskell で表現するとこんな感じ、といって実演して見せてくれるから面白いし、理解しやすい。
第1回はイントロダクション的な回で、圏論の雰囲気を掴むのが目的だから浅くサクサク進んでしまう。
だから難しく感じるのは当たり前なので、ここで諦めてしまわないように。
第2回からは圏論を学ぶ前の準備的な話からゆっくり丁寧に進むので安心して。
とりあえず全部一気に流して見て、2周目からじっくり学びながら見よう、
という学習スタイルはおすすめしない。
それだと1周目はテレビを何となくダラダラ見るのと同じで、何も理解できず、2周目に繋がらない。
(書籍なら自分のペースで読めるので、このスタイルでもいいと思うけどね)
それでは時間の無駄で、それなら初めから2周目のつもり挑んだ方がいい。
細かく一時停止して、今の話本当に理解できたかな、どこが理解できなかったんだろ、
といちいち理解度を確認しながら見ること。
また、動画内で例がいっぱい出てくるけど、自分でもオリジナルの例を作ってみるといい。
理解できたあかつきには、圏論はもちろん、Haskell がもっと面白くなる事を保証する。 圏論が分からん? 頭悪過ぎだろ。
まあコーダーなんてそんなもんかw 圏論どうこう以前に文系出身だから数3Cすらわからんわ
すまんな 数学教室 πの焼き方 日常生活の数学的思考って本が圏論入門以前としては良いかも。
触り程度だけど、圏論出てる。 Haskell固有のコーディングスタイルって何種類くらいあるの?それらのスタイルに名前あったりするの? shadowingも再代入できないから'を連打するパターン >>476
Haskell固有のコーディングスタイルって何?
たとえはどんなの? 圏論のアイデアを盗むのは難しくない
盗用しても、そんなの圏論じゃないから盗作じゃないもんみたいな反応なので盗み放題 >>471
いい大人が2時間x13回なんて時間取れるかよ!ぼーっと見てるだけなんてダル過ぎ
…でもありがとう >>476
まだ関数脳が出来てない時は、副作用のない関数でも手続き的な書き方するけど、関数脳が出来上がったら自然と宣言的に書いていくから、コーディングスタイルと言えるようなのは段階を踏んで成長していくもの。
そう言うのじゃなくてインデント以外にも書き方あるのかと言われれば、ある。
ブレース構文と呼ばれるCっぽい書き方。
main = do { cs <- getContents;
putStr cs}
こっちはインデントに左右されない自由に書ける。
レイアウトまたはオフサイドルールと呼ばれる書き方はPythonと同じ、インデントを考慮しないとコンパイル出来ない。
こっちが主流。
ちなみに、ポイントフリースタイルはコーディングスタイルではなく、カリー化の部分適用で見た目の引数を減らす関数の書き方。 x:xs みたいな変数名の使い方ってHaskell的だよね
関数名に意味を込めておいて変数名は短く簡潔な方がいいみたいなスタイル >>476
GitHub - jaspervdj/stylish-haskell: Haskell code prettifier
https://github.com/jaspervdj/stylish-haskell
GitHub - commercialhaskell/hindent: Haskell pretty printer
https://github.com/commercialhaskell/hindent
GitHub - evolutics/haskell-formatter: Haskell source code formatter
https://github.com/evolutics/haskell-formatter Haskellの関数のアリティは常に1なので「カリー化」も「部分適用」も存在しない Text.Printfのprintfはスゴイことをやってることはわかる
いまだに似たようなものを書くことができない >>482
引数の時点で使いたい構造に分けておくのは気に入ってる。
使わない部分は'_'で明示出来るし。
f xs -- リスト全体
f (x:xs) --リスト先頭と残り
f xxs@(x:xs) -- リスト全体とリスト先頭と残り同時利用
f (x:y:zs) -- リスト先頭から2個と残り 遅延評価分かってるつもりだったけど分かってないな
オライリーの並列本で、次のような式があって、force使ってたら並列処理に回される前に評価されて意味無いんじゃって思ってしまった
rpar (force (map solve as))
これって、rpar引数の式が式のまま引数として渡されて、rparが並列処理内で引数を評価しようとしたタイミングでmapとforceが評価されるって理解でいいのかな?
値の遅延評価は何となく頭に入ってたけど関数の評価については意識できてなかった rparが来た時点で次のrpar,rseqと並列に実行し始めるという風になってるから遅延評価とは違う?ような気がする
引数を正格にするのは単に並列化済みのそれぞれの処理を速くしたいという意図では force自体の評価は遅延されるからね
式はまだ評価されてない値と考えればいい パターンマッチの分岐を確定するのに必要な分だけ評価する
Identityモナドみたいなやつでも⊥ではないことを確定する必要があれば評価する ではなく、評価の深さに関係してるみたいですね。rparがWHNFまでしか評価しないので。rseqでも同じかな? >>491は>>488に対してです。
>>489
それでは、rseqが呼ばれるまでrparの引数が評価されないように感じるんですが、いつ評価が始まるんでしょうか? やるなら並列にやる(いつやるとはいってない)
↑
これが初心者キラー >>492
forceという関数そのものは特別扱いされないって意味
ちなみにrpar自体が引数をWHNFまで評価すると理解してるけど試せる環境がないから断言は出来ないな
forceが必要なのもWHNFの時点でrparのスパークが終わっちゃうからだと思ってるけど・・・ >>482
関数自体の汎用性とか短さも関係してると思う
変数名が具体的でなくとも何してるかパッと見てわかる関数は嬉しい >>487
forceはリストの背骨までしか評価しない。
つまり
xs=[1,2,3,4,5]
が
xs=[_,_,_,_,_]
と評価される。
でも、そのforceもリストが評価されるまで動かない。。。
マジで並列化と遅延評価は相性悪い。 いやControl.DeepSeqのforceは再帰的に評価する
というのもリストのNFDataインスタンスはNFData a => NFData [a]だからね
head $ head $ force [[1,undefined]] はエラー force自体は何も特別では無くて遅延評価される
但し、force関数の評価時に本来はWHNFまでしか評価しない状況でもNFまで完全評価するって感じか http://faithandbrave.hateblo.jp/entry/20111201/1322718742
GADTs拡張で、空でないリストを前提にコーディングできるみたいですけど、
これって、静的に空でない事が判明してないと呼び出せないんですか?
空か入ってるか判らないリストについては使えないってこと?
凄い使いにくそう NonEmptyは何かしらのモデリングを行うときにパラメータが非空リストであるといった内部で生じる条件を明に扱えるようにするためのものかと思ってる
インポートした関数をつなぎ合わせるだけの部分で便利なものではない printf関数は副作用のある出力関数じゃなくて、フォーマット済みの文字列返すだけの副作用のない関数にして欲しかった。。。 import Text.Printf
genMsg :: String -> String
genMsg name = printf "Hello, %s-san!" name
main :: IO ()
main = do
name <- getLine
putStrLn $ genMsg name ん?
もしかしてread関数みたく型指定したらいけるって事け?
テキストに行番号振るナンバリング関数で数字と文字列のタプル受け取って文字列返すラムダ式をconcat[show x,str]から書き換えたらエラー出たんだけど、型指定で行けるなら再挑戦して見るかな。。。 実装自体はHoogleで調べたら見れるけど、見ても分からんかった記憶がある。 a=>PrintfArg、b=>PrintfTypeのとき、
String -> bはPrintfTypeである
a -> bもPrintfTypeである
StringもPrintfTypeである
IO ()もPrintfTypeである
…を繋ぐと動くんだったかな 型指定で行けたわ。
>>504thanks!!
import System.Environment
import Text.Printf
-- 数値型を文字列型に変換して文字列の頭に追加
consNum::(Int,String) -> String
consNum (x,s) = printf "%4d:%s" x s
-- 文章の行ごとに番号を振る
numbering = unlines.(map consNum).(zip [1..]).lines
-- ファイル名と内容(行番号付き)のタプルを作る
zipFile_Content f = (zip f).map numbering
-- ファイル名とファイルの内容を表示
putFile_Content (f,c) = printf "%s\n%s" f c
main = do
args <- getArgs -- コマンドから与えられたファイルのリストを受け取る
cs <- mapM readFile args -- 全てのファイルの内容を読み込む
mapM_ putFile_Content $ zipFile_Content args cs -- 全てのファイルのファイル名と内容(行番号付き)を表示 この長さならputFile_Contentをラムダ式に戻しても良いな。 >>506
可変長引数の仕組みはこんな感じ
class Count r where count :: Int -> r
instance Count Int where count n = n
instance (Count r) => Count (a -> r) where count n = const (count (n+1))
countArgs = count 0
main = print $ (countArgs 1 True "a" :: Int) >>511
これcountArgは型推論で型解決されてるの? 1 2 3みたいなコードのエラーメッセージを見るに
関数適用で引数分の関数だと推論されるんだろうね Haskell - GHC for iOS : iOSアプリをHaskellで開発する
http://blog.euphonictech.com/entry/2015/01/26/210101
GUIはObjective-Cに任せて中身はHaskell。
テーブルゲーム系は作りやすい言語だから、案外向いてるかも。。。 haskell androidでググったらトップで出るお。
Ubuntuなら最初の辺りは省けそう。
cabalじゃなくてstack入れた上でcabalへのパス通す方向で行った方が失敗少なそう。 ghc ios弄ってるよ。
7.8のghcは32bits版はghc公式のサイトにある。64bits のghc iosバイナリは公開されてない。
Appleのお達しにより64bitsを同梱しなければApp Storeにリリース出来ない。
HEADは試してないけど、3/27のソースではビルドは通った(ちなみにそのソースでは32bitsは素直に通らない)。
64bits のghc iosは現在活発にメンテされているようです。
俺は今は make binary-dist (つまり、ghc-....tar.xzを作るやつ)と、stackを直しています。
stackはcross compiler対応してないので、改造が必要なんだ。stack setup --os ios で一発インストールできるとこまで持っていきたい。
> cabalじゃなくてstack入れた上でcabalへのパス通す方向で行った方が失敗少なそう。
そのワークアラウンドは思いつかなかった。詳しくおしえてくれませんか。 え、cabalって書いてるところをstackに置き換えるけど、パス通す時cabalへのパスって言う、非常に単純で頭の悪いやり方だが。。。
単純にcabalが依存関係で止まる確率下がらないかなぁと。 >>518
なるほど。俺が勘違いしているのでなければ、
http://ipx.hatenablog.com/entry/2015/05/02/093634
のページのajhcをcabal install するときの話ですね。
うちの環境はMacなのでためせないのだけど、hackageにあるajhcのcabalファイルをみると依存パッケージのバージョン指定がほぼ無いので、ひょっとするとビルド通るかも。
少なくともstackの方がcabalよりは可能性高そうですね。
スマホ開発について、俺はajhcを使うアプローチは試してないのですが、他にもGHCjsを使ってjavascriptに落とした後、
PhoneGapとかで埋め込む、って手もありそうです。 GHCjsなんてあったんだ。。。
fayってのはどこかのブログで見かけたけど。 数値が書かれた文字列の大きさを比べたりソートするときってIntに変換しなくても大丈夫? a="1000"とb="999"を比べるとして、
頭から3桁目までを比べるとbのほうが大きい
けどaにはまだ続きがあってbには続きがない、だからaが大きい
こんなアルゴリズムだったような >>521
辞書式順序になる。
“1000” < “200” < “30” < “4”
みたいに。 >>521
変換しないと悪魔でも文字列としてソートするよ?
["10","100","20"] みんなありがとう
read :: String -> Intって書くのがめんどくさくて楽したかっただけなんだ
めんどくさがらずにちゃんとやるよ naturalcompを入れた場合、
Prelude> :m +Data.List Text.NaturalComp
Prelude Data.List Text.NaturalComp> naturalComp "1000" "999"
GT
Prelude Data.List Text.NaturalComp> sortBy naturalComp ["1","99","1000","10","999","9"]
["1","9","10","99","999","1000"]
だいたい思ったとおりになると思うが >>527
ごめん。
>>522に出てたの知らなかった。
>>522のライブラリ使えば問題無いみたい。 >>529
こんな簡単なことで外部ライブラリに依存とかしたくないでしょ まあねぇ。
んじゃあ桁ごとにグループ分けして、それぞれをソートして、その後結合? >>530
俺は大いに依存(利用)して問題ないと思う。
勉強も兼ねてるなら自作を勧めるが。 昔のHaskellの(1+n)形式の引数復活しないかな。。。
代数的データ型で自然数作ったりの時、普通の関数だとこう。みたいな整合性が取れないのがね。。。
type Nat = Succ(Nat) | Zero
dec (succ(n)) = n
dec(Succ(Zero))
>Zero
dec (1 + n) = n
dec 1
>0 >>533
どんな時に代数的データ型で自然数を作るの? お遊びの時。
だから無くても困らないけど、昔あったの知ってると復活しないかな。。。と。 {-# LANGUAGE NPlusKPatterns #-} dec (n + 1) = n
は通るけど
dec (1 + n) = n
は通らない。。。
なんかモヤモヤ。。。 だからKPlusNを追加したら、ンなもんねーよって怒られた。。。
あるだけ有難いけどね。 >>539
Haskell使いって入ってるだけで、コードも何も語ってないやん。
はてなのHaskellerは優秀で良い人ばかりだお。
おいらは優秀じゃないし、プログラミング自体からほとんど引退してるからやめたけど。 Haskellのプログラミングで金をもらう
Haskellerなる人物に何人も合ったが、
精神科通いとかの頭のオカシイやつばっかだった。
たまたまなのかも知れんが。 ちなみにHaskellerがおかしいというよりは
CS業界が全般に発達障害とキチガイに寛容なだけ >>539
片方はGHCの機能追加してるガチ勢だぞ
単純な言語拡張も知らない分際でコード語ってないとかのたまってるやつ恥ずかしすぎる fumieval知らないとかモグリにもほどがある
自称関数型コミュニティでは超有名人 >>548
>片方はGHCの機能追加してるガチ勢だぞ
そうだっけ?
なんかしょうもない型クラスのインスタンス追加して喜んでた記憶しかないわ なにかHaskellにはそういう魔力めいた魅力でもあるのでしょうか 関数脳になるとHaskellが癖になるのは確か。
オブジェクト指向のメソッドチェーンも入力->出力の連鎖で、関数型と同じなんだけど、ループや分岐も再帰やパターンマッチで書くから、より入力->出力に専念出来る。
思考がシンプルになる。
オブジェクト指向も思考をシンプルにする事を目指してるけど、クラス作る側とクラス使う側で大きな溝が出来てしまった。 良くも悪くも変人しかHaskellなんて覚えようと思わないからじゃないかな
明らかに文法が異質だもの
多分みんな人生で何度か「変わってるね」って言われたことあるはず 変わってると言えば否定しないけど、どの言語にもおいらみたいなのは一部居るんじゃないかな。
強いて言えばPythonやRubyにさえも挫折したおいらがHaskellで色々書けるようになって、書けるようになってからはPythonやRubyでも書けるようになって、Cでも書けるようにもなった。
例えばRubyのeach_slice相当の関数はHaskellに存在しない。
(Hoogleで調べても無かった)
でも、動きを理解さえすればすぐに同じ動きの関数が書けた。
PythonやRubyは基本が手続き型言語だから、ライブラリを知らないとか、ライブラリに存在しない時に急に難しくなる。
おいらみたいに、LLでさえ手続き型言語で挫折した人がHaskellで出来るようになって、はしゃいでるとかは有るかもね。 例の包丁Haskellerもそうだが、使っている奴は厨二病患者が多い
本当に厨二心をくすぐる言語なんだよ…
OCamlメインの俺としては変なのがこっちに吸われていて助かる 変数も引数なしの値を返す関数。
a = 1
モナドもセクションにすればただの関数。
import System.Environment
slice n xs | length xs < n || n <= 0 = []
slice n xs = ys:slice n zs
where
(ys,zs) = splitAt n xs
main = (>>=) getArgs (print.slice 2)
そういう意味で、mainすらも引数なしでプログラムの結果を返す関数。
全てが関数と型と値だけで考えられる。
厨二で上等。
一貫した考えが素晴らしいね。
煩わしさがない。 OCamlはラクダだもんな。厨二病もクソもないw
OcamlとかClojureはコードが丸い印象。Haskellは何か尖ってるよね。 >>557
え、否定しないって言ってるじゃん。
認めてるじゃん。 >>556
セクションは部分適用した二項演算子のことだぞ あれ、どっちもセクションじゃ無かったっけ?と久しぶりに調べたら。。。
前置き形式?で良いのかな?
これは済まんかった。 >>553
>良くも悪くも変人しかHaskellなんて覚えようと思わないからじゃないかな
>明らかに文法が異質だもの
ML系のワリと平凡な文法なんだけどね >>558
OCamlもHaskellも同じML系なのにどうしてそう感じたんだろう?
おいらみたいな使ってるやつの印象ってだけだったり?
おいらみたいなのは少数派だよ。
声が大きいから、たくさん居るように感じるだけ。 すみません、質問です
f :: a -> b と g :: a -> c があったときに
\x -> (f x, g x) に相当する関数はライブラリに用意されてますか? >>564
Jは聞いた事はあっても触った事すらないので何とも言えないが、Prologは昔の関数型言語の本では次世代言語として紹介されてたな。
実際触って見て可能性自体は感じるんだが、引数が大文字始まりじゃないとダメとか、計算式が=じゃなくてisとかが、とにかく愛せなかった。。。
Prolog得意の家系図関数も、Prologなら自動で関係を見つけるのをHaskellだと家系図をモデルとした仕様書いて、関係性のルール見抜いて仕様にして、そのまま家系図をデータ型に、関係性のルールを関数にする。
関数はルールの条件を箇条書きすればそのままパターンマッチの関数になる。
この辺が手続き型言語に対するアドバンテージであり、Prologに対して見劣りする所。
でも関係性のルールを見抜く作業と、関数作る作業が私にとっては楽しいのでそれで良い。 >>566
Control.Arrow の (&&&) だ。 >>566
型でHoogle検索して見ては?
探すより作った方が早そうだが。
dfunc f g x = (f x, g x) >>569
(a -> b) -> (a -> c) -> a -> (b, c) とかで検索しても出なかったんですが
検索の仕方が悪かったのかな
>>568
そんな関数があったんですね、勉強になりました
ありがとうございます >>568
演算子としての使い方分からなくてググったわw
ほへー。。。
Arrowって基本こう使うのね。
こりゃHaskell分かりにくいってなる訳だよ。 型シグネチャから利用法読み解くのはIQモンスターでないと無理
設計者の思想を語ってもらわないと 結局>>566は解決したんかな。。。
用途に合わせて自作した方が早いし読みやすいと思うんだが。
格好いいからって過剰にArrow使ったりってのもなぁ。
もうそっちのが慣れてて早いんなら別だが。 データフローを記述するようなコードならArrow使えばいい そうね。
逆にxと関数のリスト二つ受け取って、(f x, g x)のリストを得るとかだと引数の順番好きに選べる普通の関数のが良いと思う。
dfunc x f g = (f x, g f)
なりそう言うラムダ式をmapのリスト二つ版(仮にmap2)を作って渡せば良い。
結局>>566が何をしたかったかによる。 Control.ApplicativeのliftA2を使って
liftA2 (,) f g
でもいけるよ。 >>576
>liftA2 (,) f g
あー、関数アプリカティブか。 >>572
型だろうが思想だろうが同じこと
コードを1行も書かなくても分かり合えるのはIQモンスターだけ おまいらが楽する分Haskellコンパイラの
作成が激ムズになる件。 >>573
格好いいからじゃなくて
Monadはカリー化を過剰に使ってるからタプルを使わない
だからタプルに関係のあるものはArrowの方に集まってくる >>582
そういう理由で使われてたのか
理論的にArrowベースのことやってるのかと思ってた >>533
succの逆はpredな
デクリメントではない -rw------- 1 root root 13796 5月 25 23:39 /usr/share/man/man1/cabal.1.gz
ArchLinuxでcabalのmanが読めないのはなんかのいぢめですか? リストのn番目の要素をaからbに変えたリストを返す関数とかないですかね?
splitAtで分けてから加工してまた繋げればいいのかな >>589
ilist というライブラリに Data.List.Index.setAt :: Int -> a -> [a] -> [a] という
質問そのものの関数があるよ。 元のリストを破壊することなく新しいリストを作るからね
不特定多数から参照されるデータは破壊できないから効率が悪い
所有権がないと参照できないような仕組みがあれば良いのか >>589
nとaと(x:xs)受け取ってnが0になったらxの代わりにaをcons(:)すればいい。
setAt _ _ [] = []
setAt 0 a (_:xs) = a:xs
setAt n a (x;cs) = x:setAt (n - 1) a xs >>593
それ、質問者の言う splitAt で分けてからっていう方法と同じ >>590
>>593
ありがとうございます
Data.IndexのsetAt関数の定義をそのまま使わせてもらおうと思います リストのコピーって、(既にある)リストの各要素の格納先と同じアドレスを指すポインタを新規アロケートしてく感じですか?
それとも一々要素までをもコピーするんですか? コピーしてたらリストの意味無いからアドレスを新しく指してるんだと思う。
でないと、ソートとかメモリ幾らあっても足りなくなる。 >>594
SplitAtで分けると前方がリストになる。
(++)と(:)じゃ(:)のが効率が良い。
(++)は前方のリストが長くなると著しく遅くなる性質がある。 >>594
ちなみにsplitAtのやり方だとtake n zsの一番最後が更新したい場所になるので、initした上で++[a]++ysする必要がある。
setAt n a zs = init xs ++ [a] ++ ys
.........................where (xs, ys) = splitAt zs
Haskellでswap関数を作る7つの方法とか言うページ思い出したわ。。。 x splitAt zs
o splitAt n zs (++) (x:xs) ys = x : (++) xs ys
setAt n a (x:xs) = x : setAt (n-1) a xs
これを比較して前者が著しく遅いというのは嘘八百だな >>601
reverse関数をfoldl (\x -> x:ls) [] xsで書くのとreverse xs ++ [x]で作るのじゃ反転した文字列が生成される度に右から結合されて凄く遅い。
上の>>599も、init xs ++ [a]で一旦結合して、++ ysの部分に来たらまたinit xs部分から結合が始まる。 あ、逆か。
ysから始まってリストの先頭まで結合する。
出力する際には結局先頭から(:)伝いに辿って行くのでそう言う二度手間は避けた方がいい。 ここで言う問題は、++ysそのものに害は無いけど、init xs ++ [a]で一旦先頭まで結合する処理が挟まってるってことね。 実は++も右結合なんだよな
だから init xs ++ [a] ++ ys を (init xs ++ [a]) ++ ys と解釈するのは絶対ダメ setAt i x xs = let (ys,_:zs) = splitAt (i-1) xs in ys ++ x : xs
別にこういう定義にすればいい
でこれが遅いのは単にysの部分が2パスになるから >>606
ミス
x : xsじゃなくてx : zs 別にそれでも良い。
(++)は取り扱い次第で遅くなるってだけ。 showで文字列を作るのは平気なのにリストを作ると遅い遅いと言われる現象
数学的というより人間工学っぽい リストを使う頻度はIOを使う頻度と関係ありそう
IOを使う頻度は個人差が非常に大きい 例外処理のベストプラクティスがよく分からないなー
catchとかhandleでメイン処理、例外処理共に複数行になる時に、命令型のtry~catchみたいに無名関数での書き方ってどうなるんだろう
関数に切り出して呼ぶべし、なんかな?
どっちかだけ複数行ならそっちをdoにしたら良いっていうのは分るんだけど パーレンで囲んだラムダは複数行いけるのな、見た目微妙だけど f g n = gをn回合成した関数
みたいな関数のが欲しい >>618
それって真面目なコードで使っていいのか?
融合変換で実質ループなのは知ってるけど
そもそもこのレベルを勝手に抽象化していいものかどうか なんの問題もないと思うけど
そもそも同じ関数の反復適用が iterate なんだから
たいして抽象的でもない iterative f n = foldl1 (.) $ take n $ repeat f
これより >>618 の方がわかりやすいと思う iterative f n = foldl' (.) id . map (const f) $ [1..n]
とかでもいいか。そして iterate の方があきらかにわかりやすい。 Cabalプロジェクトをstackでビルドできないだろうか?
cabalをグローバルにインストールしたくないんだ haskellで○×ゲーム作りました(頑張った私を褒めてください)
https://ideone.com/HHEWZv ゲームとかアルゴリズムとかどうでもよくて、ここが可愛いってのがポイントだろ?
('o':'o':'o': _ : _ : _ : _ : _ : _ :_) -> True
( _ : _ :'x': _ :'x': _ :'x': _ : _ :_) -> True 下は泣いてるミッフィーちゃんがクローン技術で失敗したような感じ 昔オセロ作ったけど、勝敗判定作るの忘れて延々パスし続けたわ
main =
void $ loop (player >=> ai) initBoard
where loop :: (Board -> IO Board) -> Board -> IO Board
loop f ib = loop f =<< f ib 開発環境としてleksahを入れてみたんですが、getLineのような標準入力が上手く動いてない気がします
実行しても入力出来るようにならず止まってしまうのですが、どうしたら入力出来るようになりますか? 今気づいた! leksah ってHaskell逆読みじゃん! >>68
> ["aa", "bb", f ["cc", "dd"] ] =
> ["aa", "bb", "cc", "dd"]
> となるような関数fはどのように書けるでしょうか
めちゃ遅レスでなんだけど、f [x, y] = x : [y] ではだめなの? >>634
リストの定義から明らかだと思うのでテストはしていない fを適用した結果の型が外側のリストの型と合わないってことでら たぶんshowの結果を評価する途中でunsafePerformIOすればいいんだな [ “aa”, “bb”, [“cc”,”dd”] ]
の型がどうやって合うと思ったのだろうか。 >>638
文字列型の中に文字列のリスト受け取って文字列を返す関数型が混じってる。 >>644
それは違う。関数型が混じってるんじゃない。
>>642
["a", "b", ["c", "d"]]
= "a" : ("b" : ["c", "d"])
= "a" : ("b" : ("c" : "d"))
= ["a", "b", "c", "d"]
じゃないの? >>642
自己解決しますたw nilをきちんと入れてなかったみたい。 >>645
関数自体も値なのだが。。。
仮に返り値だとしても、文字列のリストにさらに文字列のリストが入ってるので型が合わない。
["a","b",["c","d"]]
="a":"b":["c","d"]:[] --["c","d"]が一つの値なので、文字列じゃない!!とエラーになる。 どうしてもできないときは、それはする価値がないのだ
= 何かをしたくて、その手段としてそれをしようとしているが、実は何かはそれでなく別の方法でより自然に実現できることが多い。無理矢理その手段を開発する価値が本当にあるのか、もう一度考えてみよう GHCi で ["aa", "bb", ["cc", "dd"]] を評価してみれば一発だろうに
• Couldn't match expected type ‘Char’ with actual type ‘[Char]’
• In the expression: "cc"
In the expression: ["cc", "dd"]
In the expression: ["aa", "bb", ["cc", "dd"]] >>647
> ["a","b",["c","d"]]
> = "a":"b":["c","d"]:[] --["c","d"]が一つの値なので、文字列じゃない!!とエラーになる。
文字列または文字列のリストからなるリストというのはあり得るでしょう?
その場合ならエラーではないはず
>>649
> どうしてもできないときは、それはする価値がないのだ
いまの場合、どうしてもできない証明はどうするんだろう?
>>650
> GHCi で ["aa", "bb", ["cc", "dd"]] を評価してみれば一発だろうに
それだけではその評価が本当に正しいかどうかが分からない >>651
> 文字列または文字列のリストからなるリストというのはあり得るでしょう?
文字列というのが String 型を指していて、文字列のリストというのが [String] 型を指しているのであれば、
文字列または文字列のリストからなるリストという型は「あり得ません」。
なぜなら、Haskell には「型A または 型B」という型は存在しないからです。
(data T = D String | E [String] の型は T であって、D や E ではない)
> いまの場合、どうしてもできない証明はどうするんだろう?
なぜ「証明」を求めるのでしょうか。
Haskell だとこれはできないよと言われ、簡単な理由を説明された時、
あなたはいつもその証明を求めるのですか。
今回の問題に限って求めているのであれば、その理由を説明してください。
理由によっては、あなたが納得できる証明以外の説明ができるかもしれません。
というのも、できないことの証明を本当にしようとすると、かなり難しいからです。
きっと構文規則や意味論にまで話が及びます。
そんな証明できる人は稀ですし、できる能力があっても、したくないでしょう。
> それだけではその評価が本当に正しいかどうかが分からない
あなたの場合、「正しい」とは何を意味するのでしょうか。
>>650 が言っているのはきっと、GHCi で試してみれば「構文エラーであることが分かる」、
ということだと思いますよ。
それが正しいのか分からないというのは、GHC は信用できないということですか。 もしかして本当に欲しかったもの:
[["aa"], ["bb"], ["cc", "dd"]] ちなみに、自分自身を要素の型とするかのような「ネストしたリスト」のようなデータ構造(というかinfnite typeのまがいもの)自体はときどき使いたくなるので簡単なライブラリを書いたことはある。そういやOCamlは オプショナルだが infnite type 扱えるんだったっけ?? >>652
> なぜなら、Haskell には「型A または 型B」という型は存在しないからです。
「今のHaskell」には存在しないということね?
こっちは今のではなく本来のに興味があるので。
> Haskell だとこれはできないよと言われ、簡単な理由を説明された時、
> あなたはいつもその証明を求めるのですか。
簡単な理由でよいのだが、「今そうなってるから」は興味がない
> あなたの場合、「正しい」とは何を意味するのでしょうか。
> >>650 が言っているのはきっと、GHCi で試してみれば「構文エラーであることが分かる」、
> ということだと思いますよ。
さっきも言ったが、「今そうなってる」というのは 「正しい」とは異なる 方法が存在しないことの証明って悪魔の証明でないの?
できると主張する側ができることを証明しないとダメだよ
痴漢の言いがかりをつけられて、『痴漢していないことを証明しない限り有罪な』って裁判官に言われて納得できる? >>657はできるという根拠をコードで示せばいい。
Haskell 2010 に従ったコードで、しかしGHCが不当にも
型検査で排除するというような、そういうコードを示せば
話はたちまちに解決する [“aa”, [“bb”,”cc”]]
について Haskell2010 の構文規則をを充足するような
Haskellの型をつけてくれればいい >>657
みんな、特に断りがなければ今のHaskellについて質問したり語ったりしています。
なので、そうでなければ、初めにちゃんと断っておかないと、話が合わなくなります。
また、本来のHaskellとは何かも説明しておかないと、これまた話が合いません。
私は今のところ、今のHaskellでアプリを作ることに興味が向いているので、
そうではない議論からは抜けさせてもらいます。
>>658
方法の存在を仮定した場合に矛盾がおきることを示すことで、方法の非存在を示すやり方もあります。
数学(厳密な論理)の舞台に上げられるテーマであれば友好的な手です。
(面倒かどうかは別にして) >>661
うぁ、恥ずかしい、友好的な手って何だよ。
有効な手、ね。
>>659
彼、今のHaskellには興味ないそうですよ。 定義の証明をしろってことか
1の次の数は2であることを証明しろ的な
つまり1=2は間違いとは言えないのだ >>663
>1の次の数は2であることを証明しろ的な
>つまり1=2は間違いとは言えないのだ
Succ 1 = 2 とか普通にPAで証明できるけど…… >>651
それぞれのリストはあるけど、両方の型を持ったリストはない。
リストがいっぺんに受け取れる型は一つだけ。
ghciで拒否られたらそれまでじゃね?
何か作りたいわけじゃないって事?
下で将来のHaskellとか語ってるっぽいけど、今作れないでいつ作るの。
>>645見るに最終的に欲しいのは
["a","b","c","d"]
だろ?
f ["a","b"] ["c","d"]
= ["a","b"] ++ ["c","d"]
= ["a"] ++ "b":["c","d"]
= [] ++ "a":"b":["c","d"]
= ["a","b","c","d"]
じゃあダメなのか?
手段にこだわるより、目的果たす事考えようぜ。 >>658
> 方法が存在しないことの証明って悪魔の証明でないの?
そんなことないよ。不可能性の証明なんて数学では普通にあるでしょ
>>661
> 特に断りがなければ今のHaskellについて質問したり語ったりしています。
スレタイは「今の」とはなっていない。「今の」「Haskell」に限るとつまらない
「関数型プログラミング言語」 の方がおもしろい。ここは「関数型プログラミング言語」がテーマと認識している。(俺はね)
「今の」「Haskell」は単にその一つ
> また、本来のHaskellとは何かも説明しておかないと、これまた話が合いません。
本来の関数型プログラミング言語程度の意味。それはみんな意識してるでしょ?
>>667
> それぞれのリストはあるけど、両方の型を持ったリストはない。
それは今のHaskellについた制限のようなものでしょ?
> f ["a","b"] ["c","d"]
> = ["a","b"] ++ ["c","d"]
> = ["a"] ++ "b":["c","d"]
> = [] ++ "a":"b":["c","d"]
> = ["a","b","c","d"]
>
> じゃあダメなのか?
それではもとの問題と違うし、スマンが興味わかんわ >>668
将来も今も["a","b","c","d"]は[String]って型で表現できるけど、
["a","b",f ["c","d"]]はどういう型で表現するのさ?
こう表現出来るってのが無いと、ただ単に型に対する意識が低いだけのお馬鹿さんだよ? 大体、複数に型を纏めるんならタプル使えよ。
(["a","b"], f ["c","d"])
fが部分適用してない、値を返す関数なら結果の型が入るし、部分適用で関数としてタプルに入ってるなら何か受け取って何か返す関数の型がタプルにに入る。 nilわすれてるってのはさ、
[a, b, c, d] と a : b : c : d : [] が等価ってことでさ、
この末尾の:[]を忘れたらあかんってことじゃないの? 自分の間違いを認められず引くに引けなくなってるだけなんじゃないの >>672
>>668に聞いてくれ。
そもそもどんな型でも文字列が返ってくる以外は入れられない。
f = concat
["a","b",f ["c","d"]]
=["a","b","cd"] --これは>>668のやりたいことでは無い。
こう言うの以外は現行で受付られないが、それ打破するリストの型表現が存在出来るなら、将来実装されるかもな。 fは引数でもない外側のリストを無理やり拡張するのか……おぞましいな
そんな実装されたらHaskell見限るわ だよな。
だからこそmapとかの関数作りやすいのに、そんな変な機能将来に渡って欲しいとは思わん。
入力->出力が素直だからこその関数プログラミングだってのに。
欲しい最終データが手に入れば良いのに、>>668は手段と目的が逆転してんだよ。 どうしてもそれができないときは、本当にそれが必要不可欠なのか、もう一度よく考えてみよう >>669
> ["a","b",f ["c","d"]]はどういう型で表現するのさ?
関数fの型によるけどその出力がStringなら["a","b",f ["c","d"]] の型はもちろん[String]だね。
>>674
> そもそもどんな型でも文字列が返ってくる以外は入れられない。
結局、今のHaskellでは、["a", "b", ["c", "d"]] のような表現はできないと言ってるだけね?
関数型言語としてなぜそんな表現力を制限するのか分からん。どういう場合に使いたくなるかは知らんが。
>>676
> 入力->出力が素直だからこその関数プログラミングだってのに。
入力->出力が素直ってどういうこと? 自然変換のことじゃないよね?www
関数プログラミングは入力->出力になってればそれで十分だと思うが
>>68
> ["aa", "bb", f ["cc", "dd"] ] =
> ["aa", "bb", "cc", "dd"]
> となるような関数fはどのように書けるでしょうか
結局もとのこの問題について、“一般の関数型言語”でのfの不可能性をだれも論証できないのかな?
(要点さえ分かれば簡略でよいが) 型は単に「欲しい最終データが手に入ればよい」っていうよりは
ある種の性質がコンパイル時に保証されてるってのがありがたい
エンバグも検出しやすい
他の言語だと[Any] なListがあったりするけど(例えばScala)
よくあんなの使うなーって思う
>>678
> ["aa", "bb", f ["cc", "dd"] ] =
> ["aa", "bb", "cc", "dd"]
これはリテラルでこう書いてる以上、 fがどんな値を返そうと
左辺は要素が3のリストで右辺は要素が4のリストだから
パターンマッチに成功するわけない >>678
ここにいる人たちは俺もあんたも含めて誰も証明できないことは、
いままでの一連のレスですでに分かっているはず。
あんたの投げかけた議論に誰もあんたの望むようには応えられないことも分かっただろ。
あんたの話はhaskellという小さな枠組みを遥かに越えてるんだよ。
いい加減スレチだってことに気づこうよ。
頼むから、一般の関数型言語における可能性や証明の議論は大学でもっと頭のいいヤツらとしてくれ。 中途半端な数学屋なんて全然怖くないのに
数学系と聞いて逃げるHaskellプログラマ大杉 どうせならFoldableにすりゃよかったな
ま、いっか Haskell の枠組みにとらわれないなら、自分専用関数型言語の
文字列リテラルを 682 が示した Nest みたいに自由に定義すればいいもんな
これで解決だ ideoneやpaiza.ioのようにhaskellコードのコンパイルと実行を同時にしてくれるようなローカルアプリはありますか?
補完とかはなくてもいいですし、exeも生成しなくていいのですが ["aa","bb",f["cc","dd"]]=["aa","bb","cc","dd"]なるfが存在しないことは、
チャーチ・ロッサー性で説明できる。
チャーチ・ロッサー性は、簡単に言うと、計算の順番を変えても
最終的な計算結果が変わることが無いという性質。
もし上記のようなfがあるとすると、以下の2つの式の計算結果が同じでなければならない。
なぜなら、これら2つの式は、一番内側のfを先に計算するかどうかの違いしかないから。
null(tail(tail(tail ["aa","bb",f["cc","dd"]])))
null(tail(tail(tail ["aa","bb","cc","dd"])))
しかし、計算すればわかるが、上はtrueで下はfalseになるので矛盾する。
よってfは存在し得ない。
本当は、型なしラムダ計算に落としこんでからやる必要があるけど、
(型なしラムダ計算にチャーチ・ロッサー性があることは証明済み)
骨子としてはこんな感じ。 要するにLispのマクロの ,@ みたいな展開をしたいってことか? >> 683
まあ、こういうデータ構造なんか既視感あるよなと思ったら、リストじゃなくてツリーだよね
つうか Data.Tree がまんまそれ >>678
>関数fの型によるけどその出力がStringなら["a","b",f ["c","d"]] の型はもちろん[String]だね。
そこまで分かってて、f ["c","d"]が単一のStringにならざるを得ない。
つまり
["a","b","c","d"]
ではなく、
["a","b","cd"]
の様な単一の値としてしか返りようがないって分かるだろ。
あれか、複数の値を返せってか。
従来の値が欲しい方はどうすんだよ。 >>679
> 他の言語だと[Any] なListがあったりするけど(例えばScala)
> よくあんなの使うなーって思う
その例は極端すぎる。Anyは論外。型の否定と同じ。(Scalaも推奨はしてないと思うが)
> fがどんな値を返そうと左辺は要素が3のリストで
ふつうに考えてそうだよね。
そこを以下のように暗算して、できるかと思っちゃった。
f[x, y] = x : [y] とすると、
[a, b, f[c, d]] = a : b : (c : [d]) = a : b : (c : d : []) = a : b : c : d : [] = [a, b, c, d]
>>680
というわけで、ここは俺が暗算で頭の体操してミスってた。
優しく拒否してもらったがスマンw
>>686
> ["aa","bb",f["cc","dd"]]=["aa","bb","cc","dd"]なるfが存在しないことは、
> チャーチ・ロッサー性で説明できる。
折角だが今の件はチャーチ・ロッサー性(合流性)は関係ないと思う。
合流性以前の到達性が問題なので。 配列xsとysと引数を2つ取る関数gがあって、
f g xs ys = map (\x -> map (g x) ys ) xs
となるような関数fってあったりしますか?
例えば
f (+) [1,2,3] [4,5,6] = [ [5,6,7], [6,7,8], [7,8,9]]
となるような関数です >>692
hoogle で調べてみても、それっぽいものが見当たりませんね。
少なくとも標準ライブラリにはありません。
なので、その定義に自分で適当に名前を付けて使ってください。 >>693
ありがとうございます
ないならないで問題ありません
たまに使うのですが、既にあるならわざわざ定義するのも無駄だなと思っただけなので >>692
f g xs ys = concatMap (¥x -> map (g x) ys ) xs
でいいなら(つまりリストを1段階潰していいなら)あるよ。
g <$> xs <*> ys
がその答え。 >>692
zipWithに配列の配列渡せば行けるか?と書いてみた。
zipWith (map.(+)) [1,2,3] $ repeat [4,5,6]
うん。
素直に関数作った方がいいね。
リスト内包表記なら分かりやすいと思う。
f g xs ys = [map (g x) ys | x <- xs] これで行けるよ。
f x = fmap . (. (:[])) . liftA2 x
f (+) [1,2,3] [4,5,6]
[[5,6,7],[6,7,8],[7,8,9]] そういう関数ってすでにある?って質問なのにオレオレ実装載せてく人たち… 隙あらば実装
いや、プログラム板ではそれでいいんじゃないか。 組み込みの関数でラムダ式を隠蔽してしまうことには意味があるんじゃないか
ところで質問者の例だと結果が可換なのでそうじゃない例の方が良かったのでは
f (+) [1, 2, 3] [1, 3, 5] -> [[2,4,6],[3,5,7],[4,6,8]]
f (+) [1, 3, 5] [1, 2, 3] -> [[2,3,4],[4,5,6],[6,7,8]]
とか >>702
それならば、あなたはどのような意味を見いだしたのかまでちゃんと言わないと。
何にどのような意味を見いだすかは人それぞれですし。
私は、ソースは人間が読みやすい事に最大の意味を見いだします。
なので、計算結果を容易に想像できるという点で、
>>692 や >> 696 の下の定義は好きですね。 IOモナドっつーか、モナドは難しく考えんで良いだろと。
IO String >>= String
IO String >> は結果を捨てる。>>= ¥_ -> の略記。
return String ってしたらIOなString返るから、return使えばモナドの途中で純粋な関数で加工出来る。
それがIOモナドにも具体的な型にも依存しない汎用的な表現が
m a >>= a
ってだけ。
これだけ覚えれば使うにゃ十分だし、使ってるうちにただの型クラスやってわかる。
結局型クラスも型を受け取れる型ってだけで、ただの型でもあるから、純粋関数の結果としてString返すと、IO StringとStringは型が違うよって怒られる。
だからIO Stringにする為にIO Stringな関数か、return使いましょうってだけ。
具体的な型を考えれば何のことはない。
returnはそう考えればまあ自然なんだが、リターンってよりレシーブって印象。 main = getLine >>= return.tail >>= putStrLn
getLine
一行入力でIO String生成。
>>=
getLineに生成されたIO StringをStringとして右辺に渡す。
return.tail
tailは受け取ったStringの先頭を省く。
そのままだとStringのままで、IO Stringを受け取る次の>>=に渡せないので、returnでStringをIO Stringにして返す。
>>=(2番目)
最終出力のputStrLnに向けてIO StringをStringにして渡す。
putStrLn
受け取ったStringを改行付き出力。
説明のために長く書いたけど、型を揃えれば良いって分かればこうも書ける。
main = getLine >>= putStrLn.tail
何もないところからIOを生成するmain = 直後の関数以降は基本的に純粋な型を受け取ってIOな型を返せばコンパイラ通るので、何の役にも立たないけどこれもコンパイル通る。
main = getLine >>= return.tail
putStrLnも関数である以上、何らかの値を返してるので見ようと思えば見れる。
main >>= putStrLn.tail >>= print
()にIOを付けたIO ()が返ってると分かる。 IOと純粋関数の関係がどうしても理解できなかったけどwiki読んだらやっとわかったからオススメ
https://wiki.haskell.org/IO_inside stack使ってるのですが、openFileでカレントディレクトリ以外のファイルを指定って出来ないんですかね? stack関係あったっけ?
何となく¥を¥¥ってしてないだけじゃないかと予想。 タプル作ろうと思ってHoogleで
f :: a -> b -> (a, b)
f a b = (a, b)
となるような関数探したら見つからないんだけどもしかしてない?
割と使いそうなイメージなんだけど どういうときに使いたいのさ
curry/uncurry ならたまに使うけど >>710
タプルコンストラクタ
$ ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Prelude> :t ((,))
((,)) :: a -> b -> (a, b) >>713
おお、まさにこれです
ありがとうございます すみません traceデバッグについてですが
ある変数に色とかで印を付けて
IOとは別の専用簡易コンソールに出力表示とか
簡単に出来ない物でしょうか。 GHC 8.2 で実装予定の backpack なるものが一体
現在のどのような問題をどのように解決することを目指したものか、
分かる方いますか?
どうも、モジュールシステムの拡張みたいですが... 文字列のリストがあって、それぞれの要素を順番にputStrLnするだけならmapM_よりtraverse_の方がいいですか? 必要以上に多相にしたり制約を弱めるのは典型的な bad practice
concat のかわりに join 使ったりしないでしょ ライブラリコード書くときには可能な限り型クラス制約を弱めて多相に
利用するコードではむしろ反対に >>723
つまりtraverse_の方がいいって認識でいいですか? パフォーマンスモニターを提供する ekg というライブラリがあるんだが、
これ、なかなか凄いな。
統計情報がHTTPプロトコルでリアルタイムに提供されるから、
モニタリング専用のアプリを使わずとも普通のブラウザで見れる。
カウントするものをプログラムの中で定義することもできるみたいだし、
けっこう本格的だ。
パフォーマンスチューニングが捗りそう。
ちなみに、俺はこのライブラリの存在をここで知った。
http://www.stephendiehl.com/posts/production.html
このブログポストに商業アプリ制作にHaskellを使う際の心得みたいなことが書かれていて、
Performance and Monitoring の項で ekg が紹介されている。
このブログの他のポストもなかなか面白いから暇人は読んでみるといいよ。 >>725
ちょい待ち >>723 や >>724 のアドバイスに従うなら、そこは mapM_ でしょ 他の言語の書き方が良くなると聞いて始めてみたが、難しい・・・
というか今のとこ恩恵が分かんない^^; 過去何度か似たような質問や意見が出てるが、
今までこういう書き方だったのがHaskellのお陰でこう改善された、
という具体例が挙がった試しがない。
改善例が載っているブログなどの紹介すらない。
俺の中では、前後の違いを明確に説明できないものは改善とは認められない。
原因がはっきりしない事はあるだろうが、改善したと言うからには
少なくとも違いははっきりと説明してほしい。
それができないと言う事は、きっと違いが説明できないほど微妙で曖昧な変化を
改善と言っているのだろう。 いやそんなの最初からちゃんとやれよと思うかもしれんが非関数型の言語を触っているときに比べて入出力をはっきりと意識するようにはなった
特に動的型付けだと何も考えなくても動くだけのものは作れてしまうからな >>731
/: : : : : __: :/: : ::/: : ://: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ ___
/;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::、 / ヽ
/ヽヽ: ://: :!:,X~::|: /;,,;,/: :/ リ!: ::/ノ l`ヽl !: : |: : : :l: :l: リ / そ そ お \
/: : ヽヾ/: : l/::l |/|||llllヾ,、 / |: :/ , -==、 l\:::|: : : :|i: | / う う 前 |
. /: : : //ヾ ; :|!: イ、||ll|||||::|| ノノ イ|||||||ヾ、 |: ::|!: : イ: ::|/ な 思 が
/: : ://: : :ヽソ::ヽl |{ i||ll"ン ´ i| l|||l"l `|: /|: : /'!/l ん う
∠: : : ~: : : : : : : :丶ゝ-―- , ー=z_ソ |/ ハメ;, :: ::|. だ ん
i|::ハ: : : : : : : : : : : 、ヘヘヘヘ 、 ヘヘヘヘヘ /: : : : : \,|. ろ な
|!l |: : : : : : : : :、: ::\ 、-―-, / : : :丶;,,;,:ミヽ う ら
丶: :ハ、lヽ: :ヽ: : ::\__ `~ " /: : ト; lヽ) ゝ
レ `| `、l`、>=ニ´ , _´ : :} ` /
,,、r"^~´"''''"t-`r、 _ -、 ´ヽノ \ノ / お ・
,;'~ _r-- 、__ ~f、_>'、_ | で 前 ・
f~ ,;" ~"t___ ミ、 ^'t | は ん ・
," ,~ ヾ~'-、__ ミ_ξ丶 | な 中 ・
;' ,イ .. ヽ_ ヾ、0ヽ丶 l /
( ;":: |: :: .. .`, ヾ 丶 ! \____/
;;;; :: 入:: :: :: l`ー-、 )l ヾ 丶
"~、ソ:: :い:: : \_ ノ , ヾ 丶 デザインパターンのようなものが自然に学べる(要出典)
>>732
IOモナドを学んでしまうとvoidとかなんやねん!て気持ちになる 空のタプルやね
引数にタプル使わないけど戻り値には使う
他の言語では最も書きにくいパターンを敢えて書く 空のタポゥってvoidに相当するんでないのって訊いてんの! 例えばIO ()なら空のタプル自体は要らなくとも「IOという文脈に包まれている」という情報は欲しい
遅延評価がデフォのHaskellで実行順序
を保証するためにはそれらのIOを繋げる必要がある
voidは何も返さないからそれができない
こんな感じで値そのものに意味はなくとも「それとセットになっている何か」が欲しいとき空のタプルを使うことが多い 空タプルはvoidなんじゃないかっていってるの!
voidが無いなんて嘘っぱちだろっていってるの!
実質 IO void やろってゆってんの! IO () はIOモナドの中にしか現れられないが
他言語のvoidはその辺の関数に普通に紛れ込めてしまう
もちろん通常は規約とかデザインパターンなどで読みやすく気をつけるわけだけど
IOモナドならそういう意図しない副作用が無いことを
型レベルで保証してくれてありがたい 集合論でいうと()型の値の集合は空集合ではない
デザインパターンでいうとSingleton
だがvoidはSingletonではない
そもそもvoidはオブジェクトか? Haskellにおいてユニット型の値は () とボトムの2つ。 ボトムは正規形になっていない式ではないのか
途中の式のことを値といっていいのか >>747
https://wiki.haskell.org/Bottom
> Bottom is a member of any type, even the trivial type () or the equivalent simple type:
>
> data Unary = Unary value of any typeとは言っていない >>747
関数を返す関数もShowのインスタンスじゃ無いから表示出来ないだけで値として扱われてるし、途中の式も値として扱われるなら扱って良いんじゃ無い? >>742
IO ()は出力関数の(どうせ捨てられる)値として便宜上付けてるだけだしなぁ。。。
別にIO Stringで毎回"Hello"とか返したっていいのをIO ()にしてるだけ。
受け取る意味はないけど、受け取って表示だって出来る。
そう言う意味じゃvoidとは言い難いな。 >>749
型を集合とみなしたときの元(member)をずっと型が取り得る値(value)だと思い込んでた。
違うのか。
それは済まなかった。
私のレスは無視してくれ。 任意の型aに対して、()型の値(≠⊥)を返す関数 :: a -> () はただひとつ
f _ = ()
つまり const ()
しかないので、「void型を返す関数」が(パラメータ多相を除いて)
一意に決まるということを受け入れるという自殺的蛮勇がないなら
void 型と ()型を同視することはできない raincatは全ステージクリアした
スペランカー並みに弱い猫だなあれ 遅延評価でグラフィック描画して何か嬉しいことあるん? deleteを遅延するガベコレだけで邪魔臭いんだが
毒食わば皿までとnewも遅延するみたいな感じ GHCランタイムシステムのガベコレって、人間が操作するなら必ずここで一瞬停まるから、この瞬間にちょっとだけガベコレしといてねっていう細かい調整はできないの?
とにかく食い尽くしてもうなくなったら、解放可能な記憶域ないか、ようやく探し始めるしか能がないの? メモリー管理が陽に出てこないGC言語でGCについて語るAPIが存在するのも美しくないな
待機型処理の内部に組み入れられないんだろうか 実行頻度不明なのに強制GCしたらGCのオーバーヘッドに食い尽くされる可能性あるやろ
人力か機械学習でGCポイント探すしかないわ
線形型はよ Numeric Prelude標準モードできねえかな いつになったらGHCのコードに型を記述するんだよ
あんなコードじゃ常に参加してる奴しか解読出来ないだろ デバッグで行単位で進める、
変数の値を都度観察できる、みたいなエディタというかIDEってありますかね? デバッグで苦しんだことがないから分からないが
観察するべき実行時エラーが出るものなのか
必死に型を記述した結果がこれか >>768
>>769
いや、型は合ってんだけど画像いじってて行列の合計数が合わんとか、出来映えがおかしいとかそういうの。途中でどうなってるのか観察したい。
emacsのREPLでちまちま動かして確認してんだけど面倒いなって。
途中でブレークポイント設定とかGHCにあるっぽいのは見たけど、そちらをもう少し当たるのが正解ですかね。 純粋関数のprintデバッグができるDebug.Traceとかどうですか プログラミング初心者だけど将来Haskell用のデバッガを作るのが夢です ジーニアス英和辞典 第五版にぴったりの例文があった
Passion without action is??merely??a dream. デバッガよりVisual Studio並みの最強IDEがほしいわ Bounded クラスと Enum クラスのインスタンスである型 T について、
n 個の要素を持つリスト型 [T] の値を全て要素として持つリストを生成する関数を enumerate とします。
たとえば型 T の値が A と B の2つだとし、n=3 だとすると、
(enumerate 3 :: [T]) = [[A, A, A], [A, A, B], [A, B, A], [A, B, B], [B, A, A], [B, A, B], [B, B, A], [B, B, B]]
となります。
ただし、生成されるリストの要素の順番は問いません。
私は下記のように定義しました。
enumerate :: (Bounded a, Enum a) => Int -> [[a]]
enumerate 1 = map (:[]) [minBound .. maxBound]
enumerate n = concatMap (\x -> map (x:) (enumerate (n-1))) [minBound .. maxBound]
n-1個の既に作られたリストの各要素 (リスト) に新たに型 T のそれぞれの値を接頭する作り方です。
シンプルで分かりやすいのですが、問題が1つあります。
この関数が生成したリストの全要素を順に別の計算に消費するようなプログラムを作っているのですが、
上記の定義ですと、リストの全要素が消費し尽くされるまでほぼ全要素分のメモリが必要になります。
x : x : x : ... と積み上がった cons がメモリに残るような作りのためです。
消費は順に一つずつ行うので、理想的にはメモリも要素一つ分で足ります。
現実はそうもいかないと思いますが、全要素分のメモリを保持し続ける必要はないはずです。
メモリ消費量をもっと抑える良い方法はないでしょうか。 >>775
ちゃんとプロファイル取ってないから確証はないけど
enumerateの定義が悪くてメモリ食いすぎてるような気がする
Control.Monad のreplicateMをリストモナドに対して使うと
同様に重複順列を作れるからそれならどうだろうか
replicateM 3 [0, 1] -- > [[0,0,0],[0,0,1],[0,1,0],[0,1,1],[1,0,0],[1,0,1],[1,1,0],[1,1,1]]
あとリストを順に消費していくような計算ならfoldl'が使えるはず
あるいは、「EnumなT型の有限個の直積」をうまく新たにEnumのインスタンスにして、
succ: Enum a => a -> a
で例えば succ [A, A, A] = [A, A, B]
みたいに計算できるようにしておいて、
STRefを利用してsuccで更新しながら消費していく、とか https://wandbox.org/permlink/jdlx4FhKT80IWQKN
data T = A | B deriving Show
hoge 0 = A
hoge 1 = B
fuga _ 0 _ = []
fuga k x n = let (d,m) = divMod n k in hoge m : fuga k (x-1) d
piyo x = map (fuga 2 x) [0..2^x-1]
main = print $ piyo 3 >>775
import Data.List
enumerate 1 = map (:[]) [1..]
enumerate n = concatMap (\x -> map (x:) (enumerate (n-1))) [1..]
main = print $ foldl' (+) 0 $ map (foldl' (+) 0) $ enumerate 10000
これ(最適化無し)でメモリリークしないあたり
普通に深さ優先で要らなくなった枝はGCされてると思うけど あー>>778だと最後の一個が変わり続けるだけだから例としてはダメか
一応enumerateの引数やEnumリストの長さを変えてみても大丈夫だったけど みなさん、ありがとうございます。
>>776
前半の replicateM を使う方法は、プロファイリングしてみましたが、私のものとほとんど同じ結果でした。
メモリ消費の傾向もピークも同じ形です。
enumerate 14 で試したところ、最初にピークの 100MB ほどまでぐんぐんメモリを消費し、
その後 90MB 近くまで落ちてから一定です。
後半の方法はこれから試してみます。
>>777
挙げていただいたコードを Bounded と Enum を使って一般化して試してみました。
同様に enumerate 14 で実行してみると、メモリ消費傾向は全体的にほぼまっすぐな長方形に近い台形で、
ピークも 40kB と桁違いに少ないです。
>>778
メモリリークが起きていないことはどのようにして確認されました?
私は実行する時に RTS オプションの hc を付けてプロファイルを取って確認しました。
確かに深さ優先で一度ずつ探索する処理なのに、メモリが 100MB も消費されていて、
これは明らかにメモリリークしていると思ったのですが、どうでしょう?
これから、私や >>776 の前半のやり方と >>777 のやり方の違いについて研究してみます。 >>781
40KBはありえないので一般化に失敗してると思われる >>782
メモ化は空間計算量と引き換えに高速化する話だからむしろ逆のような
フィボナッチで言うならInteger 3個分のメモリがあればn番目が計算できるでしょって話だから
タプリングの方が解決策としては近いと思う
結局リストで定義しちゃうと(そして評価しちゃうと)
そのイミュータブル性のために各要素はまた参照されるかもしれないから
GHCは捨てられないんだと思ってる iterateは良いよね
iterateはメモリを無限に使うとか予想したやつを退場させてから冷静な議論ができる 人間を退場させそうな勢いのAIに同じことが言えるのかね
好戦的AIの開発を禁止できるのか 私 (>>775) のや replicateM を使う方法は仮想的なツリーを深さ優先でたどります。
なので列挙したい型や、リストの要素数の影響をもろに受けるのですね。
(リストの要素ではなく、それを計算するためのサンクが大きい?)
一方で >>777 は10進数の値を一つずつn桁のk進数に変換しており、
また >>790 はn桁のk進数の値を0から順に1ずつ足しています (>>776 の後半のアイデア)。
共に理論上は1要素分のメモリしか必要ない方法なので、かなり省メモリなんですね。
理屈が分かってスッキリしました。
みなさん、ありがとうございました。 未評価のサンクじゃなくて最終的にn-1以下の評価済み結果を全て保持することになるからメモリを食うのでは? 自由な長さのビットは標準ライブラリに無いのですか? >>792
全てとは何個ですか
有限個なら定量的に書いてください
無限なら書かなくていいです >>789
dockerでihaskellだったら使ってる >>792
そうでしょうか?
私の方法 (>>775) で data T = A|B|C の時に print $ enumerate 3 としてみると
[[A,A,A], [A,A,B], [A,A,C], [A,B,A], [A,B,B], ...] の順で評価されます。
外側リストの第1要素 [A,A,A] を評価し終えて次に第2要素 [A,A,B] を評価しようとする時、
[A,A,A] の第3要素の A はもう要らないので捨てて構わないはずです。
[A,A,B] の評価にまだ必要なのは第1要素と第2要素それぞれの A のみのはず。
さらに [B,A,A] まで評価が進めば、[A,A,A] から [A,C,C] まで評価した分はもう必要ありません。
そう考えると、enumerate n に常に必要なのは理論的には T 型の値 n 個分のみ。
評価済みの値の保持に必要なメモリ量は >>777 や >>790 の方法と同じです。
なので、評価済み結果の保持によってメモリが大きく消費されるのであれば、
>>777 や >>790 でも同様に大きなメモリを消費しているはずだと私は思うのですが、
どうでしょうか? >>792
私が原因はサンクにあるのではと思ったのは次のことからです。
私の方法 (>>775) で enumerate 3 :: [[T]] の第1要素を評価しようとする時、
まず concatMap の引数である [minBound .. maxBound] の第1要素だけが評価され、
残りは未評価のまま残ります (正確には enumFromTo の結果の弱頭部正規化ですね)。
次に map (x:) enumerate (n-1) があるので enumerate 2 の第1要素を評価する必要があります。
enumerate 2 でも同様のことが起こります。
これ、全部評価されつくされるまで、深さ分だけずっと残りますよね。
enumerate 自身が深さ方向にたどるごとに毎回呼ばれ、評価し切る前にまた呼ばれるので、
未評価で残るのは [minBound .. maxBound] の部分だけではないと思います。
このようなことが積み重なって、大量のメモリ消費に繋がっていると私は考えました。
リストを消費して何かを計算する関数に使うリストそのものを再帰的に作ると、
たぶん似たような事(無駄なメモリ消費)が起こるのではないかと思います。 副作用の無い関数は同じ引数で毎回同じ戻り値になることが保証されてます
n=2のとき
enumerate 2 = concatMap (\x -> map (x:) (enumerate 1)) [A,B,C]
となります
[A,A]..[A,C]まで評価が終わったとき enumerate 1 = [[A],[B],[C]] が評価済みとなり再利用が可能となり
enumerate 2 = [A,A] : [A,B] : [A,C] : concatMap (\x -> map (x:) [[A],[B],[C]]) [B,C]
となり n-1 すなわち n=1 のときの結果が保持されることが分かります
同様にn=3のとき同じことが生じ
enumerate 3 = [A,A,A] : ... : [A,C,C] : concatMap (\x -> map (x:) [[A,A], ... ,[C,C]]) [B,C]
のようになり n-1 すなわち n=2 のときの結果が保持されることが分かります
また n=3 のとき n=1 の結果の [[A],[B],[C]] の各要素は n=2 の結果から参照されてます
すなわちGC可能な対象は 中身の[A] [B] [C]ではなく[,,,]の外側の部分だけです
(もちろんまだ enumerate 1 をどこか呼び出される可能性があるならGCはされませんが…)
ここまで言えば>>792の意味がわかりますね?
はい なおサンクを気にされてたようですが
サンクを気おつけるべきは>>790のようなコードだと私は考えますが
lastを取れば分かります
https://paiza.io/projects/lmYXW-sssdTlAIGrju4u9g >>796
>外側リストの第1要素 [A,A,A] を評価し終えて次に第2要素 [A,A,B] を評価しようとする時、
>[A,A,A] の第3要素の A はもう要らない
後ろ二つ [A,A]は、[A,A,A],[B,A,A],[C,A,A]で共有されるから
そこで捨てるわけにはいかないんじゃないかな >>799
すいません、まだ良く理解できていません。
2点確認させてください。
まず、1行目でおっしゃっているのは参照透過性のことですよね。
次に、3行目以降でおっしゃっていることですが、それは本当ですか?
それだと勝手にメモ化が行われているように私には見えるのですが。
例えば f x = x*2 という関数が定義されているとします。
その時に、別の関数 g の定義の中で、
let a = f 1; b = f 1 in ...
とやっても、1度目の g の呼び出しで 1*2 の計算結果は再利用されませんよね。
a の束縛時と b の束縛時で、計 2 回同じ計算がされると思います。
1度目の g の呼び出しで a や b が 2 と評価された後、再び g が呼ばれた時は、
a や b はもう関数 f ではなく値 2 を指していますから、
これを以て「保存される」「再利用される」と言うのは理解できます。
以上のことから、enumerate 1 = [[A], [B], [C]] のリストも、
このままでは再利用されないと思うのですが。
再利用するには、計算結果を変数に束縛する必要がありませんか。
変なことを言っていたらすいません。 >>803
>再利用するには、計算結果を変数に束縛する必要がありませんか。
mapの引数として束縛されるんじゃないの? >>775 >>804
仮引数が束縛しているのはそのスコープ内だけだと思っていましたが、
違うのでしょうか。
let a = map id (enumerate 1); b = map id (enumerate 1)
これは2度同じ計算 (enumerate 1 の評価) がされませんか? 実際に起こっているのはこういうことなんだろうな
let a = map id (enumerate 1); b = a; c=a ・愚直にパラメーターマシマシの関数
・そのごちゃごちゃしたパラメーターをデータ構造にまとめてコードの視認性と一目理解可能性を向上したコード
後者が前者より2倍近く時間かかって悲しい
データ構造の更新に思いの外時間がかかってるのだろうか
データ構造の一部だけ更新って、変える部分だけ新しく作って、後のパラメーターは元のデータのそれへポインタコピーするだけだと思うんですけど
それでもオーバーヘッド嵩むもんなんすかね
ごちゃごちゃ版の、一つパラメーター更新して再帰で関数呼び出すだけなのと、
データ構造にまとめた版の(データ構造の)一つパラメーター更新して再帰で関数呼び出すのとは
何が処理の手間的に違うんですかね
いいからパラメーター全部そのまま関数に並べ立てた方が速いんだよって言われてるようで悲しい
性能を犠牲にせずにメンテ力アップしたい 多くの場合を受け取って、後でcaseなどで引数の場合分けをするより
トップレベルで最初に引数のパターンマッチで場合分けしてから始める書き方の方が速いんですかね
後者はなんか何度も関数名書かなきゃいけなくて汚い感じするんですが。同じlet式もボイラープレートのようにまた書かなきゃならないし
でも後者の方が高速動作する(経験則)みたいで悔しい vectorパッケージ使ってて、ベンチマークとるとVector.Fusion.UtilとVector.Fusion.Stream.Monadicにリソースが割かれてるんだけど、
stream fusionてコンパイル時に効いてて、ランタイム時には出てこないと思ってたのだが、違うんかね? 本物のプログラマはHaskellを使う - 第31回
http://itpro.nikkeibp.co.jp/article/COLUMN/20090512/329783/
> これは,GHCの最適化機能の一つである「共通部分式の削除(CSE:Common Subexpression Elimination)」によって,共通する式「unsafeVal 10」がメモ化されたためです。これにより「unsafeVal 10」は1回しか評価・実行されなくなってしまいます。 > Haskellには第8回で説明した「メモ化」という機能があるため,同じ式が複数回,評価・実行されることはありません。 >>809
パラメータごちゃごちゃってのが多引数関数なら、Haskellの関数はカリー化されてるので
変更するパラメータの箇所によっては関数定義が使いまわせて効率がよくなってる、かも
末尾再帰化で局所関数作ってやるみたいに、
外からは定義したデータ構造で受け取って、
関数内で再帰回すときはばらした局所関数を使うとかはどうか http://itpro.nikkeibp.co.jp/article/COLUMN/20070305/263828/
>本物のプログラマはHaskellを使う
>第8回 遅延評価の仕組み
>この問題を解決するのが必要呼び出しです。必要呼び出しでは,
>同じ変数から束縛された項はポインタによって共有され,
>一度簡約された項をもう一度使用する場合には最初の計算によってキャッシュされた解を利用します。
>項を共有することにより,構文はもはや通常の木構造ではなくグラフ(graph)構造を取ることになります。
>そのため,このような簡約方法を「グラフ簡約(あるいはグラフ簡約法,graph reduction)」と呼びます。
>また,同じ式の評価のために,キャッシュされた解を使う手法のことを「メモ化(memoization)」といいます。 共通部分式削除か
もしバグの原因が最適化だったら簡単だな
最適化を無効にするだけでわかる ぼく、グラフ簡約がいつされていつされないのかよく解ってない(`・ェ・´) 基本的なこと
http://www.kotha.net/hperf/basics.html
> 関数の自動メモ化はない
> Haskellの関数は同じ引数で呼ぶと同じ結果を返すので透過的にメモ化が可能だが、GHCはそれを行わない。
> 局所的な最適化によってメモ化と同じ結果になることはあるが、一般には期待できない。
> メモ化が必要なら「引数->結果」の対応を保存するデータ構造(Map、Arrayなど)を明示的に用意する必要がある。 GHCのこと
http://www.kotha.net/hperf/ghc.html
> プログラムの低水準の振る舞い(たとえば、「このループでメモリ確保は発生する?」「この式はどのタイミングで評価される?」)を理解したり、GHCの最適化の結果を見たりするのには、Core言語形式の中間出力を読むと良い。
> 特に、小さいループを可能な限り高速化したい場合など、最適化後のCore出力を比較しながらコードをいじるのが有効なことがある。
> Core形式の最終形(最適化された後、STG言語に変換される直前)は-ddump-prepで読める。 >>820
http://www.kotha.net/hperf/basics.html
Haskellの言語仕様(ja)は式の評価順序を定めていないが、
GHCを始めとする有名な処理系は全て「必要呼び(call by need)」という評価戦略を基本にしている。
必要呼び戦略のもう一つの特徴は引数の自動メモ化である。
ある関数の仮引数が、その関数の本体に複数回出現したとしても、対応する実引数の評価は高々一回しか発生しない。 困ったときはhaskell-masterことtanakhに助けを求める フィボナッチ数を漸化式で単に実装したとき、そのままだと深い部分で同じ引数による呼び出しが無数に発生してると思うんですが
自動メモ化してくれないんすね >>824
それは>>820のほうで >>775で起こる「メモ化」は>>816だろ 言語別平均年収ランキング
1位Scala 626万円
2位Python 601万円
3位Kotlin 577万円
4位Swift, Ruby 562万円
6位Java 552万円
7位Perl 551万円
8位 C言語 538万円
9位JavaScript 536万円
10位PHP 522万円
11位COBOL 509万円
以下は求人が少ないためランキングから除外
Groovy 680万円
Haskell 670万円
Erlang 604万円
LISP 581万円
尚、C++, C#は調査対象外とする >>826
>尚、C++, C#は調査対象外とする
なぜなんだ?それこそ興味深いんだが? 求人数が少ないから除外?
どうしてもその言語じゃなきゃだけど、その言語使える人が少ないって方が給料良いんだが。
(あと金出す側の資金力にもよる)
Fortranとか意外と良いぞ。
金融系なら関数型言語。 あ、Fortranは大学がスパコンで使うとかの場合ね。 なぜ 828 がジョークだと分からないんだw
831 も 829 にマジレスするなら、828 がジョークだと教えないと
(まさか 831 は 828 に対してのレスってことはないよね?) グラフ簡約で物理同値が保証されてることを「メモ化」とはいわなくない? >>834
>>816
>そのため,このような簡約方法を「グラフ簡約(あるいはグラフ簡約法,graph reduction)」と呼びます。
>また,同じ式の評価のために,キャッシュされた解を使う手法のことを「メモ化(memoization)」といいます。 メモ化って memorization の訳だと思ってたが、 memoization という造語(1968年初出)の訳だったのか
んで、メモ化は簡約結果が同値であることを利用して、
計算結果を使いまわす研究での用語だったみたいね
ttps://ja.wikipedia.org/wiki/メモ化 参照透明性を利用する
一度評価したらもう動かないのだという性質を利用するのだ
コンテナと組み合わせてほら! >>838
trace関数のソースにこう書かれてた
The 'trace' function should /only/ be used for debugging, or for monitoring
execution. The function is not referentially transparent: its type indicates
that it is a pure function but it has the side effect of outputting the
trace message.
他の関数と同様に考えるわけにはいかないようだ Python, Kotlin, underscore.js にも、memoize がある
ナップサック問題で、使う Let vs. Where - HaskellWiki
https://wiki.haskell.org/Let_vs._Where#Lambda_Lifting
これってwhereは引数に変換されるってこと?(英語うまく訳せなくて分からない) 競技プログラミングではデフォルトライブラリしか使えないので
高度なアルゴリズムは自分で勉強して実装しておいたものをコピペするしかないのだ 関数プログラミングって文字列型って上手くあつかえるの?
オブジェクト指向の最大の欠点って「文字列を上手く扱えない」ところに
あると思うんだよね。 >>846
何か「表面」があっての裏面配線なんだろ?
ではその表面って何? >>842
違うよ。
ある関数の定義に使う補助的な関数の定義は、独立してトップレベルに置く事もできるし、
let や where を使って関数定義の中に置く事もできるよ、って言ってる。
関数内部で定義されていた関数を外に出して独立させることを lambda lifting と言って、
逆に外にあった関数を別の関数の内部で定義することを lambda dropping と言うんだ。
Haskell を使うだけならこんな理解で十分なんだけど、
もともとは関数型言語の処理系の研究で出てきた用語なんで、
その辺りまで深く学びたいのなら、やつぱり英語を読めないと難しいかも。
ちなみに、そのリンク先の [3 Lambda Lifting] と比べれば、
その直後の [4 Problems with where] の方が衝撃的な内容だね。
Haskell を実用的に使っている人にとってはこっちの方が大事な内容だよ。 Haskellという土台の上に、オレオレ言語を構築する。それがモナドだ
Haskell上で動作する『ぼくのかんがえたさいきょうのげんご』
DSLプラットフォーム >>849
衝撃だけど実際どれくらいパフォーマンス上のインパクトがあるの? >>851
試せばすぐに分かるが、あのフィボナッチ数のサンプルでは全く大した事なかったりする。
確かに後者の方が遅い代わりにメモリ効率いいけど、ほとんど差が出ない事に驚くほどだよ。
差がはっきり出る例を作る方が難しいと思う。
衝撃なのはパフォーマンスの差じゃなくて、単に引数を省略しただけで
コンパイルの結果に差が出ることがある、という事実。
GHCにはこういうことがあると、頭の片隅にでも入れておいた方がいいね。
他にも「単に***を変えただけで何で意図したように動かないの?」
ってなるようなコンパイラの仕様があるだろうから、
それに出くわした時に、もしかしてと気づければ無駄に悩む時間が省ける。 STモナドとSTArrayの理解を深めるのに向いてる書籍やサイトなどがあれば英語でもいいので教えていただきたいです
競技プログラミングで少し行き詰まってて >>852
なるほど
関数プログラミング入門か実践入門あたりの和書でもポイントフリーか否かで
動作が変わるという内容を見たことはある >>851
fib1 40は1秒かからなかったけど
fib2 40だと37秒かかった
fib1 = (map fib1' [0 ..] !!)
where
fib1' 0 = 0
fib1' 1 = 1
fib1' n = fib1 (n - 1) + fib1 (n - 2)
fib2 x = map fib2' [0 ..] !! x
where
fib2' 0 = 0
fib2' 1 = 1
fib2' n = fib2 (n - 1) + fib2 (n - 2) >>855
fib1 43は1秒かからなかったけど
fib2 43は2分40秒かかった 毎回 let 束縛し直すから遅い、って凄えなこれ
手動 eta-reduction 必須、みたいなんか >>855
fib3 40、fib4 40は fib2 40と同じくらい
fib3 =
let fib3' 0 = 0
fib3' 1 = 1
fib3' n = fib3 (n - 1) + fib3 (n - 2)
in (map fib3' [0 ..] !!)
fib4 x =
let fib4' 0 = 0
fib4' 1 = 1
fib4' n = fib4 (n - 1) + fib4 (n - 2)
in map fib4' [0 ..] !! x >>855
最適化オプションを付けてコンパイルしてみ。
ほとんど差が無くなるから。 モナドを取り入れると明らかに型が違うのが分かる
Identityモナドでもいいんだが
問題なのは引数の省略ではなくコンストラクタの省略ではないか
fib1 = return (map fib [0 ..] !!)
fib2 x = return (map fib [0 ..] !! x) 呼び出し毎の関数束縛が遅いってことかね
値の束縛やトップレベルの関数呼び出しだとどの程度だろう やはり、最適化かかってんのね。
安心したけど書いてるのがもう少し速くなるかなと思ってたので、残念なような、、
linuxでgtk2hsでつくってたのをwin10に移植しようとしたら、うまくいかなかった。
gtk2hsの公式も落ちてたし、HaskellのGUIは今は何が主流 or ポテンシャル高い、なんですかね? すまん、いろんなモナドをJavaとかPythonとかのコードで
表してくれ・・・
なんとなく言いたいことは分かったとしても、はっきりとモナドが
なんなのかが分からない。
クラスとは何が違うのか。 ひところ GUI の為の FRP に熱を上げていた連中は今、何に熱を上げてるの? >>868
>すまん、いろんなモナドをJavaとかPythonとかのコードで
>表してくれ・・・
JavaかPythonのスレ逝くべきだと思うの
>なんとなく言いたいことは分かったとしても、はっきりとモナドが
>なんなのかが分からない。
>クラスとは何が違うのか。
「なんとなく」もわかってないと思うよ
あと「モナドは自己関手の圏におけるモノイド対象以上でも以下でもない」が本質的な回答 >>870
お、イキリオタクか?
平たい言葉で説明できないやつは無能なんだよなぁ・・・
自分は頭いいとおもってる??かっこいいね??本質的な解答とかいっちゃってさ CSにコンプレックスでもあんの?
テクニカルな概念をバカにわかるように説明しようとしてもムダってだけ 春先Haskell熱心にやってたが
いまはCとかアセンブラとかそんなんばっかw 圏論分からんのがここで
いくら吠えても無駄だとという… 「左辺 <- 右辺」の右辺をモナドという
左辺と右辺が等しいとは言っていないので制約が少なくて便利 letとwhereが炎上したのも
等しいと書いてあるのに時間とメモリの消費が違うのはおかしいって話だよな 圏論もモノイドもわからなくてもHaskellでコード書くくらいは出来るけどな
もっと初学者への門戸を広げないと未来がない気がする >>867
最適化オプションで差がほぼ無くなるんだから、
俺は、どっちの書き方でも良い ==> 読みやすい方で書けばOK となって嬉しいけどな。
GUI ライブラリの主流は知らんけど、ポテンシャル高いのは Web アプリ系だと思ってる。
Webブラウザを GUI のキャンバスにするタイプのライブラリ。
基本的にはどのプラットフォームでも同じように動く。
既存の Web アプリ用テストフレームワークが使える。
この辺り、ライブラリ開発者にもアプリ開発者にも大きなメリットで、
要するに開発がしやすい。
これからどんどん進化していく可能性が高いんじゃないかな。
そんなライブラリはいくつかあるけど、俺は threepenny-gui がおすすめ。
ヘンに小難しい EDSL が無く、概念が素直でシンプルだからプログラムしやすいよ。
stackage にも入ってるから導入が楽だしね。 >>879
情報ありがとう。
良い機会だしThree pennyやってみるよ。
上ででてるFRPとかいうのもやれそうで面白そうだし。 >>842
2014年とかめっちゃ情報古いのでアテにならんだろ
Revision history of "Let vs. Where" - HaskellWiki
https://wiki.haskell.org/index.php?title=Let_vs._Where&action=history Chris Okasakiの純粋関数型データ構造
Haskellを志すキッズはマストバイだわ
まだ3章だけど、木の値の更新でどうやって効率良く(更新しない部分を)扱ってるのか解ったわ
根元から辿って、毎回関係ない方を共有してけば確かに辿るステップ分のコピーしか発生しないわけだわ
対数オーダーになるわけだわ
なるほどなるほど
SML記法で書いてあるけどHaskell式としてもすぐに頭に入るわ smlnj入れたけど全然勉強進んでないなそういえば ニュージャージーSMLは大学時代情報科学実験だか演習だかの簡易コンパイラ作製でひどい目にあった
Haskellに出逢えなかったら危うく関数型アレルギーになるところだった stackで、stack buildしても上書きされなかったりします?
stack execしても、新しいのにならない、、 ・怒涛の再帰再帰再帰再帰の思考枠組みに悲鳴を上げる、手続き脳だった当時のボクの頭が
・末尾再帰最適化など実際(パフォーマンス)的なことを教えてくれず、代入なし、変更はコピーでやるとふわふわっと説明され、
(時間・空間)計算量的に現実には使い物にならないんじゃないかという疑念を払拭してくれなかった当時の講師(ボクはC++のように本格的でないものにはやる気が出ない性格)が
・演習に遅刻した奴への嫌がらせかと疑わしい程に沢山埋め込んであるレジュメの誤植を、口頭でちょろちょろっと訂正するだけのおざなり風土(レジュメだけでなくちゃんと教科書で進めろ)が
・できあがる、四則演算しかできない(途中アセンブリ言語に少し触れたのは良かったが)面白くもなんともない(ボクは本格的でないものにはやる気が出ない性格)糞仕様の言語(とそれ用コンパイラ)が
…ん? なんかほとんどニュージャージーのせいじゃないな モナドってインタフェースみたいなもんでいいのか?
つまりなんでもアリにしちゃうと、設計上様々な不整合があるから
「こういうモナド」を最初に規定してしまい、「モナドに合致しない」記述は
コンパイルで弾いてくれるの? 文脈だって言ってんダロ
文脈を保ちながら普通の値と同じように扱うための規則を定めたものがモナド haskellはモナドじゃないものもコンパイル通しちゃうよ
モナドであることの保証は自分でするしか >>891
モナドってより型クラスがインターフェースに近い。
んで、モナドは型クラスの一つでしかない。
等値を司るEq型クラスのインスタンスになれば=が使える。
大小比較を司るOrd型クラスのインスタンスになれば<や<=が使える。
それと同じ。
逐次処理を司るMonad型クラスのインスタンスになれば>>=とreturnが使える。
IOモナドはIO型を受け取るモナドってだけ。
素のモナドを使うのがほぼIO型しかないからIOモナドって一緒くたにされるけど、IOとモナドは分けて考える。
リストやMaybeもモナドのインスタンスなので、モナドでもある。
モナドが他の型クラスと違うのは、メソッド定義(インターフェースになる関数や演算子をインスタンスになる型で定義)の時にモナド則に則って書く必要があるということ。
それとモナド則を正しく定義できたかは型クラスには無関係なので、定義した人が正しさを保証する必要があるということ。 万能で汎用のDSLも作れるけどそれは手続き型言語と同じだから作らないんだよ
IOはごく一部で使われるDSLであるべき
他のところではIOとは別のDSLを使うべきという設計 Haskellによる手続き型言語の
分かりやすくて面白い実装きぼん
(学習用のおもちゃでよろし) >>891
ぶっちゃけていうとライブラリ実装者専用の
グローバル変数置き場って感じじゃね?
ライブラリのユーザはその中身は気にせずに使う。 ListTの使い方ようわかりまへん
do
x <- [1..9]
なんちゃらかんちゃら x
って、リスト感覚で使いたいんですが 直受けの50万 客:いつまでもうちにいていいよ
3次受けの50万(客は70万払ってる) 客:短期延長していい?
5次受けの50万(客は110万払ってる) 客:作り終わったらとっと出てけ できなかったら即退場だ
長時間労働 高稼働 高スキル要求が多い
零細フリーランスサイトは5次受けから誰もできない難易度の高い仕事 余り物の仕事を紹介してくる。40万円代でやってくれと
これならJIETから3次でいったほうがいいな
446非決定性名無しさん2017/08/02(水) 22:12:48.95
JIETに毎月5千円払えば3次から入場できるだろ?
高額をうたうフリーランスのサイトはだいたい5次から45万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした
473非決定性名無しさん2017/08/03(木) 15:21:30.71
JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の
間でやらしている。
372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ
それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト
自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む >>899
x <- ListT $ return [1..9]
でもListTはモナドの結合則を破るというか
場合によっては幅優先になるから不用意に使わない方がいい >>901
ListTには失望しました。もう積むのやめます そもそもやろうとしてることに(よくよく考えたら)モナド変換必要なかった
本当に必要だったのは foldl でした
一方ロシアは鉛筆を使った 以下のhogeを定義してください
foldl' f a xs = foldr1 seq $ hoge $ scanl f a xs
hoge xs = ??? 引数の適用順序の理解が足りないだけでした
f x = id id id id id id x
というのがあったら
f x = (((((id id) id) id) id) id) x
という感じに左から順番に適用されるんですね
foldr f g [1..9] 707 も (foldr f g [1..9]) 707 と括れば理解できました Data.Map.findWithDefault について質問です
マップに存在しなかったからデフォルト値を返したのか、それともマップに存在したからそれを返したのか
一目判らないとき、デバッグでどうやって判定しますか? 判定不可能でありそれが意図するところじゃね?
変な値をデフォルトに入れておくか
a->k->Map k a->Either a a的なのを用意するしかないんじゃ findWithDefault d k m = maybe (trace "default" d) (trace "existed") $ Map.lookup k m >>910
やったぜ。ドバァーっとヒット/ミス/更新がその時の検索キーと共に時系列で出てきた。 もう気が狂う程気持ちええんじゃ。
ログまみれのコンソールを見つめてメモ化再帰の効果を確認したりした。ああ〜〜たまらねえぜ。(ありがとうございました) >>910
ポイントフリー化に成功しました
findWithDefault = curry.(.uncurry Map.lookup).(`maybe` trace "existed").(trace "default")
https://ideone.com/RVpv4o 新しい言語を勉強してると「Haskellならこう書けるのになんだかな〜」となってしまう Haskell書いてると「OCamlならこう書けるのになんだかな〜」となってしまう 岡村の方が速いらしいっすよ。でも、そうですね…やっぱり僕は、王道を征く、Haskell系ですか 双方向リンク系のデータ構造って、Haskell で作るのムズいね。
作るだけなら良いけど、更新時の処理で頭こんがり。
任意のノードに外部からアクセス用リンクが張ってあると
もう訳分からん。 そういうことするなっていう設計の言語で強引にしようとしたらわけわからなくなるよ >>920
そういうことするなってのは入門書には書いてないじゃん。
じゃあ、ちょっくらやってみようか、ってなるのがプログラマでしょ。
できるかもしれんし、できんかもしれん。
まぁ、かなりムズいなってのは体験して分かった。 >>921
あー。Haskellでは状態を変更しない為に単方向リストを用いるって書いてなかった? >>922
リストの定義とか使い方とかは載ってたけど、
なんで単方向のなのかの説明は無かったよ。
「Haskell:The Craft of Functional Programming」
「Beginning Haskell: A Project-Based Approach」 Purely Functional Data Structuresなら触れられてるかと思って探してみたけど
そもそも双方向連結リスト出てこないな(´・ω・`)
でも永続データ構造の概念を知ればなぜ扱われていないかが分かるだろう多分 何で双方向リストの必要なんかあるんですか
途中で戻るとか男らしくないっすよ >>926
巨大な双方向グラフを作ることになったんだけど、 使い方は次の通りちょっと特殊。
* あるノードにアクセスしたら、その近隣のノードも集中的にアクセスすることが多い
* ノードが持つ値の読み書きアクセスが圧倒的に多く、グラフの形を変えることは少ない
* ノードの値の書き込みアクセスよりは読み取りアクセスの方が多い
既存の汎用的なグラフ ライブラリと、双方向リンクで自作したグラフ ライブラリとで、
どっちが効率いいか実験してみようと思ったんだ。
でも双方向リンクは、ひとつのノードの値を変えるためにどうしてもグラフ全体を作り直す羽目になる。
どうにかならんものかと考えてたけど、どうにもならんね・・・ 「doubly linked list haskell」でググって適当な実装拾う すごハスにあるようなZipper構造かな必要なのは 書き換えしないんだったら ([a], a, [a]) みたいなので充分なんだよな
コモナドにしてどうたらとか余計な話も無視して あの、欲しいのはリストじゃなくてグラフなんだ。
だから、zipper 系とは違う。 最低限木じゃないと効率的かつ単純なのは無理なんじゃないかな?
あんま自信ないけど 皆のレスがどうも勘違いしてると思ってたら、
俺が最初に双方向リンクと言ってしまったからか。
ごめん、相互リンクだ。 >>932
木構造でも、親ノードへのリンクを入れると相互リンクになって難しくなるよね。
ひとつのノードの値を変えるためには、
ツリー全体を作り直すことになるんじゃないかな。
HaskellのDOMツリーのデータ構造とかどうなってるんだろ・・・ よく考えたら、リストとかツリーでも、
途中のノードの値を変えたかったら、
そのノードまでリンクで繋がってる全ノードは、
新しくリンクを張り直さなくちゃいけないんだね。 そうです。途中の値の変更は
リストならO(n)
ツリーならO(log n)
>>934
ランダムアクセスしないなら木に入れなくてもその都度親リストを作ればいいんだけどね
なおかつそれをカーソル的に使ってやれば平均で更新のコストも減らせる
ってこれzipperか 何が何でも1つのプログラミング言語で何とかしようとするのって
異国に行っても母国語で通そうとする観光客と同じ >>938
ひとつの言語がどこまでできて、何が得意で何が苦手なのか、
ひとつの言語に集中してそういうのを学ぼうとするのも、
おまえの言う「母国語で通そうとする観光客」カテゴリに入るのか? >何が何でも1つのプログラミング言語で何とかしようとするのって
>異国に行っても母国語で通そうとする観光客と同じ
こういうやつにかぎってポリグロッタルコストを甘く見てる 私はHaskell以外のプログラミング言語で書く気はありません ICFP 2017 で発表された資料、成果や知見はどこかで後悔されたりしないんですか?
動画が公開されてるんなら、有料でも見たいです。 発表者各自が公開してるの地道に探すしかねーんでないの
ICFP Conference(@icfp_conference)さん | Twitter
https://twitter.com/icfp_conference >>945
やはりそうですか。
毎年そうやって発表者や参加者の発信を探すのですが、
分散しており、詳しいことは書いてないことも多く、
情報集めに苦労する割には、たいてい徒労に終わります。
有料でいいので公式がまとめて公開してくれるといいのにと
ここ数年つたない英語でメールを出しているのですが、
相手にしてもらえませんね。
すいません、愚痴でした。 icfpが何なのか知らないけど「icfp video」「icfp paper」で検索してみた
ICFP Video - YouTube
https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw
gasche - GitHub
https://github.com/gasche
ICFP 2016- Proceedings of the 21st ACM SIGPLAN International Conference on Functional Programming
http://www.sigplan.org/OpenTOC/icfp16.html
フェイスブック、レディっと、ラムダザウルチメイトなどの良く知られた媒体でも
事前告知や事後報告があると思う >>947
指摘を受けて、もしかしてと思い、改めて公式サイトの中を探してみましたら、
paper は公開されていることが分かりました。
過去のも見てみましたら、去年のもの paper にはアクセスできるようでした。
(その前のは公式からはリンクは張られていない模様)
video も年によってはリンクが張られていたりします。
なかなかぱっと見では分かりにくいところにリンクがあるのですが、
やはり探し方が悪かったみたいでお恥ずかしいです。
ちなみに、ICFP は国際的な関数型言語の会議です。
使う側、処理系側双方の最新情報を発表したり、
ワークショップが開かれていたりします。 Haskellの正規表現ってどのライブラリを使うのが無難?
Text.Regex.Posixをimportしようとすると、Text.Regex.BaseかText.Regex.PCREの間違いじゃね?って言われて困惑 (´・ω・`)あのー
なにかおすすめの参考書ありませんか?
初心者です
むちゃくちゃ簡単でやさしく書いてるのが良いです
アマゾンで見つけて最近出たみたいなんだけどこれはどうなの?
Haskellによる関数プログラミングの思考法 https://www.amazon.co.jp/dp/4048930532/ref=cm_sw_r_cp_api_ozpUzbZS57HY2 正直Haskellで「簡単でやさしく」は無理です
諦めてすごいH本やHaskellWikI,Hoogleや各種書籍、サイトを何度も往復して苦しみながら覚えてください すごいHaskell楽しくなんとかって奴がいいらしいよ
あとリアルワールドHaskell >>951
他の人も書いてるけどやはり「すごいHaskell」がとっつきやすさは高いと思う
それでいて内容もちゃんとしている
「関数プログラミングの思考法」もいい本だとは思うのだが
目的がアルゴリズムデザインとかの方面であんまり初心者向けっぽくない >>954
>>956
(´・ω・`)すごいHaskell読んでみます
ありがとー 英語が読めればwikibooksのやつもどうですか?
自分は"プログラミングHaskell"から入ったので初見じゃないですが、良さげに見えます。
内容も定期的に更新かかってますし。 「しゅごいHaskell」はダブルVサイン出しながら
読まなきゃいかんのでキーボードが打てない He probably meant Haskell wikibook page is upto dated. And that is also why I recommend it for beginners too. >>957
あなたがそもそも関数型プログラミングに慣れ親しんでいないのであれば、まずはそこが第一の壁となるでしょう
まずはリストをメインに再帰やマッピング、畳み込みといった操作に慣れましょう
またHaskellはデフォルトでカリー化されているのでその妙味も十分に味わいましょう
次に壁となるのは、型や型クラスでしょうか?
ここではクラスやインスタンスといった単語が出てきますが、それらはいわゆるオブジェクト指向で使われているものとは意味が全く違うので注意してください
型に慣れ親しみ、常に適切な型を選択できるよう意識してください
そうすればコンパイラがあなたの強い味方となってくれます
最後に入門者の壁となるのは、おそらくモナドでしょう
モナドは数学の圏論由来の概念ですが、別段圏論に詳しくある必要はありません
基本的な部分では、モナドは単なる文脈であり、文脈を表すためのコンテナです
しかし、それ以上に高度で抽象的なことをやろうとすると、その理解では行き詰まるかもしれません
そんなときは、圏論に軽く触れてみるのもいいでしょう
少なくともかの有名な
「モナドは単なる自己関手の圏におけるモノイド対象だよ。何か問題でも?」
をざっくりとでもいいので理解できれば、新たな視界が開けると思います
Haskellは簡単な言語でもやさしい言語でもありませんが、その代わり高度に抽象化された、バグの少ないプログラミングが可能です
あなたの成功を心より祈っています 歳を取って反射神経鈍ってくると一々詳細を語るのが億劫になって抽象的なまま話を進めたくなるよね
Haskellは抽象的にプログラミングするインフラを整備している? Map a (Map b c)
Map (a,b) c
どっちが速いかみんな一度は悩んだことあると思う コンパイルしたらどうせ一緒になると思って適当に書いてたけど、変わるの? Mapは平衡二分探索木だから各Map b cのサイズに開きがあると遅くなるね newtype F a b c = F (Map a (Map b c))
newtype G a b c = G (Map (a, b) c)
これでFとGはどうせ一緒のクラスになる
こういうポリモーフィズムの意味がわかってる人は速さで悩まない それは実装を隠蔽しただけで速さの悩みを解決したわけではないのでは…
もちろん実装を隠蔽しておいて後でより速い実装に
容易に交換できるようにしておくのは大変有用だが pi :: Floating a => a
円周率piの値を隠蔽し精度の悩みを解決 今更だけど、いつの間にか cabal のバージョンが 1 から 2 になってる
なんか大きく変わったの? >>4にある解説ページをちらっとみた
たしかに数式に似た感じでものすごく簡単に書けるみたいだね
たしかに直感的だとおもった haskellコンパイラはユーザ定義のモナドが
モナド則満たすことを
チェックしてくれない所がウンコ QuickCheck的なのがコンパイル時に走ってチェックしてくれたりするように
そのうちならないかなー モナドを自作したことがないから後学のためにどういう状況でどういうモナドを自作すると効率的なのか教えていただけると幸いです 原理的にモナド則のチェックの自動化は不可能なの?
圏論マスターでも無理なの? ユーザが書いたモナドであることの形式的証明を
検証出来る処理系なら有るはず。
Coq辺り。 Vectorパッケージで、基本Unboxedにして、
Unboxedに出来なければBoxedにする、
途中でUnboxedにできるなら戻す、
でのを手でやってるのですが、スマートなやり方ってありますか? QuickSpecならなんとかしてくれる
かもしれない stack プロジェクト内の cabal ファイルの build-depends の項に sdl2 を書き込んで、stack build コマンドを実行しました。
すると、sdl2 パッケージのビルドでエラーが出て、「-fPCI を付けて再コンパイルしてください」と出力されました。
そこで stack build --ghc-options="-fPIC" コマンドを実行してみました。
しかし、それでも同様のエラーが起き、ビルドできません。
stack による sdl2 パッケージを利用するプログラムをビルドするにはどうすれば良いでしょうか。 >>984
やってみましたが、結果は変わりませんでした。
今使っている lts-9.5 の snapshot が
~/.stack/snapshot/x86_64-linux-tinfo6-nopie/lts-9.5
にあるのですが、nopie とあり、何か問題に関係ありそうなのですが、どうでしょうか。 >>986
とりあえず先に進めるようになりました。
アドバイスありがとうございました。
たしかに私は ArchLinux を使っています。
Haskell の問題にディストリビューションの違いが絡んでくるとは考えていませんでした。
はじめ ncurses5-compat-libs をインストールしただけでは解決されませんでした。
(ログインし直しても)
そこで stack を一度綺麗にアンインストールしてから再インストールし、
それでもダメで、更にビルド時に -fPIC オプションを付けたらエラー無く通りました。
何が原因で処置がどう働いてこういう結果になったのか、まだ何となくでしか分かりませんが、
とにかく SDL を用いたプログラムを試すことができるようになり良かったです。 集合Aと整数mを引数に取り、Aの可能なm分割全体から成る集合Mを返す関数を作りたいです。
(m分割とは集合論的にm個の集合に分割することとする)
例:
集合 A = {a, b, c, d} と m=2 を引数に取ると、下記の集合Mを返す。
M = {{{a}, {b,c,d}}, {{b}, {a,c,d}}, {{c}, {a,b,d}}, {{d}, {a,b,c}}
, {{a,b}, {c,d}}, {{a,c}, {b,d}}, {{a,d}, {b,c}} }
集合を表す型は何でも良いです。
Data.List でも Data.Set でも、その他の型でも。
Haskell で効率よく書けるでしょうか。
ここでいう効率とは、空間よりも時間を優先します。
空間も小さければ尚良いですし、ソースが綺麗ならいっそう良いです。
かれこれ一週間ほど考えていますが (と言っても四六時中ではありませんが)、
なかなか良いアイデアが浮かびません。
前もって言っておきますが、実際の集合Aのサイズはせいぜい20程度で、分割数も2に固定です。
質問のきっかけとなった問題は愚直に実装して解決しました。
なので、この質問は純粋に頭の体操、ゲームです。 集合の任意の要素m個(nCm)に1〜mの番号を重複なく振る(順列m!)、残りの要素に1〜mの番号を適当に振る(m^(n-m)) >>989
その方法ですと重複が起きます。
極端な話、集合 {a, b} を 2 つに分割する場合、
番号 1 と番号 2 を重複無く振る方法は2通りあります。
1. a=1、b=2
2. a=2、b=1
残りの要素は無いのでそのまま目的の集合を作ると、
どちらの方法で作っても同じ集合 {{{1}, {2}}} になります。
最後に重複をまとめて排除するのでしょうか。 部分集合作って差集合とのタプルにして最後に重複省くくらいしか思いつけない {a, b, c, d, e}でm=3なら
{a, b, c, d}でm=3のときの答えのリストにmap(:)'e'
それに加えて、{a, b, c}でm=2のときの答えに(:)'e'
集合の長さとmが同じならそのまま返す
みたいな感じじゃダメ? 訂正
{a, b, c, d}でm=2のときの答えに(:)'e' >>992
>>993
要素数5でm=3なら、結果の集合の要素数は25ですけど、
その方法で25個すべて出ます? inter :: a -> [[a]] -> [[[a]]]
inter x = go
where
go [] = []
go (y:ys) = ((x:y):ys) : map (y:) (go ys)
part :: Int -> [a] ->[[[a]]]
part _ [] = []
part 1 xs = [[xs]]
part k (x:xs) = map ([x]:) prev_ks ++ concatMap (inter x) ks
where
prev_ks = part (k-1) xs
ks = part k xs
main = print $ part 3 [1..4] >>995
素晴らしいです。
正直 >>992 の時点では意味が分からなかったです。
(答えに (:a)'e' とか)
コード見て意味が分かりました。 n個の異なる要素のリストから[3,3,4,1,8,...]などとサイズ指定リストに従って分割するときの全列挙をするにはどうしますか?
分割はサイズ以外に見分けはつかないものとします
[[a,b,c],[d,e,f]]
と
[[d,e,f],[a,b,c]]はダブルカウントです 分割の言葉のお前の定義からきかせてもらおうか。英語でok bunkatsu "abcdefghij" [1,2,3,4]
なら
[["a","bc","def","ghij"],...みたいにです このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 254日 1時間 35分 58秒 2ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 2ちゃんねる専用ブラウザからの広告除去
★ 2ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。