- Lisp Scheme Part39
892 ：デフォルトの名無しさん[sage]：2015/03/07(土) 01:04:14.21 ID:UBHk2s1Q - >>888
Schemeが目指すのは弱点や制約を取り除いていくこと。
実用面での不足があるという弱点を取り除こうとするのは当初からの存在意義通り。
例えばだよ、Lisp一般の話として、他のプログラミング言語では構文を追加できないという制約をマクロで取り払った。
これは制約からの解放ではあっても現実としてマクロ機能を追加してもいる。
でも、マクロを追加するのは、必要だからたくさんの構文を追加しましょうというのとは違うだろ。
ニュアンスを説明し難いけど、結論からすると全然違うよ。
|
- Lisp Scheme Part39
895 ：デフォルトの名無しさん[sage]：2015/03/07(土) 09:25:38.24 ID:UBHk2s1Q - REPLは開発環境に属することなので言語仕様の一部として決めるべきじゃないと思うな。
仮に決めるとしても今というのは早すぎる。
何が正しいのかわからない段階で決めるってのは足かせになるだけ。
つまり今のSCHEMEはまだまだ未完成な存在であると同時に、
急いで決めるとろくなことがないという思いによってそうなってる。
未定義の中で現れて現実の中で鍛えられた実装を元に仕様にフィードバックするという形
なので、ちょくちょく仕様改定するというスタンス。
|
- Lisp Scheme Part39
898 ：デフォルトの名無しさん[sage]：2015/03/07(土) 13:14:14.81 ID:UBHk2s1Q - >>896
結果的に時間はかかるんだけど優先順位の問題だよ。
ダークコーナーだったトップレベルの挙動がR6RSで一旦決まったけど、
あれにREPLを持ち込むと破綻してしまうということははっきりしてる。
拙速ではあったけど正しいと思う形に (それまで決まってなかった部分の) 挙動を決めたら
REPLがはじき出されたんだよ。
REPLが絶対に必要でそこでの挙動が明確でなければならないとするなら、
正しいと思う形を曲げ (妥協し) なきゃいけない。
最終的には妥協するにしても優先順位がどちらかというと
REPLではないな。
|
- 関数型プログラミング言語Haskell Part27＿©2ch.net
793 ：デフォルトの名無しさん[sage]：2015/03/07(土) 16:36:05.33 ID:UBHk2s1Q - 気持の問題。
|
- Lisp Scheme Part39
904 ：デフォルトの名無しさん[sage]：2015/03/07(土) 17:34:03.61 ID:UBHk2s1Q - Schemeは世の中の動きに左右されない「絶対」を求めてるんだよ。
出来るかどうかは別として。
|
- Lisp Scheme Part39
917 ：デフォルトの名無しさん[sage]：2015/03/07(土) 23:45:02.22 ID:UBHk2s1Q - >>911
C++ に REPL がないのは穴か？
(厳密にはあるが本来の意味を大幅に外れないと成立しない。)
REPL を含めて厳密な意味論を定められる言語仕様の方が特異だろ。
ただ、 R6RS はひとつの完成系ではあっても急ぎすぎたと認識したから
R7RS では R6RS を踏まえつつもだいぶん後戻りした。
|
- Lisp Scheme Part39
918 ：デフォルトの名無しさん[sage]：2015/03/07(土) 23:52:27.79 ID:UBHk2s1Q - >>916
色んな可能性があって、色んな実装が出てきて、
それでもやっぱり決まってしまったものが仕様になっていく。
今のところポータビリティがないという弱点はあるけど、
急いで埋めてヤワな土台にしてしまうのはSCHEME的でない。
|