星田さんの記事について。
> 2021/10/29
Syntax-rulesは便利そうだったかな。
うん、是非ともsyntax-rulesは押さえておいてください。
正直、syntax-rulesは非力なんだけど、マクロ理解の第一歩としては結構分かりやすい。
ANSI Common Lispのマクロを学ぶにあたって、基本的な考え方を教えてくれるとは思います・・・・・・見た目随分と違いますがね。
重要なのは式から式への変換です。そのアイディアをsyntax-rulesは明示してくれるでしょう。
まさか一気に届くとは・・・
わははははwwwww
1/2がグレアム本ですね・・・そっか、ポール・グレアムに接触するか(笑)。
イイことですよ。
彼はCommon Lisperだと思われてるけど、根はSchemerですね。
だから彼のコーディングって、実はANSI Common Lispユーザーとしては異端の方だし、綺麗なコードを書きます。
元々彼は、述懐に拠ると、あんまCommon Lisp自体は好きじゃなかったらしくってT言語と言うのを愛用してたようなんです。
T言語はScheme方言なんだけど、実用性目指してCommon Lispの機能を持ってきたりしてた言語です。
余談ですが、T言語の主要開発メンバーが、後にScheme開発を手がけるんですが、それがScheme48です。元々2日で書き上げた、ってぇんで48hoursならしいんですが。ポール・グレアムのArcもRacket(旧PLT Scheme/MzScheme)に移ってくる前、Scheme48で開発してたらしい。
いずれにせよ、ポール・グレアムのコーディング方法は元々Schemeの方に影響を受けてる、って事ですね。だから物凄く分かりやすいです。
出来たらArcを入手してArcのソースコードも目を通してみてください。非常に綺麗です。=> Windows10でtarファイルを解凍する方法
４，むちゃくちゃ気に入ったら買う（セコい）
いや、セコくない。
星田さん、むしろ勘がイイなぁ〜。
以前言いましたが、実はこのテの技術書ってのは事実上「やたら値段が高い同人誌」です。だから購入リスクは結構高いんですよ。
だから身銭切る前に「確認する」ってのは非常に重要です。セコくない。むしろ極めて冷静な正しい行動なんじゃないか。
余談ですが、しかもネットのいわゆる書評が全然アテになんない。ぶっちゃけ、Amazonのレビューが一番アテになる、ってな具合です。
IT系出版社が、宣伝としてアルファブロガーたる奴らに献本して書評を依頼したりするんだけど。「身銭切ってないモノに批判的な記事が書ける」ワケないじゃないですか(笑)。だからアルファブロガー系の書評は全くアテにならんのです。
だからAmazonに「身銭切って買ってダメだったって書く」奴らの方が信用出来るんですよね。
あと、特にネットで仲間募って書いたような本だと「同好の士」で集まってやってるわけで、批判が起きにくい、と言う最悪な循環になっています。だから「プロの、マトモな編集」が関わらない「査読しました」って本もクオリティ的には全然アテになんない。
こういう状態だから、ぶっちゃけ、コミケの同人誌の方が、まだ批判に晒される確率が高くなるので結果、質が高くなるくらいです。技術書は基本的にそういう理由で「全然ダメ」なんですよ。
と言う事を鑑みると、繰り返しますが、星田さんの行動は「セコい」んじゃなくって「合理的」です。正しい判断をする、ってのは「勘が良い」って事に他ならない。危険を避けてるわけですから。
んで、この本はCommon Lispのマクロに付いての本です。まぁ、それもあって、最初にSchemeのsyntax-rulesを学んでマクロの概念に対して準備しておいた方が良いですね。・・・多分最初にCommon Lispのマクロを見るとひっくり返るでしょう(笑)。
また、多分そのLisp関係の書籍では一番古く、実はOn Lispは(殆ど問題ないにせよ)ANSI Common Lisp対応ではないです。実はそれよりも前のCommon Lisp the Language, 2nd Editionと言う旧版(※)対応になってますね。
最後のAmountも「口座内の数値を表示する」って事ですもんね。
と言うより「口座内の数値を返す」為にあります。
仮にそれが無い場合、
(define (make-bank-account amount)
(lambda (n)
(let ((m (+ amount n)))
(if (negative? m)
(error "残高が足りません" n)
(set! amount m)))))
> (define tawa (make-bank-account 1000))> (tawa 5000)
>
と、返り値をtawaに束縛出来なくて、全く何が起きてるのかサッパリ、になります。
実はこれは単純に、set!が返り値を持たない、事に由来するんですね。
一方、ANSI Common Lispだと、
(defun make-bank-account(amount)
#'(lambda (n)
(let ((m (+ amount n)))
(if (minusp m)
(error "残高は~Sです。" n)
(setf amount m)))))
CL-USER> (defparameter tawa (make-bank-account 1000))
TAWACL-USER> (funcall tawa 5000)
6000
CL-USER>
と、amountを書かなくて良い。と言うより、Schemeのset!は値を返さないけど、ANSI Common Lispのsetfは値を返す。
言い換えると、Schemeには値を返さない関数(専門的にはプロシージャ、ないしは手続きと呼ぶ)があるけど、ANSI Common Lispの関数は、必ず、絶対、値を返すように設計されている。
ここで衝撃の事実。Schemeはプロシージャがあるんで関数型言語の要件を満たさないんだけど、ANSI Common Lispは必ず値を返すんで関数型言語の要件を満たしてるんです。言い換えると、関数型言語は必ず値を返さないとならないのです。
要するに、ここでおかしな捻じれがあって、関数型言語の要件を満たしてる筈のANSI Common Lispのユーザーは「Common Lispは関数型言語じゃない」と言って違う使い方をするんですが、Schemeユーザーは「関数型言語としての要件を満たしていない」Schemeで関数型プログラミングをしてるんです(笑)。
変だよな(笑)。
> 2021/10/30
返り値を任意の宛先に送ることが出来るのかな？
と言うか、実のトコ言うと、元々Schemeは、その「継続渡し」を実験する為に作られた言語なんです。
1970年代は研究でオブジェクト指向が発展した期間で、元々のオブジェクト指向の雄、Smalltalkが出てきたのもこの期間です。
アラン・ケイが「オブジェクト指向」という言葉を創った当初は、Smalltalk システムが体現した「パーソナルコンピューティングに関わる全てを『オブジェクト』とそれらの間で交わされる『メッセージ送信』によって表現すること」を意味していた。
この当時、この「メッセージ送信」ってのがある意味研究対象になってたんですね。あらゆる「オブジェクト」にメッセージを送信してプログラムを書く、と。
で、MITのカール・ヒューイットって人がメッセージ送信を基本にして作り上げた言語がPlanner(計画する人、の意)、です。この人は「アクター理論」と呼んでて、「アクター」にメッセージを送信してプログラムを書く、と。
言ってるこたぁSmalltalkと変わらない(笑)。
ただ、この言語は複雑怪奇で動作を想像するのがメチャクチャ難しかったらしい。
そこで、Schemeの設計者、ガイ・スティール・ジュニアとジェラルド・ジェイ・サスマン(SICPの著者の一人)の二人が、実際「アクター理論」に基づいてメッセージ送信の仕組みを知るためだけにLisp上で小さなLispを作った。これが初代Schemeです。
ちなみに、本当はPlannerにあやかって「Schemer(企てる人)」って名付けたかったらしいんですが、文字数制限があったため(笑)、最後のrが無くなってSchemeになったらしい(笑)。
ところが、これで書いたメッセージ送信のプログラムをコンパイルして、機械語を調べると「あれ、これ、フツーにreturnしてるのと変わんなくね?」ってのを発見するんですよ。機械語レベルだとメッセージ送信は要するに関数を書くのと何も変わらなかった。
と言うわけで、フツーの関数とメッセージ送信を統一的に扱って構わない事をSchemeで発見したんですね。これで出てきたのが「継続受け渡し方式(CPS)」と言う書き方です。
また、この実験中に末尾再帰が単純なループに変換可能な事も分かった。それもあって、末尾再帰最適化、と言う機能がSchemeで要求されるようになったのです。
この辺のアクター理論に関する話は次のリンクを参照してみてください。 => SchemeとActor理論
※: Common LispはそれまでのLisp方言の多さに辟易して、「共通のLispが欲しい」と言う要求で作られた。策定者はオリジナルのSchemeの開発者であるガイ・スティール・ジュニアを中心とするグループ。
最初のCommon Lispの仕様は1984年に発表されたが、この時点ではまだ有志による「草の根」仕様だった。
この仕様の第二版が、同じくガイ・スティールに拠るモノで、出版が1990年。しかし、この時点でもまだANSI(アメリカ規格協会)での公式仕様ではなかった。
この後、第二版を改版して1994年にめでたくANSIの審査を通ったCommon Lispの公式仕様の出版となる。
つまり、最初にCommon Lispなるモノを作ろう、と言い出してから10年後にやっとアメリカ国内では「共通のLisp」が出来た、と言う事だ。
