キーワード構文によるスロットアクセス

SchemeがLuaみたいに流行らない最大の理由はスロットアクセスが面倒な事だと思う。

• http://practical-scheme.net/wiliki/wiliki.cgi?Gauche%3A%E3%82%B9%E3%83%AD%E3%83%83%E3%83%88%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9

Gaucheは[ ]のカッコをスロットアクセスにつかうことを考えていた。これは確かに合理的なんだけどR6RSでは[ ]は( )と同じになってしまったので今後導入できるかというと微妙なところ。
yuniではSRFI-88形式のキーワードを切り崩してスロットアクセスに割り当てている。要するに、

(hoge: a) ; オブジェクトaのスロットhogeへのアクセス
(hoge: a b) ; オブジェクトaのスロットhogeにbをset!
(car: '(1 2 3)) ; => 1 RnRS。
(cdr: '(1 2 3)) ; => (2 3)
(first: '(1 2 3)) ;=>1 SRFI-1。
(second: '(1 2 3)) ; => 2
(Check: '(HEAD :Check 1 :Test 2)) ; => 1 yuniSchemeのkeylist

(以前R6RSでyuniSchemeを書くために、同様のアクセス機構を持つdefine-tableを書いた。http://d.hatena.ne.jp/mjt/20100115/p2。これは、table間でフィールド名が衝突すると間違ったことが起こる。)
これは通常のR6RSでは実現出来ないので、何らかの形で言語側を拡張する必要がある。

暗黙のアクセサ

↑の例を見れば解るように、キーワードリストのキーワード中に:carや:cdrが入っていると困ったことになる。
多分暗黙のアクセサは悪いアイデアだろう。

構文にすべきか

通常のSchemeで実現するなら、キーワードをapply可能なオブジェクトと見なして通常のオブジェクトと同様に扱う方が好ましいかもしれない。
しかし、apply可能にしてしまうと、例えば(apply hoge: l)のように書かれたときに困るという問題もある。スロットアクセスは最適化される必要があり、その辺の解析が面倒なのも困る。(一般に、プログラムの定義域は狭いほうがコンパイラにはやさしい)