[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/10 00:21 / Filesize : 224 KB / Number-of Response : 956
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

関数型言語ML(SML, OCaml, etc.), Part 5



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/

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 ]
ハードウェアに特化しすぎた奴は全部死滅しただろ。
トランスピュータ+オッカムとか、コネクションマシン2+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#の本、欲しい


125 名前:デフォルトの名無しさん mailto:sage [2007/12/01(土) 17:36:49 ]
>>116
>CML→manticoreって人がいるね。

manticoreってもう使えるの?

126 名前:デフォルトの名無しさん mailto:sage [2007/12/01(土) 20:45:42 ]
>>120
どちらかといえば、前者。



127 名前:デフォルトの名無しさん mailto:sage [2007/12/02(日) 00:09:43 ]
>>125
>>116は研究者/開発者

128 名前:デフォルトの名無しさん [2007/12/02(日) 01:04:45 ]
>>119
正直無駄にHaskell-STM風にモナド前提なのを何とかして欲しい。


129 名前:デフォルトの名無しさん mailto:sage [2007/12/02(日) 08:05:45 ]
無駄に?

130 名前:デフォルトの名無しさん mailto:sage [2007/12/02(日) 12:32:54 ]
Poly/ML が 5.1 でネイティブスレッドを使える様になっているね
polyml.5.1/libpolyml/processes.cpp 内で pthread 関連の関数を
呼び出しているみたい

Poly/ML を使っている人はこのスレには居ないかな...

131 名前:デフォルトの名無しさん mailto:sage [2007/12/02(日) 21:46:29 ]
使ってるよ。
自作のコードはStandard ML系の処理系のほとんどでひととおり動作チェックする。

132 名前:130 mailto:sage [2007/12/02(日) 22:23:23 ]
今日久々に Poly/ML 見てみたんだけど、結構進化してるよね。
イメージベースの環境から、オブジェクトファイルを吐いて
実行ファイルを生成出来る様に変わっているし、スレッドは
カーネルスレッドをサポートしているし、FFI は C の構造体
を扱えるし、Intel Mac も Solaris もサポートしているし、
あと欲しいのは UNICODE のサポートくらい。

Standard ML 処理系では最強なんじゃないかな。

133 名前:デフォルトの名無しさん mailto:sage [2007/12/03(月) 09:37:00 ]
誰かocaml-ssl ってのビルドできた人いますか(0.4.2)

ttp://sourceforge.net/project/showfiles.php?group_id=89802&package_id=106341

134 名前:デフォルトの名無しさん mailto:sage [2007/12/06(木) 00:06:44 ]
SML のソースコードを沢山読んでみたいのですが、
Perl でいう CPAN みたいなのはありませんか?

135 名前:デフォルトの名無しさん mailto:sage [2007/12/06(木) 08:34:33 ]
www.cs.princeton.edu/~appel/smlnj/projects.html

136 名前:デフォルトの名無しさん mailto:sage [2007/12/06(木) 09:02:46 ]
ありがとうございます!



137 名前:デフォルトの名無しさん mailto:sage [2007/12/07(金) 12:11:14 ]
>>2
>yk.i.hosei.ac.jp/smlbook/smlbook.pdf

だいぶ今更かもしれないけど、これ無くなってしまっているね。
欲しい人は今のうちに Web Archive から頂いておいた方が良いかも。

138 名前:デフォルトの名無しさん mailto:sage [2007/12/08(土) 02:59:37 ]
>133
Cygwin 上で特に patch なしでビルドできてるけど。何ぞ問題が?

139 名前:デフォルトの名無しさん mailto:sage [2007/12/08(土) 16:52:38 ]
過疎っているので、Python スレにあったお題でコードを書いてみました。
"行頭の空白文字列を nbsp に変更するプログラム"

fun replaceWhite file =
  let fun repLn lst =
        case hd lst of
          #" " => [#"&", #"n", #"b", #"s", #"p", #";"] @ repLn(tl lst)
        | #"¥t" => [#"&", #"n", #"b", #"s", #"p", #";",
                     #"&", #"n", #"b", #"s", #"p", #";",
                     #"&", #"n", #"b", #"s", #"p", #";",
                     #"&", #"n", #"b", #"s", #"p", #";"] @ repLn(tl lst)
        | _ => lst
      fun replace out =
        case TextIO.inputLine out of
          NONE => ()
        | SOME ln => ((print o String.implode o repLn o String.explode) ln;
                      replace out)
  in (replace o TextIO.openIn) file
  end;

140 名前:デフォルトの名無しさん mailto:sage [2007/12/08(土) 16:56:47 ]
もういっちょ。
"フィボナッチ数を 0 から 35 まで表示するプログラム"

fun fibloop () =
  let fun fib n = if n < 2 then n else fib(n-1) + fib(n-2)
      fun loop 36 = ()
        | loop cnt = (print(Int.toString(fib(cnt)) ^ "¥n");
                      loop (cnt + 1))
  in loop 0
  end;

141 名前:デフォルトの名無しさん mailto:sage [2007/12/08(土) 21:30:26 ]
次スレを立てる時は >>2 の SML の所にこれを追加して欲しいな
SML を勉強していて一番参考になった

www.geocities.jp/m_hiroi/func/index.html
sml.sourceforge.net/Basis/

142 名前:デフォルトの名無しさん mailto:sage [2007/12/08(土) 23:42:59 ]
>>137
旧研究室サーバにあった。
133.25.16.150/smlbook/smlbook.pdf

143 名前:デフォルトの名無しさん mailto:sage [2007/12/10(月) 00:42:45 ]
>>139
...正規表現のライブラリって無いのですか?
いくら静的型付けとはいえ、スクリプト系の言語に比べてかなり冗長で、
いまいちSMLを勉強する気にならないのですが...。



144 名前:デフォルトの名無しさん mailto:sage [2007/12/10(月) 03:21:09 ]
取り敢えず Moscow ML には正規表現ライブラリがバンドルされている
みたいだけど、他もあるんじゃないかな。正規表現を使わなくとも
Vector で書いたらコード量は大分少なくなると思う。

まあそんな事は誰でも簡単に調べられる事だし、勉強する気にならない
のであれば他の事をした方が良いと思うよ。自由ってそういう事でしょ。
面白いと思ってすぐに手を動かせる人間が自分で色々探求して行く一方で、
そうじゃない人がいても別に誰も強制したりなんかしない。

そもそも >>139 は SML を勉強し始めて一日目の人間が書いたコード
だから参考にしない方が良いでしょう…

145 名前:デフォルトの名無しさん mailto:sage [2007/12/10(月) 09:43:10 ]
>>144
3行でおk

146 名前:デフォルトの名無しさん mailto:sage [2007/12/10(月) 18:12:49 ]
>>145
俺の
コードに
文句言うな



147 名前:デフォルトの名無しさん mailto:sage [2007/12/10(月) 21:34:29 ]
>>144
一日目でそれだけ書ければすごいよ。

148 名前:デフォルトの名無しさん mailto:sage [2007/12/10(月) 22:13:04 ]
>>145
3 行 x 80 桁ではこれが限界ですた…

fun r () = let open TextIO String Char val c = (valOf o input1) stdIn; in case c
of #" " => print "&nbsp;" | #"¥t" => print "&nbsp;&nbsp;&nbsp;&nbsp;" | #"¥n" =>
print "¥n" | _ =>((print o toString)c;(print o valOf o inputLine)stdIn);r() end;






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<224KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef