R5RS、R6RS、R7RS でそれぞれ商と余りを求める手続きの名前が違っていて(R7RSでは互換性の維持のために R5RS のも使える)。個人的には R5RS の quotient, modulo, remainder に慣れてるけど、 R7RS の floor, truncate 系の名前の方が正しそう。手続きと構文の名前は基本的に R6RS よりも R7RS の方が洗練されていると思う。
R7RSのeditorであるJohn Cowanは処理系作者ではない(Schemerなのは以前から知られていた)のが異色だったりする
R7RS largeに入るにはSRFIが必須とされているので、SRFIの策定プロセスで議論が進められ、R6RSのような分裂を避けていこうという方針(だけどまだfinalになっていないSRFIが内定したりして若干不穏がないでもない)
低レベルマクロ、explicit renamingがR7RS largeに入るといわれているものの、現時点ではまだそのためのSRFIが書かれていないはず
R7RS と比較して R6RS を使いたい理由としては syntax-case も強い。R7RS の方の低レベルマクロ機構がどうなったのか追えてない。
R5RS の時代からある処理系のデフォルトのモードは大抵の場合は R5RS に独自のライブラリシステムを追加したものになっているという認識でいる。
Implementing R7RS on R6RS Scheme https://www.slideshare.net/katotakashi16/implementing-r7rs-onr6rsscheme
Scheme '14 http://www.schemeworkshop.org/2014/
Sagittariusの作者はR6RS処理系上でR7RSを実装して発表したので徐々にR7RSに集いつつある現状に大きく貢献しているという認識
(重くて飛べやしない) https://pawoo.net/media/QkP8emi1rBreJgPfwYM
時の羅針盤@blog: R6RSとR7RSのライブラリ比較 https://compassoftime.blogspot.com/2012/12/r6rsr7rs.html
PythonはCPythonが圧倒的な支配力を持っているけれど、Schemeは得意分野の違う様々な処理系が共存しているので割と違う
私の主観ではPythonより荒れてた(R6RSのドラフトに対する投票で処理系実装者も賛成派と反対派に割れて、一応必要な賛成票は集まったけれど反対派のグループがERR5RSを提唱したりしてなんだかんだあってR5RSとの互換性を重視したR7RSができた)
R5RS:現代的なライブラリシステム(モジュールシステム)がない、シェルスクリプトのsourceレベルの機能ならある
R6RS:ライブラリシステムを追加した
R7RS :ライブラリシステムの設計をやり直した
SRFI込みなら機能面でどちらがどうということはないんですが、ライブラリシステムに互換性がないので両対応にするにはコツがいる
Scheme ほとんど何もわからんのですが R⁷RS と R⁶RS の違いで開発体験にかなり影響する機能ってどんなのがあるんですか
こみトレに向けてプリコネ制作なう https://pawoo.net/media/QgregaSVo6c1gPd2z-Q https://pawoo.net/media/i0ei43k6uG7A6Nrb2gg
きららmax連載中、私を球場に連れてって!のイラストを描いてみました。今年もプロ野球いよいよ開幕!!!