;; -*- mode: org; coding: utf-8 -*-

new->old順

• %multiple-value-prog1 を実装
• 複素数 fallback. fetestexcept で domain error を拾う。
• Continuation 型を削除。 VM を Lisp_ptr に詰められるように
• eq_internal を inline 化
• Lisp_ptr の int wrap 部分を共通化 enable_if 無双のこと
• 環境を返す関数 (やらなかった) interpreted 関数は環境を立てるので、外の環境を返せないはず

• quasiquote syntax-rule化
• Winline 調整 Lisp_ptr::get<> のチェックを assert 化

• -Wswitch-enum いくつかの if/else 連鎖を、 switch に置きかえ。

以下のように決定

identifier

小文字。 ZS_IDENTIFIER_CASE マクロ。 configure では指定できない。 これを大文字にしようとすると、埋め込みリテラルを 全部置きかえることになり、面倒なため。 C++11リテラルが使えれば、楽になる可能性はあるかも。

case-insensitive 文字比較

zs_case.hh の zs_charcasecmp()

case-insensitive 文字列比較

zs_case.hh の zs_strcasecmp() この代替実装では、 tolower を使用している。

• tolower の使用箇所 この二箇所のみ
  1. zs_case 内 (ZS_IDENTIFIER_CASE, zs_strcasecmp)
  2. Scheme の tolower 実装。

• (なし) デバッグ関数に attribute cold を付けて回る遊び
• undefined/uninitialized な値の初期化をサボる 一箇所発見した。
• Passing::quote 時の Variadic call 規約を変更。この時は、native関数でも list が渡ってくる。 Passing::whole をいくつか追い出せた。
• autoconf で __cplusplus を見てC++0xコンパイラ判定 ax_cxx_compile_stdcxx_11 を使用 https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html

• throwする関数を作る バイナリサイズ的に、現場で throw するよりも noreturn な関数を呼んだ方がいい。
• 型名の命名規約を統一する

  class

  UpperCamelCase. (除: Lisp_ptr)

  struct

  全裸な型. UpperCamelCase. (除: to_type<>)

  enum

  全て enum class. UpperCamelCase. (除: Ptr_tag)

• inline関数のinline宣言 header では一切宣言しないことにした。どう定義されても関係ないだろう・・ (inline があったら、 .i.hh にある、というのは分かりやすいかもしれんが)
• macro transformer 手続きにも名前をあげる vm_op_define (旧 vm_op_local_set) であげることに

• srfi-0
• テストのscheme化 case変更でテストが壊れると面倒。
• tmpfile(3)相当
• exit で終了ステータスを返せるように
• Tokenizer整理 Token型はなくなり、Lisp_ptrに統合された。
• .scm inclusion
• 引数のバリエーションがある関数 native 関数はほぼ引数固定に。 .scm でデフォルト引数を付加する。
• 例外型整理・・というよりなくした。 文字列しか飛んでこない。どうせcondition型もないので。
• (なし) syntax-rules での traversal をまとめる 微妙なハンドラばかり増えて、うれしくない。
• EOFをまともに扱えるように
  • tokenize() -> EOF にいったら EOFを返す。
  • read() -> list等の中で EOF だとエラー。さもなくば EOF を返す。
• VM初期化の整理 VMが、static変数の初期化順序に依存しており、あぶない状態だった。 現在は、初期化関数で初期化されるように修正済み。

• evalを再帰させると壊れる 再帰を「慎重に」除いた。
• procflag処理 letの非native化に伴い、Entering flag はなくなって一気に整理された。
• let実装 R5RS定義をそのまま採用
• std::get みたいに list に触るinterface 結構昔に、 nth_cons_list とか作ってた。
• 先頭をとりのぞくために、ConsIter を使う nth_cons_list にしたり。

• srfi-23, srfi-34
• repl での eval を ignore-errors で囲む
• test-error も直す

結局、Lisp_ptrの構造そのままに実装

連分数展開で実装

Wikipedia から連分数展開を参照し、それを使用 http://en.wikipedia.org/wiki/Continued_fraction#Infinite_continued_fractions

rational.* を追加。 ついでに、整数オーバーフロー確認を有理数型で扱うこととし、普通の整数 型でも有理数側に一旦入れて扱うように。たぶん重いがすっきりした。

• 引数の arity 確認が間違い。 call/cc に渡される関数は厳密に一つの引 数を取らねばならなかった。実際には、0以上取れればよい。
• 引数の処理中に call/cc で脱出した場合、演算子が関数でなくてもエラー にならない。=(0 (cont 100))= みたいな式で、 cont が継続ならば、 エラーにしてはいけない。ad-hoc な対処でカバー。

named let のバグ修正の一環。 named let の名前は、 let の binding し てる所から参照できてはいけない。ついでに define された手続きも名前を あげるように。

ラムダ式の組みあわせで表現できそうなのだが、楽なのを採用した。

integer overflow で real に fallback。

long long を一回経由する形で実装している。整数型を変えずにやる手も色々 ありそうだが、複雑になり確認が難しく保守できなくなることは見えている。

数値関数の実装がぐしゃぐしゃだったのを整理。 ちょっとした用途ごとにちまちまヘルパーを書いていたのを改め、 大体が拾える統一的インターフェイスに置きかえ。

int, double,complex は Lisp_ptr と Token に入れこまれた。

現在、 C++ の範囲で出来ることだけしてある。 ライブラリ依存 (libstdc++) のインターフェイスには降りていっていない。

std::basic_streambuf<>::in_avail() 関数が強力で、大部分はこれで終 わっている。この関数は、バッファの持つ残り文字数を返すだけでなく、バッ ファが空の場合には下請けの showmanyc() を呼び、持っている fd とか から読める文字数を見積もろうとする。そのため、この関数の返り値を見る だけで、実装の大半は終わる。

ところが、 char-ready? は、「port がファイルの終わりに到達したとき に、 #t を返す」ことを求めている。 in_avail() は、ファイルの終わりに 到達したときと、読み込みを一文字も出来ずにブロックするときの両方で 0 を返してくるため、この二者を区別しないといけない。

ファイルの終わりに到達したあと、一文字でも読んでいた場合は、上方の stream 等に eofbit が立つので、それを見ればよい。しかし、そもそもブ ロックするものは読んではいけないし、たとえブロックしないと(神秘的な 力で)予測できても、「前回の読み込みで丁度ファイルの終わりを指した」 という場合を上手く扱えない。 他の get的な関数は、当然ブロックするの で使えない。 pubseekoff() で位置を見てみることを考えたが、 pubseekoff() も(なぜか)ブロックするので、ブロックしないで検査する という用途には使えなかった。

現在のコードは、この先の判定はやっていない。先に、どうあるべきか考え たい。

標準 C++ を逸脱して、 libstdc++ 依存の層に降りていくと、とりあえずの 解法はある。

in_avail() が 0 を返した場合、 dynamic_cast をかけて、型を取りだ して分岐する。

• __gnu_cxx::ext/stdio_filebuf の場合

  どうやら libstdc++ で std::sync_with_stdio(false) をかけると、 std::cin がこの型になる。この場合、 fd() 関数で file descripter を取れる。これがあれば、 poll(2) や lseek(2) でどうとで もなる。

• __gnu_cxx::ext/stdio_sync_filebuf の場合

  std::sync_with_stdio(true) の場合の std::cin のようだ。 file() 関数で C の FILE 構造体を取れるので、そこに fileno(3) を かませば上と同等。

• std::stringbuf の場合

  これは本当に空だと思われる。EOFと同じ扱いでよい。

  と思うのだけど本当だろうか？ 例えば、 SRFI-6 の string port が空に なった瞬間に char-ready? をかけた場合、何を返すべきなんだろう？

• なにかの filebuf の場合

  おそらく、 libstdc++ の filebuf である。この先に降りていくことは出 来ない。

  fstream を使って stream を作る場合、どうやらこの型が使われる模様。 そのため、この型の場合は pubseekoff() を使っても、おそらくブロッ クしないだろうと踏める。

  もちろん、 キャラクタデバイスファイルなんかを開いてしまった日には この限りではない。そういうのを厳密に扱うなら、「このプログラムでは 常に stdio_filebuf を使う」とかの規約が必要だろう。

• その他の場合

  ＼(^o^)／

• R5RS macro おそらく大丈夫だろうということで、多くの構文実装を syntax-rules ベースに移行
• intern() で内部関数にアクセスする処理の除去 シンボルを導入する箇所だけに残る。それ以外は排除
• (未遂) 実行時に使うシンボルは毎回internするんじゃなくて、どこかglobalなところに初期化時に置く intern はほぼ廃絶したので未遂。 組み込み関数を呼んだり、組み込み関数を探したりするのが、多くの intern() 使用例だったので それ専用のものを用意した。 マクロが入った今、安易にsymbolだけで関数を探すと変になりかねないので、それへの対策も兼ねていた。
• (未遂) bulitin interpreted function を専用の構造体に 内部構造専用の型を導入し、C++ load() 関数を削除するのが目的だったが、やらず。 やっても、ほぼ “read ‘(define …)’ “と書いている今の形式とほぼ同様の見た目。 なのに、専用のreaderを書かないといけないので、なんか格好悪かった。
• stack_to_list stack_to_vector を整理 勝手にstackを触るので、ZsArgsと一緒にいると、きもちわるい ZsArgs が begin/end を取れるなどの事実を利用し、一掃した。
• テストバイナリの暴走を防ぐため、ulimit制限しとく automake での ‘make check’ で使用される環境にそれを入れた

• R5RS macro
  • 最初のkeywordにbindしないように -> 先に判定して、引数 ignore-ident に詰めている
  • syntax-rules で vector を取れるように -> 気合いコピペ実装
  • pattern に syntactic alias が入ってきた時になにが起こるか検証 -> close_to_pattern_variable() で扱っている。そのままスルーする。
  • templateには、展開結果を埋め込んであげないといけない quasiquote的に実装できる? -> 色々複雑なので手書き
  • pattern の調査は事前に check-duplicateの問題は。それはそれで調査。 いつ値がsetされたのか確かめないと、変な上書きするかもしれない -> check_pattern() 関数
  • 変数を capture する lambda式を static const にしていた。 これをやると、一度作られた lambda式は、延々と「最初の」引数を参照し続けることになる。
  • native function に syntax closure が入ってきちゃう問題 対応策
    • implicit forcing delay も同じ現象を引き起こすので、それに対処できるかも。
    • self evaluating な値を wrapしない 判定関数をよういする
    • identifier の eq hashを直す identifier=? のセマンティクスを持つ hash でないといけない。

    -> alias to alias 問題と同根といえる。 close_to_pattern_variable() が構造を destruct し、 さらに syntactic closure を二重に包まないようにして対処。 別の環境のclosure同士でも、意味的には最初のやつを残せば合ってるはず。

  • ellipsis identifier 以外の pattern の並びを上手くあつかえない matching は上手くいっているが、 expand でも同様にしないといけない -> 再帰的に結果を map に蓄積するコードに
  • alias to alias 元環境で bind されていたら、それを持っていくようにした。大丈夫なのか？ eval() 側で「書きかえていい環境」を用意するんじゃなく、syntax-rules 内で考え、環境を返すように。
  • bind to syntactic alias 本当に ‘syntactic closure 自身に bind’ という実装が必要なのだろうか？ 単に同じ名前の symbol (環境を無視) に bind すればいいんじゃないの

    Env が持つ table は ‘symbol <-> Lisp_ptr’ のみとする。 「上書きした alias 一覧」を Env 中のどこかに管理し、leave_frame や VM::set_frame() 時に戻す、とか

    • その環境が lambda に補足されたら? bind 作りなおし?

    -> bind を伝搬させるような挙動となり、それは健全性に反している、と思う。

  • usage-env の let を参照するには？ rsc-macro-transformer の semantics が必要? -> このときは、usage form の方をcloseして、transformer-envに切り換えて評価していた。 それを逆にして、transformer formをcloseし、変換後 code を返すだけにした。 これで自然に参照できる。
  • bind to syntactic alias (2) やはり、aliasの指す先の環境を書き換えることが必要??
    • macro_test.cc の aif の例 同じ symbol + 環境を指す syntactic closure だが、 片方は alias で、もう片方は式の syntactic closure 。 「 alias に bind して環境は書きかえない」だと、この alias に bind しても、 後者の syntactic closure から参照できない!

      -> 間違い。これはテストケースのバグと思われる。 「syntactic closure の free-names に指定したものは、どの変数を参照するか」という問題。 aif の例は、外側に let があるかないかで参照する scope が異なるのかどうかというもの。 この場合、 aif に it の参照は閉じるべきだと思う。

• traditional macro traditional-transformer として実装されている
• set! の名前変えよう なぜこれが zanken にあるのか忘れてしまったが・・ Env::local_set(), Env::set() の整理を以前に行ったので、それにより解消されているはず
• 例外で飛ぶことを前提とした、readerの書き直し number parserのエラーハンドリングが冗長だった
• Calling の更新 呼び出し規約の整理
• whole-macro 復活? 呼び出し規約の変更により、実質的に復活
• equal のファイルを分ける equality.*
• eq hash func をちゃんとする char, bool を考慮

builtin 関数をincludeしてみる

• 実行時例外をC++ exceptionに それを前提としていない冗長な箇所は、まだ残っている
• eval() の defaultでpopする動作をあらためる vm-op にだけ off にした
• 引数access の proxy class ZsArgs
• typed-destruct strict mode 長さの厳密なチェックをする

• vm_op_if で使うのを code stack にする
• leave_frame のところに戻り先envを置く。 vm env_stack の排除
• nprocedure の型を Lisp_ptr (*)(void) に 引数の数の検査もeval()側で
• cons list を C++ iterator で回せるように proper list でなければ 例外

• STL iterator compilant CONS
• input port, output port を別の型として、Lisp_ptrにlift dynamic_cast を除去

• typemap
• Portをc++ stremにする
• release package は downloads におく
• 古い項目
  • &whole パラメータを実装する
  • 組み込みマクロ expand-define で関数定義のdefineを展開する
  • evalの式解析でnullpを使っていく
  • publish with autotools
  • ungetc + fflush() ????
  • autoconfでfmemopenまわりを判定して代わりのコードを入れられるように

growlist構造体

• <2012-11-06 火> dynamic-wind
• <2012-11-02 Fri> replをevalで扱う
• <2012-11-02 Fri> stackで引数を渡すときに、その引数の数も渡す。
  • 全ての評価式を一気にcode stackに入れず、逐次展開
• <2012-11-02 Fri> whole-macro を除去。whole functionに統合。
• <2012-11-02 Fri> let* を 素直に 実装する
• <2012-11-02 Fri> do実装(色々な修正も含めて動作可能に)
• <2012-10-17 水> VM stackの内部vectorを見せちゃって、任意に書き換えられるように
• <2012-10-17 水> call/cc
• <2012-10-16 Tue> stackの中身をやっぱりdequeにする
• <2012-10-09 日> set! は unbound な所に入れようとするとエラーを吐かないといけない
  • 今の VM::set が、失敗した時に local_set に落とすのが間違っている
• <2012-10-03 Wed> ArgInfo に Calling も入れる
  • もう ProcInfo とかに改名
  • これ以上太るようなら、フラグをbitfield化
  • もっといくなら、例えば、NativeFuncのProcInfoを共有 predefined な構造体へのポインタのみにする

  – サイズが(ポインタに比べて)かなり大きくなったらの話

• <2012-10-02 火> is_sorted の無茶な使いっぷりをどうにかする 代替実装を手書き。バイナリサイズは犠牲に。
• <2012-10-02 火> lambdaが作られなかった場合の環境をきちんとdelete
  • 自前での参照カウント
  • shared_ptr<>は使えなかった あるEnvを指す新しいポインタを得る際に、shared_ptrの場合はそれを指すshared_ptrをコピーする などしてカウンタを触る必要があるが、それはそのEnvからは分からない。
• <2012-10-02 火> #\<文字> 書式の修正
  • 後にdelimiterが来るかどうかを確認
  • 文字名指定は case-insensitive
• <2012-10-02 火> 数値操作 有理数以外
• <2012-10-01 Mon> builtin_whole のようなファイルを作って、色々まとめる。
• <2012-10-06 Sat> Portの実装
  • FILE*に皮をかぶせている
  • 色々めんどうなので、もはやC++ streamのほうがいいかもしれん
• <2012-09-27 木> このwikiをorg-modeにする
• <2012-08-31 Fri> Lisp_ptrはexplicit外していいかも
• <2012-07-19 > symbol, symtableのコードをまとめる
• <2012-07-19 > VM内部に触るインターフェースが不均一
  • 直のフィールドアクセスに置き替え
• <2012-07-09 > stack取り出しtemplateを、iterator使用に書き換え
  • 両方のインターフェースを残している
• <2012-07-09 > native funcをinterpreted funcと別の型にしてconstで常に扱えるようにし、バイナリに仕込みやすくする
• <2012-06-27 Wed> quasiquoteの引数回収の仕組みを、同等のnative callと同じにしてソースを減らしたい
• <2012-06-20 Wed> whole function, whole macro
• <2012-06-19 > define は local set じゃないとまずい
• <2012-06-19 > VM_op を関数ポインタにしちゃう
• <2012-06-09 > symbolにkeywordか否かの判定結果をあらかじめ持たしてしまおう
• <2012-06-09 > variadic template で固定長リストマッチ
• <2012-06-09 > native func で既定数引数を取り出す仕組み
• <2012-06-07 > tail call 最適化
• <2012-05-25 > lexical closure
  • spagetthi stack 的にenvをcons listでつないだ
• <2012-05-22 > stackとenvは一緒
• <2012-05-17 > （やらなかった） test/ では前ヘッダ一発読み込みでも用意。それをprecompile..
  • コンパイル済みヘッダについて依存関係構築が簡単にできそうになく、そのせいで問題を引き起こしそう
  • 本当にコンパイル時間が問題になったら、考え直す価値が生じるかもしれない・・というレベル
• <2012-05-17 > string::compare -> strcmp()
• <2012-05-17 > （やらなかった）文字列定数を返すやつ(stringify())はconstexprにしてヘッダに追い出せる
  • 追い出すとコンパイル負荷はあがるが、バイナリサイズは減らせる
  • デバッグ用の不要な文字列が組み込まれなくなる。
  • 二箇所以上で使われるとバイナリサイズは悪化するが、そうならないことを保証する手段はない
    • そもそも、使われない関数をつぶすのは inter-procedual optimizer の仕事か・・
• <2012-05-16 > 無駄なincludeを排除
• <2012-05-16 > defineのところのvar検証をlambda式にすれば前側に引っ張りだして自然な順序にできる
• <2012-05-10 > dolist 的なものを作る
  • range-based for とくっつけようと思ったが、終了判定がoperator==なのでこっちの言って
• <2012-05-10 > （やらなかった） istreamをnumberから排除
  • これは面倒杉、いいことあんまりない（tmpfile()になる・・）