継続(continuation)とは，式を評価している途中のある時点で，『いま得られた 値を使って，この後は何を計算するのか』を表すものである．たとえば，Scheme の関数呼びだしの式を評価する際には，まず関数とその引数を評価して，その 後で関数に引数を適用する． ==> (+ (* 1 2) (* 3 4)) ;; ==> (+ 2 12) ;; ==> 14 14 この式の場合，まず「+」,「(* 1 2)」,「(* 3 4)」を評 価したのち，「(+ 2 12)」を評価する． 各部分式の評価が左から右へ進むものとすると， たとえば，「(* 3 4)」を評価した後にするべき計算，つまり継続は， 『いま得られた値に2を加える』 である．この式の評価を完了するためには， Schemeのシステムは，この継続を知っていなければならない． 継続は，「何を評価して，その値によって次には何を行う」
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Lively Linear Lisp 「やりたいこと」 高速なschemeで遺伝的プログラミング(GP)を実行させる。 「そのために必要なこと」 schemeで遺伝的プログラムが可能か調査する。 http://www.geneticprogramming.com/Tutorial/ ＞できそう 線形論理（？）に従ったschemeを実装する。 ＞外してそう Lively Linear Lispを翻訳してデータ構造の策定の参考になるかならないか判断する。 ＞外してる GC不要なLispが遺伝的プログラミングを高速に実行するために有用か調査する。 着手 Automatic Memory Management in newLISPを翻訳してのGC不要なメモリ管理が使えるか判断する。 仕様書を書く。 着手 外部使用を書く とりあえずは、GPに必要な関数のみに限定する。 データ構造とアルゴリズムを
Primitive Procedureの実装をした。 例えば + という手続きがあるがこれはSchemeインタプリタが primitive に持つ手続きである。 Schemeのオブジェクト define/lambda/Variableなどを組み合わせだけでは作れないものである。 このような Primitive Procedureはインタプリタ起動時に Environment に追加される。 environment->defineVariable(new Variable("+"), new Plus());Plusは PrimitiveProcedureクラスを継承したクラスで、"+"という名前でアクセスできるようになります。 applyでは Primitive Procedureかどうかで分岐し、Plus::applyが呼ばれます。 結構適当な実装です。桁あふれとか考慮してません。 Ob
最近、字句解析とか構文解析をしていましたが、その試行錯誤のサマリです。 前提 SICPの４章ではSchemeのインタプリタをSchemeで実装します。 勉強のためにC++で実装してみます。 基本はScheme->C++に置き換えています。（そんなに簡単じゃないけど） 置き換え以外の部分が字句解析・構文解析です。 なぜ構文解析が必要か Schemeインタプリタ(以後インタプリタ)をScheme(以後Gauche)で実装する場合と入力の扱いが違うからです。 インタプリタでは入力を受け付けますが、実際にはGaucheが入力を受け取り、Gaucheが手続き eval にそのまま渡します。 この際、Gaucheが受け取る入力はS式ですが、Gaucheはそれ自体S式をS式として認識しているので特に難しい作業は必要ありません。 一方、C++で実装する場合、入力は"(+ a b)"のように文字列で与えられ
4章では Scheme の上に Schemeインタプリタを作る過程でいろいろなものを学んでいきます。 このように、被実装言語と実装言語が同じなことを metacircular というらしいのですが、読んでいるだけでドキドキしてきます。 実際4章を読み進めていくと、とても面白いのですが、所々で引っかかるところがあります。 どうも読んでいるだけでは解決しないモヤモヤがあって、それは被実装言語と実装言語の境界に関する問題のように思えてきました。 metacircularだと、どこまでが被実装言語の機能で、どこからが実装言語の機能なのか分からなくなってきてしまうのです。 こんな経緯もあり、4章で書かれているSchemeインタプリタを「ほぼそのまま」C++で実装してみようという思いに至りました。 最近SICP日記を更新できなかったのはこのあたりに悩んでいたからです。 いろいろと困難あるでしょうが、試
apply 実装の肝は apply と env のあたりだということに気づく。 (define (apply procedure arguments) (cond ((primitive-procedure? procedure) (apply-primitive-procedure procedure arguments)) ((compound-procedure? procedure) (eval-sequence (procedure-body procedure) (extend-environment (procedure-parameters procedure) arguments (procedure-environment procedure)))) (else (error "Unknown procedure type -- APPLY" procedure))))
上のエントリでは、これまで考察してきたクロージャについての簡単なまとめを行ないました。そのエントリで最後に書いたブロックにも着目しながら、これまで考察してきたクロージャについて、コードを挙げて検証してみようと思います。 さて、上のエントリでは、クロージャの基盤となっている三つの仕様を挙げています。 しかし、これらのうちの幾つかが欠ける場合でも、Scheme で言うところのクロージャではないかもしれませんが、有効に利用可能な手続きを活用することは可能であると、私は考えています。 これは、上で挙げた三つの仕様が揃わない言語環境に於いて、クロージャの様な仕組みを活用することが可能か、という視点に置き換えることができます。例えば、Emacs Lisp や Java などでクロージャの様なコードを書けるか否か、ということですね。 ;; Java にもクロージャを導入可能に (?) といった動きもある
これまで考察してきたクロージャの件ですが、まだまだ頭の中では発散しているのですけど、一旦、簡単にまとめておきたいと思います。 ただ書き散らかしているだけでは意味ない (いや、意味はあると思ってるんですけど。自己矛盾だ。) ですからね。 Rui さん、shiro さんのコメントに助けられて、今では、 手続きをファーストクラスオブジェクトとして扱える。 静的スコープを持つ。 無限のエクステントが保証されている。 の三つの基盤が揃うことで、クロージャが実現されていると考えるに至りました。 Scheme 以外ではどうか判りませんが、こと Scheme に於いては、上の仕様に立脚する形でクロージャが実現されていると考えて差し支えないと思っています。 ただ、言語設計の推移としては、shiro さんから頂いたコメントで示唆されている様に、動的スコープに於ける環境問題 (FUNARG problem) が
Last update 1999/08/07 Scheme処理系の制作 第2回 (C)平山直之 無断転載は禁止、リンクはフリー 誤字脱字の指摘は歓迎 作戦目標 前回どこまでやりましたっけ？ ああそうですか、構文木を内部に作るところまでですね。 その前に、前回のアーティクルでは作戦目標がいまいちあいまいだったようなので、もう少し技術的に踏み込んだ明確な作戦目標を示すことにします。 環境非依存のschemeインタプリタモジュールを作成する。 堅牢性・サイズ・保守の便宜のために、標準scheme以上の拡張は必要最小限しかしない。 外部とのインターフェイスには環境に適した動的モジュール機構を利用する。具体的には、Win32ではDLL機構を使う。 単体では完全なサーバとして働き、不必要なユーザーインターフェイスは（コンソールを含めて）持たない。また基本的には受動的にしか動作しない。 オブジェクト指向
SICP の 3.5 節「ストリーム」に出てきたストリームを Perl で実装してみた。 意外と簡単に書けた。 SICP のお買い上げは、アマゾンの 『計算機プログラムの構造と解釈』 のページからどうぞ〜。 概要 ストリームを使うと、 プログラムに状態変化を持ち込むことなく、 物事の変化を扱うことができるらしい。 必要な時に必要なだけの計算をするのに、 実際に計算をする部分と、 その計算された値を使う部分を完全に分離した形でコーディングできるので、 非常に強力なテクニックとなり得る。 ストリームは遅延リストとして実装するので、 まず遅延評価を実現するための手続き delay と force をそれらしく作り、 その上にストリームを構成するいくつかの関数を書いてみた。 実装 以下に、 テキストに出てきた Scheme でのコードと、 それに対応する Perl のコードを順番に載せます。 スト
4章を先読みとかしているくせに、全然3章が進んでいないので反省中。 今日は問題3.50が解けるまで寝ない！と決めたらわりとすぐに解けた。 問題3.50 cons-streamや、stream-carをまだ定義していなくて、テストができないので cons/carで実装してみた。 (define (hige-map proc . argstreams) (if (null? (car argstreams)) '() (cons (apply proc (map car argstreams)) (apply hige-map (cons proc (map cdr argstreams)))))) (display (hige-map + (list 1 2 3) (list 4 5 6)))mapに car や cdr を渡すところが思いつくのに時間のかかった部分だった。 ということで答え
クロージャについて色々と考えてみました。 以前にも書いたのですが、そもそも Gauche をインストールした目的の一つに、クロージャの動作をもっと理解したいという目的があったので。 で、色々と shiro さんが公開されているドキュメントを読み返したり、Gauche 上で試行錯誤しながら、これまでの私の解釈には誤りがあったと思う様になりました。 これまでの私の理解では、クロージャとは、 クロージャは、ファーストクラスのオブジェクトである。なので、名前も付けられるし、関数の引数や戻り値としても利用できる。 クロージャには、(そのクロージャ生成時の) 環境が閉じ込められている。 クロージャ実行時に参照される環境は、実行時点のものではなく、クロージャ自身に閉じ込めてある環境になる。 というものでした。 これらの認識自体には誤りはないと思っている (誤りがあったらツッコミをお願いしたいです。> 識
待ちに待っていたデジタル回路のシミュレーション。 オラ、何だかワクワクしてきたぞ！ 問題3.24-27 略。 問題3.28 and とほぼ同じ。 今の段階では add-action の実装が見えないので or-action-procedure が2回呼ばれておかしくなるんじゃないかと心配。 と思ったけどよく考えれば入力は同時に届くことはありえないのでこれで正しい。 (define (or-gate a1 a2 output) (define (or-action-procedure) (let ((new-value (logical-or (get-signal a1) (get-signal a2)))) (after-delay or-gate-delay (lambda () (set-signal! output new-value))))) (add-action! a1 or
実用っぽいコードを書かないと中々上達しないと思うので無理やり書いてみました。 引数で受け取ったファイルを開いて、ファイル内を置換する。 「sedとかPerlならすぐに書けるよ」とか「もっと汎用化したスクリプトを書いたほうが良い」というのは分かるのですがまずは練習ということで。 まだ完成していなくて、現在分かっている問題点は 入力と出力ファイルを同じにするとおかしくなる 結果文字列が""で囲まれてしまう 改行コードがなくなってしまう などなど。 気長に直していこう。 #!/usr/bin/env gosh (use file.util) (define (main args) (define (replace-text file) (let ((lines (file->string-list file)) (result "")) (for-each (lambda (line) (set
On Lisp Paul Graham の著書でマクロのことが満載の本。ただし Lisp で書いてある。 文中気になったコードをSchemeで書いてみるコーナー。 （セクションタイトルその他の邦訳は 野田さんの邦訳 をそのまま引用させてもらいます） マクロのツボ マクロはどのように、そしてなぜ違うのかを知ることは、マクロを正しく使うための鍵だ。 関数は結果を生むが、マクロは式を生む。----そしてこの式が評価されると結果を生む。 (「7 マクロ」から) マクロの引数は式であって値ではないことを忘れてはならない。 (「10.1 評価の回数」から) On Lispマクロのツボ5.1 Common Lisp は進化する5.3 関数の値のメモワイズ5.4 関数を合成する5.5 Cdr 部での再帰5.6 部分ツリーでの再帰7.1 マクロはどのように動作するか7.3 単純なマクロの定義7.5 引数リス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く