空港や新幹線停車駅などの交通拠点から観光地を経由して主要宿泊地または交通拠点へ向かう（あるいはその逆）形態。バスガイドの乗務や途中観光地での見学時間を設定することなどからバスツアーの類型の一つとも言えるが、観光地での行動（食事や観光施設への入場）は任意となっており、旅行商品としてはあくまでもバスでの移動のみを提供する。旅行代理店が主催するため定期観光バスには該当せず、単純往復で運行されるものでもない。観光客誘致のために自治体や観光団体が主導する例がある。航空会社系の旅行会社（ANAセールスやジャルパック等）の募集型企画旅行商品の一部として組み込まれる場合もあり（写真の北海道リゾートライナーもそのようなケースがある）、高速ツアーバスとは異なる内容が多い。また、伊東園ホテルズ、湯快リゾート、大江戸温泉物語の送迎バスも観光地周遊型に分類される。
高速ツアーバス同様、貸切バスを利用しながら輸送に特化した旅行商品としては、スポーツ観戦やコンサートなどのイベント開催時にイベント参加者の交通の便を確保する目的で、周辺の都市から輸送するイベントツアーバスがある。この場合はイベントの主催者が提携する旅行代理店を斡旋し、その旅行代理店がスポット的な募集型企画旅行を主催する形を取る。遠方発着の場合は観戦・観劇チケットを含んで「バスツアー」として催行されることも多いが、最寄り駅からの交通の便確保のために観戦・観劇チケットを含まない形態のイベントツアーバスが催行される場合もある。尚、イベントツアーバスは、目的となるイベントの参加がツアー参加の条件に加えられ目的外利用が禁じられた。
1980年代初頭、北海道稚内市の北都観光が、路線申請するほどの数は見込めないが、確実に需要の存在する札幌と稚内を結ぶ会員制バスの運行を開始したのが始まりで、1984年1月には、道内の貸切バス活性化の一環として、北海道運輸局が会員制バスの運行を充実する方針を明らかにしたことから、札幌から北海道内の各地を結ぶ会員制バスが多数設定された。しかし、路線バスの免許秩序が乱れるという理由で疑問を呈されていた。この状況下で1984年5月に北都観光・銀嶺バスが札幌と留萌を結ぶ会員制バスの運行を開始し、これに対して北海道中央バスが北海道運輸局に対して北都観光の留萌線の運行を廃止させるように要請した。しかし、北都観光では「違法ではなく需要もある」と反発した。最終的に、北海道運輸局では1984年12月に、会員制定期バスに対しては当時の道路運送法24条の2（貸切免許による乗合運送の特別許可）を適用することとなり、それまで会員制定期バスを運行していたバス事業者に加えて沿岸バスが道路運送法24条の2に基づいて申請することとなった。これを受けて、運輸省では1986年6月10日に通達「一般貸切旅客自動車運送事業者による乗合旅客運送の許可について」（昭和61年6月10日地自第124号、地域交通局長から各地方運輸局長等あて通達）を示し、「運行区間が乗合バス事業者の路線と全部又は一部で重複し、取扱旅客につき競合関係が生ずる場合」などの条件に該当する場合、道路運送法24条の2の適用を指導することとなった。
Common Lisp と最も頻繁に比較対照されるのが Scheme である — これら二つは最も有名な LISP系言語だからだ。Scheme は Common Lisp よりも古く、同じ LISP の伝統から生みだされただけでなく、同じエンジニアのガイ・スティール・ジュニアが Common Lisp 委員会の議長を務めた。以前の多くのLispの方言や実装とは異なり、Common Lisp は Scheme と同様な、スコープは静的スコープのみを基本とする仕様である。ZetaLisp や Franz Lisp といった Common Lisp の設計に寄与した実装の多くは、インタプリタでは動的スコープを、コンパイラでは静的スコープ、という仕様になっていた。Schemeはそういったものとは異なり、静的スコープのみであった。Common Lisp は動的スコープをもサポートしているが、明示的な special 宣言が必要である。ANSI Common Lisp のインタプリタとコンパイラの間にはスコープに関しての相異点は全く存在しない。時々、Common Lisp は「Lisp-2」、Scheme は「Lisp-1」と呼ばれることがある。これは Common Lisp が関数名と変数名(2つ)にそれぞれ独立した名前を備えている事に起因した名前である。しかし、実際には Common Lisp は go タグやブロック名、loop キーワードなど多くの名前空間を持っているし、マクロをうまく使えば、構文的に名前空間を追加することも出来る。複数の名前空間に関するトレードオフについて、Common Lisp と Scheme のそれぞれを支持する論争が長いあいだ行われている。Scheme では変数名と関数名の衝突を避ける必要があるため、Scheme の関数はよく lis や lst、lyst といった関数名と衝突しないような引数名を取ることになる。一方 Common Lisp では引数として使う場合に、明示的に関数の名前空間を参照する必要がある。これは上にでてきた sort のサンプルのように一般的なことである。Common Lisp はまた、真偽値の扱いが Scheme とは異なっている。Scheme は真と偽の表現として #t と #f という特別な値を用いている。Common Lisp は、より古い LISP系言語の伝統に従ってシンボルの t と nilを使っている。Common Lisp においては、if のような条件式において任意の nil でない値が真として扱われる。このことは、いくつかのオペレータが述語として働くと同時に、後の計算に使うための有意な値を返すものとして動作する事を可能としている。Scheme の標準規格は 末尾再帰の最適化 を要求しているが、Common Lisp の規格はしていない。ほとんどの Common Lisp 実装は末尾再帰の最適化を提供するが、それでもプログラマーが最適化宣言を使った場合のみである場合が多い。それにも関わらず、一般的な Common Lisp のコーディングスタイルは Scheme スタイルで好まれるようなあらゆる場合に再帰を使うというやり方とは異なっている。Scheme プログラマが末尾再帰で表現するものを、Common Lisp プログラマーは do、dolist、loop、最近だと iterate パッケージを使って反復で表現する。