Timeline for it list by senooken, page 84

なんで、Scheme という括りじゃなくて GNU Guile 使いますとか、Racket 使いますとか言っていった方がもういいのではないかという気がしている。

今後 Scheme どうなるんだろう……。SRFI を取り込んでいく R7RS-large はカオスになっていく気しかしないし R5RS で終わっておくのが一番平和だったんじゃないかという気がしてならない……。

Scheme について関数型言語の一つだよねって言われると困る感じするんだよな。その側面も確かにあるけど言語を作るための種としての側面の方が圧倒的に上回っているかと……。

Common Lisp と Scheme の最大の違いは「関数」と「手続き」の違いかと思います。Common Lisp の関数と Scheme の手続きは役割りが違うんです。Scheme の手続きはプログラミング言語の全ての制御を司る機構です。

末尾呼び出しが最適化されるので、手続きは「繰り返し」を表現するためにも使えますし、任意の位置で継続を手続きとして取り出せるんで、「例外」機構を手続きで作ることができます(call/cc と dynamic-wind の組み合せ)。

Scheme は言語のコアな機能を構文ではなくて手続きとして提供することで、プログラミング言語の拡張性を上げているので、この状況を defmacro と比較するのは難しいのではないかと思います。Scheme では新しい構文を作成するのとは別の方法で言語を拡張できるわけです。

Scheme を言語設計をするのに必要な最小セットだと思えば不思議に思うことはない。

Scheme はそれ自体でプログラミングする言語ではなくてプログラミング言語を作るためのプログラミング言語だとしてみれば、破壊的変更が必要なことに納得できるかと思う。

Scheme も Haskell も碌にやってないけど、個人的には Haskell の方がしっくりくるんだよな

普通のプログラミング言語だとたとえば配列の最初の要素に何か代入するときは、変数に値を代入するときと同じように。`a[0] = 1`みたいにする。でも Scheme にはそんな構文はなくて、`(vector-set! a 0 1)`のように書かないと変更できない。（なお変数に値を代入する場合は `(set! x 1)` のようにする)SRFI-17 では、この明示的な区別には意味がある派とない派で戦争が起きた。

Scheme の一般化された `set!` を言語仕様に含めない方針によって、データの書き換えと変数への代入を混同しなくなるのは本当なのか気になっている。

もしそうなら Scheme をプログラミングの初期教育に使っても良いことになるのではないだろうか。

やっぱそうだよな……。C のポインタ分からないとどうしようもない気がする。ただ私はC言語から学んだ勢なんでそうでない人にとって世界がどううつるのか想像もできない。コウモリであるとはどういうことかみたいなレベルで分からない。

これもしかしてライブラリかな。デフォルトでは使えないかも。

あ、Racket でも一応 SRFI-17 実装されてるのか。

SRFI 17: Generalized set!https://docs.racket-lang.org/srfi/srfi-17.html

SRFI-17 反対派は他の言語でその混乱が生じるのは異なる操作を `=` という同じ記号を使っているせいである。Scheme にも同じ問題を持ち込む気か！みたいな感じで、SRFI-17 賛成派はそんなのデータを書き換えるか環境を書き換えるかくらいの違いしかないじゃんとか、データも set! で書き換えられたら便利じゃんみたな感じで言い争っている。

たぶん、Racket では SRFI-17 使えないんじゃないかな……。

const だけどデータは書き換えられる問題、Scheme の SRFI-17 のメーリングリストで一般化された set! (他の言語でいうところの代入記号 =)を導入するかどうかで大揉めしていたのを思いだした。

Re: perhaps I've missed something ... - Simplelists.comhttps://srfi-email.schemers.org/srfi-17/msg/2778583/

その後「スクリプト言語」なるものに関心を抱き、当時は Perl, Python, Ruby が並列に語られていた。その中で一番古いのは Perl らしいので私はとりあえず Perl を勉強したんだけど、その後 Python も Ruby もやった結果それぞれ全然違う言語だと分かって驚いた。あれなんで並べられてたの？

そもそも今の世代の学生ってC言語学ぶのかな。私がプログラミングを勉強しようとしたときって何故か「まずはC言語をやるのが定石」みたいな空気が流れていた。

C のポインタ問題が構文の複雑さに起因すると仮定すると、Perl のリファレンスが難しい問題と Lisp の cons の理解が難しい問題に説明がつかなくなる。

やっぱこれ共通する難しさがあるんじゃないかと思う。

まあ、C のポインタは型宣言の構文が異常にややこしいというのがある気がする。

でも、どうも本質的な問題はそこじゃないっぽいんだよな。

たぶん、一般に C のポインタが難しいとされているのと似たような理由なんだろうな。ただ私はその壁に当たらなかったので、どうやったらポインタが分からない人にポインタを教えればいいのかが分からないんだよな……(TA時代の苦い記憶が蘇えっている)。

なるほど……。やっぱリファレンスって鬼門なんだ。。。