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

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

■ このスレッドは過去ログ倉庫に格納されています
0001a36 ◆K0BqlCB3.k 2011/10/07(金) 12:27:25.71
haskell.org
ttp://www.haskell.org/

日本語サイト
ttp://www.sampou.org/cgi-bin/haskell.cgi
ttp://www.shido.info/hs/

過去ログ
関数型プログラミング言語Haskell
Part1 ttp://pc.2ch.net/tech/kako/996/996131288.html
Part2 ttp://pc2.2ch.net/test/read.cgi/tech/1013846140/
Part3 ttp://pc8.2ch.net/test/read.cgi/tech/1076418993/
Part4 ttp://pc8.2ch.net/test/read.cgi/tech/1140717775/
Part5 ttp://pc8.2ch.net/test/read.cgi/tech/1149263630/
Part6 ttp://pc11.2ch.net/test/read.cgi/tech/1162902266/
Part7 ttp://pc11.2ch.net/test/read.cgi/tech/1174211797/
Part8 ttp://pc11.2ch.net/test/read.cgi/tech/1193743693/
Part9 ttp://pc11.2ch.net/test/read.cgi/tech/1211010089/
Part10 ttp://pc12.2ch.net/test/read.cgi/tech/1231861873/
Part11 ttp://pc12.2ch.net/test/read.cgi/tech/1252382593/
Part12 ttp://hibari.2ch.net/test/read.cgi/tech/1272536128/
Part13 ttp://hibari.2ch.net/test/read.cgi/tech/1286706874/
Part14 ttp://hibari.2ch.net/test/read.cgi/tech/1299385928/
Part15 ttp://hibari.2ch.net/test/read.cgi/tech/1310199414/
0446デフォルトの名無しさん2011/11/10(木) 19:47:03.85
>>418
Yampa 関連のドキュメントは論文も含めてけっこう多いので、
どれがオリジナルなのかもさっぱりなんですが、
どれも個々の特徴を割り下げてたり、活用したり、
さもなければ全体を長々と解説してる感じのものばかり

もっと、全体の構造をスパッと語ってくれると、
それだけでもありがたいのですが、無いですね

reactive も勉強してみたんです
シンクの仕組みがなかなか独特で面白かったんですけど、
結局これは「今はまだ」使えんと思いました

挙動が予測と噛み合わない部分や、予測し難い部分がちょくちょくあるんですよね
例えば integral 関数を使ってると、タイムリークを起こすと言うのかな、
間に合わなかった計算処理がどんどん積み上がっていって次第に処理が遅くなりました

この辺り Yampa なら react 関数を呼ぶ（呼ばれる）タイミングを
そのタイミングの処理の重さに合わせてリアルタイムに調整することは楽にできるんですが、
reactive ではその辺りどうやればいいのかよく分からない
0447デフォルトの名無しさん2011/11/10(木) 19:53:02.29
>>445
(^) :: (Num a, Integral b) => a -> b -> a
だから、(a^2)の2の型が何になっても、式全体の型には関わってこない
0448デフォルトの名無しさん2011/11/10(木) 20:31:23.29
>>447
こうすりゃいいじゃん

(^(2::Int))
0449デフォルトの名無しさん2011/11/10(木) 21:08:18.64
>>448
それ>>442の話と関係なくね？
0450デフォルトの名無しさん2011/11/10(木) 21:24:40.76
>>449
自作の関数作るときとかは、型推論に任せるより自分で決めた方が速かったり、逆に遅い代わりに大きな数を扱えたりする
length関数と同じ機能の関数mylength作るとき、

mylength [] = 0
mylength (_:ns) = 1 + mylength ns

の型は[a]->aだが、

mylength::[a]->Int
mylength [] = 0
mylength (_:ns) = 1 + mylength ns

とすれば、当然ながら型は[a]->Intになる
0451デフォルトの名無しさん2011/11/10(木) 21:26:17.73
訂正

x [a]->a
o [t]->a
0452デフォルトの名無しさん2011/11/10(木) 22:01:08.03
>>450
だからそれは(a^2)のケースでは関係ないよね
0453デフォルトの名無しさん2011/11/10(木) 22:06:04.65
>>452
自分で作る関数なら自分で型を決めればいいし、すでにある関数なら、引数に渡す値の方の型を決める他あるまい
0454デフォルトの名無しさん2011/11/10(木) 22:16:47.46
>>453
大抵の場合は、自分で作る関数の型さえ決めれば型推論で自動的に全ての型が決まるんだよ
それだけで決まらないこともときどきあって、(^)はそれを発生させる例の筆頭
0455デフォルトの名無しさん2011/11/10(木) 22:33:42.23
>>454
そういう話だっけ？
速い型を使いたいけど、型を明示した方が良いのか？って話だった気が・・・

単なる数字（例えば５とか）は、通常Num a。定数として宣言すると、Integralにデフォルトでなるから、数字をInt型にしたいなら、5::Intって具合に宣言しないとダメ
>>441への回答としては(^(2::Int))と書け。が、妥当だと思うんだが・・・

*Main> :t 5
5 :: Num a => a
*Main> let a = 5
*Main> :t a
a :: Integer
*Main> :t 5::Int
5::Int :: Int
0456デフォルトの名無しさん2011/11/10(木) 22:48:37.04
>>441は何も質問してないのに回答とかよくわからん
俺は>>442に対する>>443の回答に反論してるだけだよ
0457デフォルトの名無しさん2011/11/10(木) 23:17:35.61
>>456
ん、んんん？
だったら、>>450の通り、先に型を書けば防げてるだろ？
(^(2::Int))は併用すればいい話じゃね？
ごちゃ混ぜに話すなよ
0458デフォルトの名無しさん2011/11/10(木) 23:20:16.10
何が防げてるの？
0459デフォルトの名無しさん2011/11/10(木) 23:32:16.57
>>458
遅いIntegerやNum aを使うのを防げてるだろ

だあ、もう

beki1 a = a ^ 2

beki2 :: Int -> Int
beki2 a = a ^ 2

beki3::Int -> Int
beki3 a = a ^ 2::Int

下に行くほど、遅い型を使うの防げてる

以上

0460デフォルトの名無しさん2011/11/10(木) 23:40:30.36
先に書くだけじゃ、2がIntegerになるのは防げないんでしょ？
0461デフォルトの名無しさん2011/11/10(木) 23:54:39.66
>>460
そうだな
ただ、一般的には自分で型を書いた方が速い型を選べる

(^(2::Int))も出してるのに、そこに拘るってのもどうなのよ？
併用すればいいじゃないかって書いたよな？
そこは認めるのか？
0462デフォルトの名無しさん2011/11/11(金) 00:20:31.17
もちろん併用は有効。
だけど>>442に>>443の回答は誤り。
0463デフォルトの名無しさん2011/11/11(金) 00:32:29.31
>>462
絡むんじゃなくて、こうだから、間違いって指摘しろよ
時間の無駄
0464デフォルトの名無しさん2011/11/11(金) 00:42:49.60
それこそ

beki n = beki' n 2
0465デフォルトの名無しさん2011/11/11(金) 00:47:17.39
書き損じ・・・

それこそ

beki n = beki' n 2
where
beki'::double->Int->double
beki' n m = n^m

なら、ちゃんとn^2そのものを書く前に2の型も決められるしな
（さすがに、こんな反論もどうかと思うが）
0466デフォルトの名無しさん2011/11/11(金) 00:49:18.12
要するに型を書けば解決する話。
先に書くか後で書くかは無関係ですな。
0467デフォルトの名無しさん2011/11/11(金) 03:36:49.91
c言語でのint (*)[4]型っぽいものをhaskell的に表現する場合、
* = Pointer, [] = Array4, int = Intと置き換えて、
Pointer (Array4 Int Int Int Int)とでも書けるんだろうけれど、
int (*)[100]型とかになってくるととても書いていられない。
何か上手い方法はないだろうか。
用途ねーだろって突込みは無しで。
0468デフォルトの名無しさん2011/11/11(金) 08:48:39.45
>>467
コード生成じゃ駄目？
0469デフォルトの名無しさん2011/11/11(金) 08:49:33.54
Data.Arrayってそういうのじゃないの？使ったことないけど。
0470デフォルトの名無しさん2011/11/12(土) 01:01:56.40
reactive-glutを試そうとしたら依存パッケージのcategory-extrasがインストールできなかった。
out of dateなパッケージかどうかすぐに分かる手段ってあるのかな。
0471デフォルトの名無しさん2011/11/12(土) 08:11:04.13
ListはもうEducationalモジュールに引っ越せ
0472デフォルトの名無しさん2011/11/12(土) 12:18:07.24
>>471
引っ越したとして、代わりに何を標準ライブラリに入れるの？

今までの List と互換が無ければ今まで作ってきた資産が死ぬし、
さもなければ互換性を捨ててでも入れる大きなメリットがあるものじゃないと
0473デフォルトの名無しさん2011/11/12(土) 15:32:33.20
haskellはrubyと比べてダメな言語。 http://d.hatena.ne.jp/mizon9/20111112/1321046483
0474デフォルトの名無しさん2011/11/12(土) 15:49:26.84
>>473
こういう総合的使い勝手に関して
関数型言語は時の洗礼を十分に勝ち抜いてはいないと思う
当面C#からF#を操作すればいいと思うしまだまだ本格使用はしない
0475デフォルトの名無しさん2011/11/12(土) 15:49:41.43
>>473
そこで挙げられてる事に関しては俺もそうだと思う。
回避策はあるにはあるけど、いつも使える訳じゃないし。
0476デフォルトの名無しさん2011/11/12(土) 15:57:09.17
>>473
名前空間の問題はasでimportすれば解決するんじゃ？
module が抽象化の単位だから module毎に名前空間を設定できればいいわけだし

操作とデータ型の分離はいわゆるexpression problemによくあるトレードオフそのもので
どっちがいいとかじゃないと思う
分離してmoduleで管理でいいと思うけど
class前提の人には受け付けないのか
0477デフォルトの名無しさん2011/11/12(土) 15:59:22.58
>>473
SMLならモジュールで名前空間を実現しているから
uri.schemeやuri.pathみたいに書けて、Rubyと遜色ない

Haskellって大規模開発には適していないのかな？
0478デフォルトの名無しさん2011/11/12(土) 16:07:36.78
Haskellわかってないやつが批判してるってのは理解できた
0479デフォルトの名無しさん2011/11/12(土) 16:19:42.77
名前についてHaskellよりRubyの方がうまくやってるのはその通りだな
qualifiedでインポートしても結局修飾しなきゃいけなくて、.fooで済むオブジェクト指向言語には負ける

それ以外の点は的外れだと思った
関数の部分適用とsetterはまるで別物だし、パターンマッチはかっこいいifじゃないし、
高階関数の「固まり」を苦労して扱わなくて済むのはそれだけで利点だし
0480デフォルトの名無しさん2011/11/12(土) 16:23:39.76
>>477
そのuri.schemeのuriってモジュール名？そうならRubyと遜色ないとは言えないだろ
Ruby(や他のオブジェクト指向言語)はモジュールで修飾する必要がないのが自慢なんだから
0481デフォルトの名無しさん2011/11/12(土) 16:24:46.65
>>477
バイナリ互換性が糞だからな
それが一番大問題だと思う

名前空間は一長一短だろ、エディタでの補完考えるとhaskellみたいに関数名で完結してたほうが良い
0482デフォルトの名無しさん2011/11/12(土) 16:27:49.15
補完は静的であれば何でもいけるんじゃないかと
0483デフォルトの名無しさん2011/11/12(土) 16:28:53.90
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
これがあれば短い名前を使って衝突しても解決してくれるという触れ込みだけどどうなんだろう
個人的には曖昧エラーの山になりそうだと思うんだが
SPJは使いものになると考えてるらしい
0484デフォルトの名無しさん2011/11/12(土) 17:07:16.80
>>480
SMLなら、open uri と宣言すれば、Rubyと同じように修飾を省略できるよ
Haskellはできないの？
0485デフォルトの名無しさん2011/11/12(土) 17:09:09.99
>>481
>名前空間は一長一短だろ、エディタでの補完考えるとhaskellみたいに関数名で完結してたほうが良い

まるでイソップ童話の「酸っぱいブドウ」みたいだ....
0486デフォルトの名無しさん2011/11/12(土) 17:11:25.72
>>484
できるけど、名前が衝突しない場合に限る。これはSMLも同じだよな？
Haskellで短かい名前を多用すると、けっこう頻繁に衝突して、けっきょく修飾インポートするはめになる
Rubyだとメソッド名はグローバルじゃないので衝突を気にする必要すらない
0487デフォルトの名無しさん2011/11/12(土) 17:16:42.29
>>486
>これはSMLも同じだよな？

いや、ゼンゼン(理由は下記を参照)

>Haskellで短かい名前を多用すると、けっこう頻繁に衝突して、

ナゼこんなことが起きるの？
SMLなら名前空間は(Rubyと同じように)階層化されているから、
適切にモジュール設計していれば、衝突なんて全く気にならないんだけど....

もしかしてHaskellの(モジュールに関する)名前空間というのは
フラット(平坦)なの？
0488デフォルトの名無しさん2011/11/12(土) 17:21:06.02
>>485
>>481は関数名しか補完してくれないテキストエディタしか使ったことが無いのかもしれない。
型を認識するIDEを使ったことがあれば、こんな発想にはならないだろ。
0489デフォルトの名無しさん2011/11/12(土) 17:23:06.27
>>487
Haskellの名前空間はフラットだよ
階層化されているから名前が衝突しないってのが良く分からん
実例かポインタある？

>SMLなら名前空間は(Rubyと同じように)階層化されているから、
Rubyで衝突を気にしなくていいのはメソッド名の解決に型情報を使う
(正確にはレシーバがメソッド名を実行時に解釈する)からであって、
階層化うんぬんは関係なくね？
0490デフォルトの名無しさん2011/11/12(土) 17:25:14.72
>>487
> もしかしてHaskellの(モジュールに関する)名前空間というのは
> フラット(平坦)なの？

どういうのをフラットと言うのか分からんが、
俺が Haskell のモジュール関係で不満なのは次のことができない事

AAA.BBB.CCC.DDD というモジュールがあったとして、
モジュール AAA.BBB をインポートして CCC.DDD.fff で関数 fff を使う事

関数 fff を使いたかったらモジュール AAA.BBB.CCC.DDD をインポートしないといけない
0491デフォルトの名無しさん2011/11/12(土) 17:36:29.05
すいません、Haskell初心者で
オライリーのプログラミング言語Haskellを買ってきたのです
プログラムをかきながら本を進めていくと
後半からimportできないモジュールばかりになるのですが…
環境はWindowsでGHC6.4.1ですが、CentOSでGHC6.10.4でもダメなので
単純に環境問題ではない気がするのですが…
0492デフォルトの名無しさん2011/11/12(土) 17:42:05.24
>>489
>実例かポインタある？

階層化されたディレクトリの無いファイルシステム(CP/Mや初期のMS-DOS)
過去の階層化されていないWindows Network(NetBIOS)

名前の衝突回避と階層化との関連はコンピュータ科学の知識があれば常識だよ

>階層化うんぬんは関係なくね？
Rubyのインスタンスメソッドについては、その通りだね。
ただし、Rubyにはクラスメソッドあるいはモジュール関数という概念がある。
これらのメソッドは(実際の実行は動的であっても、)構文上は静的に解釈できる。
ここで、M::N::O.func と M::N.func は同じモジュール関数名 func を使っているけど、
それぞれ名前空間が M::N::O と M::N とで異なっているから静的に区別できる。
0493デフォルトの名無しさん2011/11/12(土) 17:49:31.51
>>492
いやプログラミングの文脈ではぜんぜん常識じゃないと思うんだが

あるモジュールMを書いているとする
別のモジュールA.B.Cの関数fと、A.D.Eの関数fを使いたくなったので、両方ともインポートする
すると、単にfと書くだけではどちらを意味しているか決まらないので、なんらかの修飾が必要になる
これは名前空間が階層化されていようがいまいが関係ない

という理解だけど
0494デフォルトの名無しさん2011/11/12(土) 17:52:01.51
>>485,488
たしかに変なこと言っちゃったな
大規模開発云々で名前空間のrubyとhaskellでの差なんて大した問題じゃないってことが言いたかった
0495デフォルトの名無しさん2011/11/12(土) 18:05:45.44
>>493
修飾の無い名前 f だけじゃ区別がつかないのは、常識以前の当たり前な話だろ

>>493の例の場合、RubyやSMLならばモジュール空間Aだけをインポートして
B.C.f と D.E.f と書くことができる。あるいは、X=A.B.CおよびY=A.D.Eという
局所的なモジュール空間を宣言してX.f および Y.f という短い別名での参照が可能。

HaskellではAだけをインポートするとか、
あるいは局所的なモジュール空間を宣言するとかできないの？

RubyやSMLなら「普通に」できるんだけど....
0496 [―{}@{}@{}-] デフォルトの名無しさん2011/11/12(土) 18:08:18.90
>>495
>修飾の無い名前 f だけじゃ区別がつかないのは、常識以前の当たり前な話だろ
Rubyのインスタンスメソッドについてはそれができるんだよ。ずっとその話をしていたと思ったんだが

>HaskellではAだけをインポートするとか、
>あるいは局所的なモジュール空間を宣言するとかできないの？
できません
0497 [―{}@{}@{}-] デフォルトの名無しさん2011/11/12(土) 18:12:28.69
>局所的なモジュール空間を宣言してX.f および Y.f という短い別名での参照が可能。
これについては同様のことができるな。局所的なモジュール空間を宣言するわけじゃなくて
単なる別名の導入だけど

import qualified A.B.C as X
import qualified A.D.E as Y
0498デフォルトの名無しさん2011/11/12(土) 18:15:51.80
>>496
>Rubyのインスタンスメソッドについてはそれができるんだよ。

Rubyのインスタンスメソッドもレシーバで修飾しなければ区別できないよ。

たとえば
　c = A::B::C.new; e = A::D::E.new
という文脈の下で、レシーバで修飾された
　c.f および e.f
という式は正しく評価できるけど、単なる
　f
ではRuby処理形は式を評価できない。(当たり前の話だよね？)
0499 [―{}@{}@{}-] デフォルトの名無しさん2011/11/12(土) 18:22:34.43
>>498
もちろん。でもHaskellにはその能力がない
Rubyでuri.schemeと書くときにメソッド名schemeが他と衝突するのを心配する必要はないけど、
Haskellで(scheme uri)と書くならそうはいかない
これを指して>>486で「けっこう頻繁に衝突」と言った
>>487で否定されたのでSMLにもRubyみたいなレシーバ依存の名前lookupがあるのかと思ったけど、
そういう訳でもないってことで良いかな
0500デフォルトの名無しさん2011/11/12(土) 18:23:49.38
なんか一人すごい天然がいるなｗ
0501デフォルトの名無しさん2011/11/12(土) 18:36:14.30
お願い

感情に走らずに、もっと落ち着いて議論して
0502デフォルトの名無しさん2011/11/12(土) 18:39:16.82
>>499
>そういう訳でもないってことで良いかな

SMLはオブジェクト指向では無いし静的型付け言語だから、
Rubyのようなレシーバ(インスタンス)依存の名前参照は存在しない

ただし、SMLでは uri.scheme と書く時に、uri以外の他のモジュールで
schemeというアクセサ名が使われているかどうかを心配する必要はない
つまりHaskellのような urlScheme という冗長な命名は不要

こういう事で理解してもらえるかな？
0503 [―{}@{}@{}-] デフォルトの名無しさん2011/11/12(土) 18:51:56.84
>>502
>つまりHaskellのような urlScheme という冗長な命名は不要
Haskellでもこれは原理的には不要なんだよ
衝突が発生したら修飾した名前に切り替えればいいだけ
uriSchemeのような命名がされるのは修飾を面倒だと思っているから

これに関してHaskellでできないことをSMLができる訳じゃないと理解した
もちろん名前空間が階層化されてるのは良いことだけど、この話題には関係ない
0504 [―{}@{}@{}-] デフォルトの名無しさん2011/11/12(土) 18:54:26.76
あと、Haskellだってオブジェクト指向じゃないし静的型付けだけど、
レシーバ(に相当するもの)の型に依存して名前解決を行えるようにしようという提案があって、
それが>>483
0505デフォルトの名無しさん2011/11/12(土) 18:57:39.73
SMLとHaskellは同じ
Rubyは普通のOOPをやってる

新しい話題は無いわけね
0506デフォルトの名無しさん2011/11/12(土) 18:58:06.93
ようやく数セミにモナドの解説出たか。やっぱ京大スゲーわ。
0507デフォルトの名無しさん2011/11/12(土) 19:06:28.43
ここで出ている話題だと
コンパイル時に実装が選択できれば十分で
OOPの動的束縛を持ち出すのは道具が大きすぎな気がした
0508デフォルトの名無しさん2011/11/12(土) 22:08:46.75
僕ハスケルでOOPしたいです先生
0509デフォルトの名無しさん2011/11/12(土) 22:23:45.34
>>508
多相レコードを使え…あったっけ？
0510デフォルトの名無しさん2011/11/12(土) 23:01:33.64
>>508
どういうのをOOPと言ってるの？
何がどうできたらOOPと言っていいの？
0511デフォルトの名無しさん2011/11/13(日) 00:47:50.77
どんな言語でもまともなプログラムを作ろうと思うったらOOPしない方が難しい
0512デフォルトの名無しさん2011/11/13(日) 00:53:06.55
定義と思ってるものが各人違うから

http://ja.m.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
- カプセル化 (振る舞いの隠蔽とデータ隠蔽)
- インヘリタンス (継承) --クラスベースの言語
- ポリモフィズム (多態性、多相性) --型付きの言語
- ダイナミックバインディング (動的束縛) --インタープリタの言語 この機能

これらの機能のうち、オブジェクト指向の考え方で不可欠なのは「カプセル化」の機能だけである
0513デフォルトの名無しさん2011/11/13(日) 00:58:52.92
隠蔽かあ。あんまり良い定義とも思えないな
PythonとかOOPLでなくなってしまう
なんでこう日本語版のWikipediaは（略
0514デフォルトの名無しさん2011/11/13(日) 01:03:23.86
そう思うのなら翻訳よろしく
http://en.wikipedia.org/wiki/Object_Oriented_Programming
0515デフォルトの名無しさん2011/11/13(日) 01:16:28.24
やさしいHaskell入門 型クラスと多重定義
http://www.sampou.org/haskell/tutorial-j/classes.html
Haskell vs OOP
http://d.hatena.ne.jp/kazu-yamamoto/touch/20080828/1219888005
OOP vs type class
http://www.haskell.org/haskellwiki/OOP_vs_type_classes

↓こういう考えかたも、分かりやすいと思うんだけどな。
Clojureは、皆さんがオブジェクト指向から望む多くのものを提供 *して* います。
http://www.infoq.com/jp/news/2009/02/clojure-interview-halloway
0516デフォルトの名無しさん2011/11/13(日) 01:18:40.31
> ダイナミックバインディング (動的束縛) --インタープリタの言語 この機能
これ dynamic dispatch のことだよね
インタープリタの言語じゃなくてもあると思うんだけど
0517デフォルトの名無しさん2011/11/13(日) 01:20:07.80
オブジェクト指向といえば、こんなのも有るよ。
Perl5's Moose ロールベース？のオブジェクト指向
http://perldoc.perlassociation.org/pod/Moose-Doc-JA/Moose/Manual.html
0518デフォルトの名無しさん2011/11/13(日) 01:36:57.23
宣言的とのことなので、ロールじゃ無くてルールだった。

そういえば、動的型付け言語も動的ディスパッチする部分を型推論したり、
宣言する方向で高速化してるな。
0519デフォルトの名無しさん2011/11/13(日) 01:45:46.50
What is "Object-Oriented Programming?" [B. Stroustrup ECOOP '87] によれば
(subtype) polymorphismとADTの組み合わせだと言ってる
データ隠匿やデータ抽象だけならADTで可能だけど、これだけではOOPじゃない
0520デフォルトの名無しさん2011/11/13(日) 02:46:52.16
それは二つに分岐した一方のオブジェクト指向ではないかい？
0521デフォルトの名無しさん2011/11/13(日) 03:05:26.23
Haskellの型クラスとかインスタンスという用語は
OOPの用語と重なっているからまぎらわしい
もちろんHaskellの型クラスがOOPのクラスとは全く異なる概念であることは
調べればすぐに理解できることだけど、
いざHaskellのFPとOOPを対比させた説明を始めようとすると、
いちいち「Haskellのクラスは...」と「OOPのクラスは...」というように修飾が必要
0522デフォルトの名無しさん2011/11/13(日) 03:10:45.95
もう一つのオブジェクト指向のひとたちは、環境全体を考えるから分かりにくいね。
オブジェクト指向プログラミング：筋悪だったのか？
http://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang
0523デフォルトの名無しさん2011/11/13(日) 08:17:08.75
#Ruby の人でHaskellを勉強したいと思っている人はけっこういる。
Haskellの人でRubyに興味がある人はあんまりいない。
両方使えるならHaskell使うだろ。
つまりそういうことだ。

ちなみにRubyはListをmapしたらArrayになる。こんなのをほったらかし
たままで新しい構文がどうのこうの言っている。Rubyはオワコン
0524デフォルトの名無しさん2011/11/13(日) 08:42:40.27
>>506
は？京大なんて傲慢レポート何位だと思ってんだよ？
0525デフォルトの名無しさん2011/11/13(日) 09:05:28.47
>>523
> ちなみにRubyはListをmapしたらArrayになる。
どゆこと？
0526デフォルトの名無しさん2011/11/13(日) 09:15:34.66
言葉通りの意味だろ
0527デフォルトの名無しさん2011/11/13(日) 09:26:08.75
いやだってRubyにListってクラスは（多分）無いし、
Listと同じように扱えてmapを呼べるArrayはmapしてもArrayを返す

rb> a1 = [1, 2, 3]
=> [1, 2, 3]
rb> a1.class
=> Array
rb> a2 = a1.map{|e| e * 2 }
=> [2, 4, 6]
rb> a2.class
=> Array

なのでもう少し説明が欲しい
0528デフォルトの名無しさん2011/11/13(日) 09:26:50.55
トートロジー
0529デフォルトの名無しさん2011/11/13(日) 09:45:49.75
イテレータであるEnumerableから実際のコンテナにアクセスするとかそういう意味ならばまだ分かったんだけどなぁ>rubyのmap
0530デフォルトの名無しさん2011/11/13(日) 10:27:18.52
>>523
そもそもRubyは関数型言語ではないんだよね
関数風の(=関数型言語スタイルの)プログラミングも可能だというだけで....
厳しく言えば、Rubyでは関数(メソッド)はファーストクラスじゃないし、
末尾再帰も最適化されないからすぐにスタックオーバーフローする

自分達の優位な土俵で下位レベルの言語をつかまえて、
自身の優越感に浸るとは、なんともはや心の狭い発想じゃないのかと思われ
そんなにもHaskellという言語に対して自信が無いの？
もっと胸を張ってもいいと思うんだけどなあ....
0531デフォルトの名無しさん2011/11/13(日) 10:33:02.71
その点トッポって凄いよな
末尾までちゃんとチョコが再帰してる
0532デフォルトの名無しさん2011/11/14(月) 04:23:49.84
>>530
>>473のどこから優越感が云々という話になるのか分からんのだが

Rubyは言語仕様を読むとけっこう滅茶苦茶、細部をつつくと大変な事になる言語だが
一方で、言語仕様の「良さ」で支持されてきた言語でもある
悪い意味じゃなくてHaskellとは対照的な感覚があると思うけど
0533デフォルトの名無しさん2011/11/14(月) 08:04:23.97
>>532
どこから473が出てきたのか分からんのだが
523は俺が読んでも酷いレスに思える
0534デフォルトの名無しさん2011/11/14(月) 16:30:43.08
そろそろ純粋関数型とそうじゃないやつは分けて話そうぜ
Lisp対Haskell並に不毛な議論
最強を決めたいなら、とりあえずラムダ計算にしとけばいいよ
0535デフォルトの名無しさん2011/11/14(月) 16:46:43.11
ラムダ計算vs型付きラムダ計算
0536デフォルトの名無しさん2011/11/14(月) 16:54:16.83
Typed Pi-CalculusとTyped Join Calculusも虎視眈々と最強を狙ってる。
0537デフォルトの名無しさん2011/11/14(月) 18:34:22.14
まーちんれふでも意味分からんのにホモとピーとか有向型理論とかどんどんでてきてついていけせんねん
0538デフォルトの名無しさん2011/11/14(月) 18:43:45.63
君たちがなんかやっても、外人Haskell使いのほうが詳しいし
何でHaskellやるの?教えて？？？
0539デフォルトの名無しさん2011/11/14(月) 18:56:08.83
釈迦の教えに通じるから
0540やんやん ◆yanyan72E. 2011/11/14(月) 21:07:35.07
Haskellは現代数学をWikipediaで勉強するレベルの人間が
粋がって数学用語を多用するのがなんか鼻に付く。
0541デフォルトの名無しさん2011/11/14(月) 21:10:21.00
にわかほど語りたがる -- あるハッカー
0542デフォルトの名無しさん2011/11/14(月) 21:18:39.79
>>538
単純に楽しいから・・・かな
なぜか組み込み関数と同じもの自分で定義したり、＋演算子と同じ機能定義しようとして数学の世界に片っぽ足を突っ込んで「おお！！これ、数学スレやLispスレで見たぞ！！大学数学を高卒なのに解いてる!!」とか、そんなことに興奮してるけど…
0543デフォルトの名無しさん2011/11/14(月) 21:34:31.55
証明するより、プログラムのが楽しいというのもあるし、、、
0544デフォルトの名無しさん2011/11/14(月) 21:40:08.83
>>543
証明するつもりなかったんだけどね…
単に＋演算子と同じもの作りたかっただけだったのに、自然数から定義しなおす羽目になって、それがHaskellで動くもんだから、興奮しちゃうという…
0545デフォルトの名無しさん2011/11/14(月) 22:04:22.81
Yampa を調べているのですが、意味が分からない部分があります

dpSwitch 関数が第1引数として適用する関数
forall sf . (a -> col sf -> col (b, sf))
これの sf はこの関数においてどのような役割を果たすのでしょうか
■ このスレッドは過去ログ倉庫に格納されています