"BAZ"))とシンボル名を文字列で書かずにシンボルで書くことも可能です。baz))))のようなことになっていると考えれば良いでしょう。designatorでのシンボルの表記に各人割とこだわりがみられるので考察してみることにしました。文字列そのまま"FOO"、"BAR"等とそのまま書く流儀です。通な人がこの方式で書いてることがあります。メリットとされること余計なシンボルがインターンされないデメリットとされることリーダーの読み取りケースを変更した環境では上手い具合に馴染まないしかし、そんな特殊な状況のことを考えてコーディングする必要ってあるんですかね?シンボルfoo、bar等とそのまま書く流儀です。してて良さそうですが、案外少ないですメリットとされることすっきりしているリーダーのケースの設定が変化しても良い感じに馴染む(と思われている)デメリットとされることdefpackageしたパッケージに余計なシンボルがインターンされるdefpackageは、大抵cl-userでされることが多いですが、cl-userは作業用パッケージなので、多少汚染されても良いんじゃないかという気もしますね。キーワードシンボル:foo、:bar等と書く流儀です。等々リーダーのケースの設定が変化しても良い感じに馴染む(と思われている)デメリットとされることキーワードパッケージに余計なシンボルがインターンされるキーワードパッケージが汚染されると開発環境のキーワード補完でゴミが補完されることが多くなるので、案外cl-userが汚染されるより嫌かもしれないですね。自由(uninterned)シンボル#:foo、#:bar等と書く流儀です。これも割と見かける流儀です。自由(uninterned)シンボルは、不要になったらGCされるので、細かいことを気にする人に好まれています。メリットとされること余計なシンボルがインターンされないエディタで良い感じに色付けされるリーダーのケースの設定が変化しても良い感じに馴染む(と思われている)デメリットとされること#:がウザい第四の方法を考えてみた見た目がウザいので自由(uninterned)シンボルで書きたくない、パッケージも汚染したくない、というのを両立させるとしたら、一時パッケージを作成し、その中でdefpackageすれば良いでしょう。"FOO-META")SBCLならこんな風に書けたりもします。baz))まあ、でもめんどくさいですね。まとめファイルをロードする時に、暗黙のうちに*package*をcl-user、*readtable*を標準のリードテーブルであると仮定しているコードは、Quicklispの大半を占めますが、それに起因するバグも思いの外多いです(Quicklispのパッケージを1000パッケージ位ロードしてみると体験できます)作業用パッケージ(とリードテーブル)を作成して、そこでdefpackageするのが吉なのかなあ等々考えていますが、作業用パッケージを作成するなら、余計なシンボルのインターンについても考えなくて良さそうですね。ちなみにこの記事を書くにあたって、文字列、シンボル、キーワード、自由(uninterned)シンボルの大き目のリストを作成して読み取りの速度を計時してみましたが、大抵の処理系ではシンボルや文字列が速く、一番遅いのは自由(uninterned)シンボルのリストでした。読み取りスピード的にも普通のシンボルで書くのが有利っぽいですが、極端なことをしない限りは有意な差にはならないでしょう。以上、特にまとまりもない記事でした。