アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
なくならない派。 (スコア:1)
だって。。。Suicaの中にあるワンチップマイコンとかで関数型だったりGCとかやったりするのは
経済的にアレだし。
手続き型言語に関数型っぽい考え方も浸透していく、というのは有りそうですが。
ああそうか、おっしゃっているのは、やがては関数型で記述してもマイコン向けコードが
吐けるようななる、ってことなのですね。うーん．．．
例えば for ループのような、シンプルで機械語的・メモリ的にもコストが低いものに対して、
再帰のほうがいいんですよ (再帰でも書けますよ、ではなく) と言える、積極的で
納得できる理由ってあるのかなぁ? と。
Re:なくならない派。 (スコア:1)
>やがては関数型で記述してもマイコン向けコードが吐けるようななる
そんな感じ。でも「マイコン向けコードが」ではなく「マイコン向けコード*も*」同一の処理系で吐けるような処理系。
>例えば for ループのような、シンプルで機械語的・メモリ的にもコストが低いものに対して、
>再帰のほうがいいんですよ (再帰でも書けますよ、ではなく) と言える、積極的で
>納得できる理由ってあるのかなぁ? と。
これはﾓﾚの想定している物とはだいぶ違う。espyさめがちょっと前に書いたscheme云々のあれを想定してみて。あれで全要素の集合を定義してるじゃない。あの例だと結局全部の要素を使うんだけど、たとえば使わない要素があると使われない要素の分を計算しなかったりするんだよね。だから手続きでfor使ってループ回してるところを要素の集合を定義して...ってやるとソースがアルゴリズムから自由になるし処理系も自由にアルゴリズムを選べるようになる。
例えば集合が0-100なら実装上はループで要素を作った上で途中の「変換」にそれぞれ適用するとかになる。これはループになった例だけどSMTなプロセッサがなら分割して同時に動かすかもしれないし、集合にホントのリストやベクタを使えばforeach的な動作になる。他にも有用な集合があるかも知れないが、やっぱりこれも同じように書ける。
そうなるとたとえばO(n2)の処理があったとすると手続き型では相当大変な最適化をしなければO(n2)にしかならないけど、宣言型なら処理系がアルゴリズムを知ってればO(nlogn)になるだろうし、処理系がそのアルゴリズムを辞書的に知らなくても推論してO(nlogn)にしてくれるかも知れないし。
また集合に「順序を守れ」と修飾しておけば(たぶん)ループのままになる。たとえばアクセス順を指定したベクタをレジスタに張り付けて元の集合からマップしてくるようにすると順序通りに値が格納されていくとか。要はレジスタアクセスで順番の指定があった場合に重要なのはアクセス順を守る事であってループ内からアクセスする事ではない。だから宣言型でもこの手の指定ができればハードウェアをベッタベタ触るようなコードも書けるはずなのだ。
手続き型になれた人が宣言型を使って苛立ったり、現状ではマイコンに宣言型言語を使えないのはその言語でこの手の指定ができないからであって言語が宣言型だからなのではない。とﾓﾚは考えてる。
#再帰でループを再現するのはループと同じ事をするだけの、たぶん悪い例なんじゃないかな。