不正なテクニックを駆使してdefine-valuesもR5RSサポートする

追記: SCM自体にはdynamic loadingは有るが、Win32向けのバイナリディストリビューションでは有効にされていない
前回( http://d.hatena.ne.jp/mjt/20160825/p1 )、結局R5RSでのdefine-valuesは諦めた雰囲気を出していたが、結局サポートした。...実際には偶然動いているのでまぁ良いやということに。

Alexpanderにletrecではなくdefineを使わせる

Alexpanderはexpand時にinternal defineをletrecに変換する。

(define a 10)
(define b 20)

;; ↓↓

(letrec ((a 10)
         (b 20))
  ...)

これを、let + internal defineに変換するように変更した。https://github.com/okuoku/yuni/commit/d1b1c852e898e90360f959784169bf5692a6f502#diff-c1032b6304e8ed0e2d26b2e9ea1bba96R833

(let ()
  (define a 10)
  (define b 20)
  ...)

少くともMIT-SchemeとGambitでは、この方法で期待通り(普通にsyntax-rulesで実装した)define-valuesが動作した。MIT-Schemeでは、まだコンパイルを試していないのでコンパイルすると結果が変わってくるかもしれないけど。。

R5RSサポートの意義(と展望 ?)

R5RSサポートをどれくらい頑張るかは非常に悩みどころで、MIT-SchemeとGambitのサポートはモチベーションになっているけど、これらはそもそも付属のR5RSがyuniの目的に使えないのでAlexpanderを追加してサポートしている状況にある。
今のところ、純粋なR5RS処理系(= Alexpanderでなく、処理系本来のsyntax-rulesを使うもの)は一切サポートが無い。SCMのバイナリ配布には組込みのFFIやネイティブモジュール機構が無く、Biglooは開発リポジトリが存在せず、...とやっていくと何も残らない。yuniを展開するには、バグが修正される望みが有ることと、処理系のリコンパイルを伴わずにC関数を呼べることが最低要件なのでR5RS処理系は大分旗色が悪い。
Husk( https://github.com/justinethier/husk-scheme )はHaskell力が溜まってきたらサポートしたい。Scheje( https://github.com/turbopape/scheje )もR5RSでは無いがsyntax-rulesは有るので試したい。
...でもそれより先にBiwaSchemeやs7( https://ccrma.stanford.edu/software/snd/snd/s7.html )のような処理系をどうサポートするのかという所かな。。