[過去ログ] 関数型プログラミング言語Haskell Part16 (978レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
463: 2011/11/11(金)00:32 AAS
>>462
絡むんじゃなくて、こうだから、間違いって指摘しろよ
時間の無駄
464: 2011/11/11(金)00:42 AAS
それこそ
beki n = beki' n 2
465: 2011/11/11(金)00:47 AAS
書き損じ・・・
それこそ
beki n = beki' n 2
where
beki'::double->Int->double
beki' n m = n^m
なら、ちゃんとn^2そのものを書く前に2の型も決められるしな
(さすがに、こんな反論もどうかと思うが)
466: 2011/11/11(金)00:49 AAS
要するに型を書けば解決する話。
先に書くか後で書くかは無関係ですな。
467(1): 2011/11/11(金)03:36 AAS
c言語でのint (*)[4]型っぽいものをhaskell的に表現する場合、
* = Pointer, [] = Array4, int = Intと置き換えて、
Pointer (Array4 Int Int Int Int)とでも書けるんだろうけれど、
int (*)[100]型とかになってくるととても書いていられない。
何か上手い方法はないだろうか。
用途ねーだろって突込みは無しで。
468: 2011/11/11(金)08:48 AAS
>>467
コード生成じゃ駄目?
469: 2011/11/11(金)08:49 AAS
Data.Arrayってそういうのじゃないの?使ったことないけど。
470: 2011/11/12(土)01:01 AAS
reactive-glutを試そうとしたら依存パッケージのcategory-extrasがインストールできなかった。
out of dateなパッケージかどうかすぐに分かる手段ってあるのかな。
471(1): 2011/11/12(土)08:11 AAS
ListはもうEducationalモジュールに引っ越せ
472: 2011/11/12(土)12:18 AAS
>>471
引っ越したとして、代わりに何を標準ライブラリに入れるの?
今までの List と互換が無ければ今まで作ってきた資産が死ぬし、
さもなければ互換性を捨ててでも入れる大きなメリットがあるものじゃないと
473(5): 2011/11/12(土)15:32 AAS
haskellはrubyと比べてダメな言語。 外部リンク:d.hatena.ne.jp
474: 2011/11/12(土)15:49 AAS
>>473
こういう総合的使い勝手に関して
関数型言語は時の洗礼を十分に勝ち抜いてはいないと思う
当面C#からF#を操作すればいいと思うしまだまだ本格使用はしない
475: 2011/11/12(土)15:49 AAS
>>473
そこで挙げられてる事に関しては俺もそうだと思う。
回避策はあるにはあるけど、いつも使える訳じゃないし。
476: 2011/11/12(土)15:57 AAS
>>473
名前空間の問題はasでimportすれば解決するんじゃ?
module が抽象化の単位だから module毎に名前空間を設定できればいいわけだし
操作とデータ型の分離はいわゆるexpression problemによくあるトレードオフそのもので
どっちがいいとかじゃないと思う
分離してmoduleで管理でいいと思うけど
class前提の人には受け付けないのか
477(2): 2011/11/12(土)15:59 AAS
>>473
SMLならモジュールで名前空間を実現しているから
uri.schemeやuri.pathみたいに書けて、Rubyと遜色ない
Haskellって大規模開発には適していないのかな?
478: 2011/11/12(土)16:07 AAS
Haskellわかってないやつが批判してるってのは理解できた
479: 2011/11/12(土)16:19 AAS
名前についてHaskellよりRubyの方がうまくやってるのはその通りだな
qualifiedでインポートしても結局修飾しなきゃいけなくて、.fooで済むオブジェクト指向言語には負ける
それ以外の点は的外れだと思った
関数の部分適用とsetterはまるで別物だし、パターンマッチはかっこいいifじゃないし、
高階関数の「固まり」を苦労して扱わなくて済むのはそれだけで利点だし
480(1): 2011/11/12(土)16:23 AAS
>>477
そのuri.schemeのuriってモジュール名?そうならRubyと遜色ないとは言えないだろ
Ruby(や他のオブジェクト指向言語)はモジュールで修飾する必要がないのが自慢なんだから
481(2): 2011/11/12(土)16:24 AAS
>>477
バイナリ互換性が糞だからな
それが一番大問題だと思う
名前空間は一長一短だろ、エディタでの補完考えるとhaskellみたいに関数名で完結してたほうが良い
482: 2011/11/12(土)16:27 AAS
補完は静的であれば何でもいけるんじゃないかと
483(1): 2011/11/12(土)16:28 AAS
外部リンク:hackage.haskell.org
これがあれば短い名前を使って衝突しても解決してくれるという触れ込みだけどどうなんだろう
個人的には曖昧エラーの山になりそうだと思うんだが
SPJは使いものになると考えてるらしい
484(1): 2011/11/12(土)17:07 AAS
>>480
SMLなら、open uri と宣言すれば、Rubyと同じように修飾を省略できるよ
Haskellはできないの?
485(2): 2011/11/12(土)17:09 AAS
>>481
>名前空間は一長一短だろ、エディタでの補完考えるとhaskellみたいに関数名で完結してたほうが良い
まるでイソップ童話の「酸っぱいブドウ」みたいだ....
486(2): 2011/11/12(土)17:11 AAS
>>484
できるけど、名前が衝突しない場合に限る。これはSMLも同じだよな?
Haskellで短かい名前を多用すると、けっこう頻繁に衝突して、けっきょく修飾インポートするはめになる
Rubyだとメソッド名はグローバルじゃないので衝突を気にする必要すらない
487(3): 2011/11/12(土)17:16 AAS
>>486
>これはSMLも同じだよな?
いや、ゼンゼン(理由は下記を参照)
>Haskellで短かい名前を多用すると、けっこう頻繁に衝突して、
ナゼこんなことが起きるの?
SMLなら名前空間は(Rubyと同じように)階層化されているから、
適切にモジュール設計していれば、衝突なんて全く気にならないんだけど....
もしかしてHaskellの(モジュールに関する)名前空間というのは
フラット(平坦)なの?
488(1): 2011/11/12(土)17:21 AAS
>>485
>>481は関数名しか補完してくれないテキストエディタしか使ったことが無いのかもしれない。
型を認識するIDEを使ったことがあれば、こんな発想にはならないだろ。
489(1): 2011/11/12(土)17:23 AAS
>>487
Haskellの名前空間はフラットだよ
階層化されているから名前が衝突しないってのが良く分からん
実例かポインタある?
>SMLなら名前空間は(Rubyと同じように)階層化されているから、
Rubyで衝突を気にしなくていいのはメソッド名の解決に型情報を使う
(正確にはレシーバがメソッド名を実行時に解釈する)からであって、
階層化うんぬんは関係なくね?
490: 2011/11/12(土)17:25 AAS
>>487
> もしかしてHaskellの(モジュールに関する)名前空間というのは
> フラット(平坦)なの?
どういうのをフラットと言うのか分からんが、
俺が Haskell のモジュール関係で不満なのは次のことができない事
AAA.BBB.CCC.DDD というモジュールがあったとして、
モジュール AAA.BBB をインポートして CCC.DDD.fff で関数 fff を使う事
関数 fff を使いたかったらモジュール AAA.BBB.CCC.DDD をインポートしないといけない
491: 2011/11/12(土)17:36 AAS
すいません、Haskell初心者で
オライリーのプログラミング言語Haskellを買ってきたのです
プログラムをかきながら本を進めていくと
後半からimportできないモジュールばかりになるのですが…
環境はWindowsでGHC6.4.1ですが、CentOSでGHC6.10.4でもダメなので
単純に環境問題ではない気がするのですが…
492(1): 2011/11/12(土)17:42 AAS
>>489
>実例かポインタある?
階層化されたディレクトリの無いファイルシステム(CP/Mや初期のMS-DOS)
過去の階層化されていないWindows Network(NetBIOS)
名前の衝突回避と階層化との関連はコンピュータ科学の知識があれば常識だよ
>階層化うんぬんは関係なくね?
Rubyのインスタンスメソッドについては、その通りだね。
ただし、Rubyにはクラスメソッドあるいはモジュール関数という概念がある。
これらのメソッドは(実際の実行は動的であっても、)構文上は静的に解釈できる。
ここで、M::N::O.func と M::N.func は同じモジュール関数名 func を使っているけど、
それぞれ名前空間が M::N::O と M::N とで異なっているから静的に区別できる。
上下前次1-新書関写板覧索設栞歴
あと 486 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ
ぬこの手 ぬこTOP 0.017s