- 1 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 14:49:54 ]
- 関数型言語MLについて語るスレッドです。
MLは、確固とした理論的背景を持つ言語でありながら、
現実的なソフトの開発にも使用できる実用性を備えた言語です。
また、プログラミングの初心者が最初に学習する言語としても優れています。
総本山
Standard ML www.smlnj.org/
Objective Caml caml.inria.fr/ocaml/
前スレ
関数型言語ML(SML, OCaml, etc.), Part 4
pc11.2ch.net/test/read.cgi/tech/1133003340/
- 24 名前：デフォルトの名無しさん mailto:sage [2007/09/25(火) 21:37:29 ]
- OCamlでSTMできるライブラリが登場してまっせー
cothreads.sourceforge.net/
- 25 名前：デフォルトの名無しさん mailto:sage [2007/09/27(木) 11:50:09 ]
- λってなに？って聞かれたらなんて答えればいいの
- 26 名前：デフォルトの名無しさん mailto:sage [2007/09/27(木) 13:04:40 ]
- 関数です、と。
でもプロシージャではありません、とでもいっておく。
- 27 名前：デフォルトの名無しさん mailto:sage [2007/10/01(月) 02:47:24 ]
- 前に、どっかのスレで lambdaの由来を読んでから、
λって言葉に対する、引っかかりがなくなったというか
λって言葉に対して、意味を求めなくなった。
>λってなに？
ギリシャ文字を記号として使っている。
何を表す記号かというと、次の人が答えてくれる。
(私が、頓珍漢な事を書いてるのでなければ)
- 28 名前：デフォルトの名無しさん mailto:sage [2007/10/01(月) 07:53:20 ]
- Calandar モジュールってあるじゃん
あれで今日の日付を取得すると、月がまだ９月なんだよね
だれか英語で切る人、報告してやってくれないか
俺は無理
- 29 名前：デフォルトの名無しさん mailto:sage [2007/10/01(月) 07:56:24 ]
- Ｔｉｍｅｚｏｎｅのセット間違いだったよ、ゴメン
- 30 名前：デフォルトの名無しさん mailto:sage [2007/10/05(金) 15:43:24 ]
- 久しぶりにocamlのuser's manualを眺めてた。そんな事もできるのかーという構文発見。
其の1 ローカルモジュール
#let module A = struct let add x = x + 1 end in A.add 3;;
- : int = 4
其の2 開いて閉じる
#type t = [ `A of int | `B of bool];;
type t = [ `A of int | `B of bool ]
# type u = private [< t > `A];;
type u = private [< t > `A ]
private row応用範囲広すぎ。
- 31 名前：デフォルトの名無しさん [2007/10/06(土) 16:01:07 ]
- えらいひとに質問です。
let f = function `A -> () | `B -> ();;
let g = function `C -> () | `D -> ();;
があったときに、これら2つを使って、「パターンマッチを使わず」に
h : [<`A|`B|`C|`D] -> ()
を合成する方法はありますか？
めっちゃ頭を絞ったんですが分からないのです。
何がやりたいのかというと、polymorphic variantを引数に取る任意の2つの関数を、
うまいこと合成したいのです。
- 32 名前：31 [2007/10/06(土) 16:07:01 ]
- あ、もちろん、`A,`B,`C,`Dを直接パターンマッチするのでなければ、match構文やfunction構文は使っても良いです。
そのような関数の型はどうなるのかを考えるために、ためしに、
let comp : (('a -> unit) -> (g:'b->unit) -> (['a|'b] -> unit)) = ();;
というのを考えてみましたが、['a|'b] のところで、
The type 'a is not a polymorphic variant type
と怒られてしまいます…
>>30みたいなことができたら良かったんですけどね。
- 33 名前：デフォルトの名無しさん mailto:sage [2007/10/06(土) 17:36:35 ]
- パターンマッチの合成かー、私も一度悩んだことあるなー。
その時の結論は結局「無理」。fやgの引数に取る多相バリアントが閉じてなければ、
#let ($+) f g x =
try g x with Match_failure -> f x;;
val ( $+ ) : ('a -> 'b) -> ('a -> 'b) -> 'a -> 'b = <fun>
#f $+ g;;
- : _[> `A | `B | `C | `D ] -> unit = <fun>
で合成できるけど、せっかくの型安全が台無し。
えらいひと回答plz.
- 34 名前：31 mailto:sage [2007/10/07(日) 00:33:08 ]
- おぉっ、なるほど。確かにそれっぽくなってますね。ありがとうございます。
あの後、似たようなことをやろうとしてダメだったんですが、よく考えたら[<`A|`B]->unitのようにclosedになってた気がします。
ただおっしゃる通り、f $+ gに`A..`D以外のバリアントが来た時に、g側がMatch_failureを投げてくれる関数でないとfが動いてくれないし、
f側はf側で想定外のバリアントをどうハンドリングするのかが問題っすね。
curry-howard的には、
((AまたはBならばX) かつ (CまたはDならばX)) ならば ((Aまたは...またはD) ならば X)
なので、そういう関数があっても良さそうなもんですが、
問題が多相バリアントなのでよくわからんです。
助けてえらいひと…
- 35 名前：デフォルトの名無しさん [2007/10/07(日) 02:05:42 ]
- >>30
其の1を上手く使った例としてp4ckのpa_openinを挙げておく。
便利。
- 36 名前：デフォルトの名無しさん mailto:sage [2007/10/07(日) 04:51:57 ]
- P4ckのpa_openinとpa_recordsくらいはそろそろ標準の構文に入れて欲しい。
- 37 名前：デフォルトの名無しさん mailto:sage [2007/10/11(木) 00:01:52 ]
- 第15回 型からプログラムを当てる
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20071005/283903/?ST=develop
連載も既に15回を数え、そろそろ仕事方面に走り出している件について。
- 38 名前：デフォルトの名無しさん mailto:sage [2007/10/11(木) 02:17:37 ]
- この人floatを浮動小数と書くけど、正しくは浮動小数点数じゃないのかな?
何が固定か浮動かっていうと小数点がだよね。
- 39 名前：デフォルトの名無しさん mailto:sage [2007/10/11(木) 02:26:10 ]
- 口語と文語だとでも思っておけば……
あっ、文章を書いてるんだっけｗ
- 40 名前：デフォルトの名無しさん mailto:sage [2007/10/11(木) 11:13:42 ]
- >>37
これのどこが「数理科学的バグ撲滅方法論」なの？
- 41 名前：デフォルトの名無しさん mailto:sage [2007/10/12(金) 02:24:58 ]
- Job Announcement
ttp://groups.google.com/group/fa.caml/browse_thread/thread/eeb092296dc09468/b088e1f1c3db1b45
あのJane Streetが東京オフィスでOCamlハッカーを募集している！10月3日のメールだ！
我こそはという人材はいまがチャンスだ！！
（あぁ、私がもう10才若ければ……）
- 42 名前：デフォルトの名無しさん mailto:sage [2007/10/12(金) 23:01:48 ]
- 誰？
- 43 名前：デフォルトの名無しさん [2007/10/14(日) 12:37:47 ]
- 既出かもしれんけど
開発環境WideStudio/MWT
www.widestudio.org/ja/
C++, Java, Perl, Python, Rubyのほかに…
OCamlも使える(3.09-2以降)らしい。ちょっと驚き。
- 44 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 21:35:57 ]
- OCamlerが主要開発者だから普通だろ
- 45 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 00:47:52 ]
- しらんがな
- 46 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 01:56:40 ]
- Java の Scripting API で、OCaml が使える。
OCamlScripting
ocamlscripting.x9c.fr/
- 47 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 18:19:21 ]
- そういう紹介だけ、とかありがたくもないし、ＭＬ見てたら誰でも知ってることなんだよね
いい加減うざい
使ってみたら～だった、ぐらいまで踏み込んでるならまだしも。
- 48 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 21:49:42 ]
- >>47
こういうハイレベルな人が「人こねえええ 」を招くんだろうね。
私は紹介だけでも十分うれしいですよ。
- 49 名前：デフォルトの名無しさん [2007/10/17(水) 23:00:50 ]
- >>40
別にバグを撲滅させようとしてるわけじゃない
研究さえできりゃそれでいいっていうスタンスだからな
- 50 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 13:02:16 ]
- >>48
むしろそんなハイレベルな人が2chを見ていることに驚くわけだが
MLとかいちいち粘着に全部読んでないし。
- 51 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 13:06:30 ]
- つーかどんだけ偏狭なんだと
- 52 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 20:09:23 ]
- caml.inria.fr/cgi-bin/hump.en.cgi?contrib=592
- 53 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 22:44:11 ]
- preprocessor-pretty-printer-puricure
- 54 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 18:35:26 ]
- www.amazon.co.jp/dp/4774132640
- 55 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 19:36:46 ]
- あああいつもrecを書き忘れる
- 56 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 19:38:07 ]
- なんでrecなんてかかなきゃいけないんだy
- 57 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 23:30:30 ]
- マジレス。
let f x=x in let f x=f x+1 in f 0
とかが書けてしまうので、OCamlのプログラムなので、let recと明示的に再帰していると言ってやらなきゃならんのでは。
Haskellだとこうはならんすよね
- 58 名前：55 mailto:sage [2007/11/10(土) 02:37:55 ]
- >57 ありがとうございます。
ちょっと取り乱しました
- 59 名前：デフォルトの名無しさん mailto:sage [2007/11/11(日) 11:01:35 ]
- MLでも今のletとlet recの仕様を入れ替えれば、こんな面倒はなくなる。
その場合let recだと変だから、let outerくらいにすればよい（どうせほとんど使われない）。
- 60 名前：デフォルトの名無しさん mailto:sage [2007/11/12(月) 22:53:05 ]
- SMLでは再帰関数定義にはval recとfunが使えます。
- 61 名前：デフォルトの名無しさん mailto:sage [2007/11/12(月) 23:46:56 ]
- このスレではOcaml派：SML派はどんくらいなんだろうな。
まぁOcaml派8割越えなんだろうけどな...
- 62 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 00:18:01 ]
- SML は良い実装が無いから…
- 63 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 09:08:14 ]
- SML#に期待
- 64 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 19:42:13 ]
- Native Thread 使えないから期待出来ないよ
何で日本の言語屋さんってハードウェアのトレンドを理解してないんだろう…
並列化は OS の仕事だとか言ってる人も居るし…
- 65 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 21:10:47 ]
- 何でハードウェア屋さんって言語のトレンドを理解してないんだろう…
- 66 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 21:15:29 ]
- >>65
それは実状と異なるからナンセンス。
- 67 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 22:57:16 ]
- 何で言語屋さんとハードウェア屋さんって、コミュニケーションを取らないんだろう…
情報交換はOS屋の仕事だとか言ってる人も居るし…
- 68 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 23:06:28 ]
- それ日本だけだから日本発の処理系以外は大丈夫
- 69 名前：デフォルトの名無しさん mailto:sage [2007/11/14(水) 02:35:21 ]
- こうして実用環境はすべてC言語
（およびC言語上に構築された動的言語（笑））
とUNIXから逃れられないのでした。完。
- 70 名前：デフォルトの名無しさん mailto:sage [2007/11/14(水) 05:50:33 ]
- まあでもJoCamlがErlangより速いって結果もあるし、こういう型付きコンパイルによる効率向上とCより格段に高い信頼性からいって、OCamlもけっこう捨てたもんじゃないとおもうよ
eigenclass.org/hiki/wide-finder-conclusions
- 71 名前：デフォルトの名無しさん mailto:sage [2007/11/22(木) 22:30:33 ]
- Microsoftの新プログラミング言語「F＃」，Visual Studioへの搭載目指す
ttp://itpro.nikkeibp.co.jp/article/NEWS/20071023/285185/
>「ML」という初期の関数型プログラミング言語をベースに，
>プログラミング言語「C＃」や「Haskell」，リレーショナ
>ル・データベース操作技術「LINQ」の要素を含んでいる。
ITProよ。そこはどう譲ってもHaskellじゃなくて、OCamlだろっ！！
- 72 名前：デフォルトの名無しさん mailto:sage [2007/11/22(木) 22:35:30 ]
- 遅延評価とか Haskell 的なものって無いよねぇ確か F# に
- 73 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:06:06 ]
- >>64
頭古すぎw
- 74 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:32:03 ]
- >>73
並列化は OS の仕事だというのが?
確かに時代錯誤的だよね
- 75 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:39:12 ]
- ハードウェアに特化しすぎた奴は全部死滅しただろ。
トランスピュータ＋オッカムとか、コネクションマシン２＋C*/*Lispあたり。
求められているのはハードウェアにベッタリしすぎない抽象化されたモデル。
- 76 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:59:15 ]
- >>75
抽象化自体は良いよ。ただ、ハードの資源を使い切れない様な抽象化では
意味が薄い。ハードの制約を無視した抽象化は単なる机上の空論だよね。
何年も前からトランジスタ数の増大に比較して CPU の性能が伸びない事、
CPU の速度向上に Memory が付いて来れない事が問題になっている。
現状としては業界を上げてマルチコア、メニーコア、ハードウェアマルチ
スレッディングに移行している。途中で VLIW みたいな寄り道もしたけど、
現在製造されているプロセッサの多くが既にマルチコアに意向済み。
そんな中で、いかにスレッドを簡単に扱えるか、スケーリングする GC を
実装出来るかは言語の設計と処理系の実装には結構重要なポイントで、
テーマとしては新規性はあまり無いかもしれないけど、逆に言えば本来
あって当たり前の機能なんだよね。自動並列化とか CAS とかも。
まあ最低限、ネイティブスレッドくらいは扱える様な処理系があると良いね。
- 77 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:05:21 ]
- ネイティブ・スレッドって結論が馬鹿すぎる。
それから関数型言語と並列化の文献は山のようになるので、
英語でもちゃんと読んでやってください。
- 78 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:08:03 ]
- >>77
それを馬鹿だという奴は現実が見えてないだけだよ。
並列化の研究が沢山あるのは知ってるよ。じゃあどれだけの
実装が残ったのかという話。
- 79 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:10:04 ]
- 今後のハード技術は
スレッドが使いづらい方向に行くと思うぞ
- 80 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:10:48 ]
- 有益でないから残らない。
関数型言語はErlangなど残っている方。
- 81 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:14:30 ]
- >>79
どちらかというとスレッドが無いとやってられない方向へ向かってる
- 82 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:18:45 ]
- 有益でない言語は残らない。
- 83 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:24:09 ]
- つまりMSにとって有益な言語が残るってことだな
- 84 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:33:41 ]
- Haskell は STM とか頑張っているんだがのう
SML はダメッポス
- 85 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 16:14:00 ]
- STM?
- 86 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 16:18:31 ]
- >>84
haskell.g.hatena.ne.jp/jmk/20061219/1166519293
元の処理系に並列化の基盤が無いと、
こういう実験にも使えないのよね
- 87 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 16:46:40 ]
- 間違えた。>>86 は >>85 向け。
- 88 名前：85 mailto:sage [2007/11/23(金) 16:59:39 ]
- さんきゅう
- 89 名前：79 mailto:sage [2007/11/23(金) 18:29:22 ]
- スレッドが使いづらい方向に行くっていう意見は、たぶん俺がハード屋で
性能/消費電力/発熱に苦しんでるからかも。
SMPコアには既に限界を感じてる。
ASMPコアで無駄な回路を減らせば、まだまだ上を狙える。
遅延評価・非同期実行（イベント同期）をナチュラルに行なえる言語だと
ハード・ソフトの両面からグッと最適化が効く。
スレッドはSMPと相性がいいかもしれんが、
でもASMPにはマッチしないと思う。
- 90 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 18:32:00 ]
- スレッド←→遅延評価・非同期実行（イベント同期）
って反対概念でもないよね?
- 91 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 18:39:20 ]
- >>89
ASMP でも汎用コアが複数あったり、SMP と言っても特殊用途の
コプロ積んでたりするもんじゃないの?
どう転んでもスレッドの重要性は当分は覆らないと思うけどなあ。
- 92 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 22:38:05 ]
- >>90
確かに。お互いに実現可能なものを持ってるしね。
スレッドはハード層にCPUとしての機能と性能を要求してくるけど、
本当にそんなに大げさな物が必要なのかなーって思ってる。
OS層にはマルチタスク要求があるからスレッドは有益だけどさ。
アプリ層でスレッドを使うときって、
・CPU複数使って速く処理する
・ブロッキング処理を非ブロッキング処理にする
こういうのを言語がサポートしてないからじゃない？
（ライブラリじゃなくて言語仕様ね）
それにスレッドっていうキーワードを使って作られたものって、
DSP,SIMD,コプロ等々の存在を無視する気がする。
┌─────────────┐
│ 関数 ｜
├───┐ ｜
｜ ｽﾚｯﾄﾞ ｜ ｜
├───┴─┬───────┤
｜ CPU ｜DSP,SIMD,コプロ｜
└─────┴───────┘
言語にはネイティブスレッドを要求するより
こんなものの→（Scatter/Gather、Map/Reduce、遅延評価、イベント同期）
シームレスでポータビリティな仕様と、実装の最適化を要求して欲しい。
- 93 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 23:05:28 ]
- >>92
結局 CPU 複数使って速く処理するにはスレッドが必要なんだぜ。
何でそんなにスレッドを嫌がるのかは知らんけど、現実には
コプロや SIMD があってもスレッドは必須だよ。
- 94 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 23:27:35 ]
- 話がかみ合ってないな
- 95 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 23:38:17 ]
- はぐらかしてるだけに見えるけど
- 96 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 00:04:53 ]
- ＞CPU 複数使って速く処理するにはスレッドが必要
違う。
手続き言語andスレッド によって速い処理を行おうとするから
複数のCPUを要求されている。
でもスレッドじゃ
DSP,SIMD,コプロ
この辺をうまく使っていけない。
極論だけど、関数言語がソフトウェアの主流なら
クロックを使わない論理回路で作ったチップにも需要が出るから
そういうのも作るもん。
- 97 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 00:15:20 ]
- >>96
違うっていうけどさ、元々違う話をしてるんだから当たり前だよ。
俺は現実世界にある CPU をどう有効に使えるかにしか興味無いよ。
そしてその為にはスレッドを使うのが一番の近道。
それにスレッドと SIMD やコプロは排他的な存在じゃないから。
- 98 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 00:35:01 ]
- >>96
>手続き言語andスレッドによって速い処理を行おうとするから
>複数のCPUを要求されている。
これは違うよな。プログラマはスレッドなんて別に使いたくない。
シングルコアで高性能の CPU が作れないっていうから、仕方なく
ソフトウェアを並列化してるだけ。DSP も一緒。
- 99 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 00:47:23 ]
- 各CPUにコードをロードさせておいてから、
データばらまいて、関数に突っ込んで、出力を集計すればいいじゃん。
ってこれはMap/Reduceだよな。
- 100 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 01:04:45 ]
- 何だよ、素人か。
- 101 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 23:28:42 ]
- 言語はマルチスレッドをサポートすべき?
│
├CPUシングルスレッド性能は打ち止めだからこれからはマルチスレッドスレッドだよ
│├マルチスレッドをどうにかするのは言語の仕事だよ
││├とりあえずスレッドとロックサポートすればいいよね (古典派)
││├ロックしないよ (モダン派)
││├プロセスは言語の基本だよ (並列言語派)
│││└おっぱい おっぱい (ぱい計算ってうまいの?)
││└マルチスレッドは実装屋の仕事だよ
││
│├マルチスレッドをどうにかするのはOSの仕事だよ
││├1つのプロセス中では並列度上がらないよ
││└小さいプロセスいっぱい作るよ (forkできればそれでいい派)
││
│├CPUごとに仮想マシン割り当てるから問題無いよ
││
│└コプロの命令もメインプロセッサの命令に見せかけるからやっぱスレッドだよ (Intel)
│
├マルチスレッドよりも大切なものがあるよ
│├SMPは限界。処理ごとに回路作るよ
│├高性能処理はベクタマシンだろ。常考 (ベクタ派)
││└GPUを計算に利用しようぜ (新ベクタ派)
│├他マシンとの通信こそ重要だよ (クラスタ派)
│└機械語レベルでなんとかなるよ (スーパースカラ派・コードモーフィング派)
│
└並列こそ計算の本質だよ。データフローマシン最高 (逐次処理は諸悪の根源だよ派)
- 102 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 00:13:28 ]
- っあらゆるテクニックを使って速く動くように裏で最適化してよ（何も考えたくない派）
- 103 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 14:48:34 ]
- クラスタ以外は、下へ行けば行くほど現実解から遠ざかっているなw
- 104 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 20:21:12 ]
- ていうかアプリによってどれがいい違ってくるよね
- 105 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 20:24:02 ]
- アプリレベルじゃない話も混ざっているみたいだけど
例えば fork を使うと良いアプリってどんなの?
- 106 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 20:28:36 ]
- ネットワークサービス系はforkがいいと思う。
セキュリティを考えると、
同じプロセスで走らせたくない処理が多い。
- 107 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 20:45:54 ]
- ネットワークサービス系って一般的にはスレッドプールを作るイメージだけど、
具体的にはどんなアプリを想定してるの?
- 108 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 11:28:12 ]
- >>84
manticoreがあるでしょ > SML
>>101
> 言語はマルチスレッドをサポートすべき?
関数型言語の場合は、semanticsをどうするかが一番の論点で、
(関数型言語でなくていいことは、他の言語でやればいいし、実際行なわれている)
言語に並列処理能力を持たせるべきかどうかってのは、設問としておかしい。
持たせるとしたらどういう風なものがいいか、研究が行なわれ続けている。
- 109 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 12:02:18 ]
- >>108
＞関数型言語の場合は、semanticsをどうするかが一番の論点
そーそー、それそれ。
関数型言語にはそういう力があるんだから。
>>92の一番最後に書いたここの部分ね。
＞シームレスでポータビリティな仕様
CがUNIXの力になって
LLがWebアプリの力になったように
関数型言語が並列処理分野の力になると思うんだけど。
今のスレの流れって
なんだかWebアプリの話をしてるときに
C実装レイヤーのことを話してるみたいな気がする。
- 110 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 12:04:09 ]
- >>108
>関数型言語でなくていいことは、他の言語でやればいい
それはおかしいだろ。
例えばすごく関数型向きなアプリケーションを作ろうとしていて、
たまたま一ヶ所並列計算が必要だと分かったら、それだけで
関数型言語が選択肢から外れるってのは問題だと思わないか？
同じ論法で、汎用言語なら、良く使われる機構は一通りカバーしておくべき。
- 111 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 15:39:16 ]
- あなたが知らないだけです。
- 112 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 20:41:03 ]
- >>111
そういうのは例え 2ch でもどうかと思うよ。
manticore ってこれか。まだ実装は公開されてないのね。
manticore.cs.uchicago.edu/
- 113 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 22:17:20 ]
- >>86
それ、最初の方でoperaionalにSTMの意味を説明しているけど、
それはSTMの実装の一つを紹介している(ことになっている)だけで、
STMは必ずしもそういう実装になる必要はないので読む時には気をつけて。
TMはdatabaseやdistributed computingでよく使われるモデル。
並列処理抽象化のために、実装がいくつも考えられて、
モナド親和性の高いモデルを採用している。
- 114 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 14:11:41 ]
- CML(cml.cs.uchicago.edu/)とOCamlのThreadsライブラリの事もたまには思い出してあげてください。
- 115 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 20:54:51 ]
- CML って所謂 Green Thread だと思ってた
ちゃんと "Concurrent" に動くの?
- 116 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 08:03:00 ]
- スケジューラがユーザ空間に(も)ないと、
関数型言語っぽい面白いことができない。
CML→manticoreって人がいるね。
- 117 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 23:15:14 ]
- せっかく新生した JoCaml のことも思い出してあげてください
- 118 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 23:20:30 ]
- OCaml はもう良いじゃん...
- 119 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 23:29:28 ]
- >>114
coThreadライブラリ(cothreads.sourceforge.net/)は無視ですか、そうですか。
- 120 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 01:25:15 ]
- プログラミング in OCaml ~関数型プログラミングの基礎からGUI構築まで~
と
入門OCaml ~プログラミング基礎と実践理解~
どっちがいい？
- 121 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 11:09:15 ]
- 立ち読みして決めろ
- 122 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 00:27:53 ]
- お前らの感想を言え
- 123 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 13:42:43 ]
- >>122
昨日発売される本の即日レビューなんて 無茶いうな。
入門OCaml
必要なことは大体書いてあるので、基礎的なことは十分できるようになった。
短所としては、よくあることだけど、ちょっと複雑な機能を説明するときに
複雑な例で解説してる場所がある、とか。そのぶん実用例の確認にはいいんかな。
そういう部分は自分で簡単なもの作ってみて理解するしかない。
まだ勉強中だけどスレッドやらパーサやらCGIやらの使用例とかあるし
本格的に使うつもりなら買っといていいんじゃないっかな。
あとこの本が無ければSML#とか知らなかった。
- 124 名前：デフォルトの名無しさん mailto:sage [2007/12/01(土) 16:26:55 ]
- SML#の本、欲しい
|
 |
