concepts.texi

@node Concepts, Programming in Gauche, Introduction, Top
@chapter Concepts
@c NODE 主要な概念

@c EN
In this chapter I describe a few Gauche's design concepts
that help you to understand how Gauche works.
@c JP
本章では、Gaucheの設計の背景となるいくつかの概念を説明します。
Gaucheの動作を正確に理解する助けになると思います。
@c COMMON

@menu
* Standard conformance::
* Multibyte strings::
* Multibyte scripts::
* Case-sensitivity::
* Integrated object system::
* Module system::
* Compilation::
@end menu

@node Standard conformance, Multibyte strings, Concepts, Concepts
@section Standard conformance
@c NODE 標準への準拠

@c EN
Gauche conforms ``Revised^7 Report of Algorithmic Language Scheme,''
(R7RS)
including optional syntax and procedures.  We cover R7RS small language
(@pxref{R7RS small language}), as well as part of R7RS large libraries
(@pxref{R7RS large}).
@c JP
Gaucheは、オプショナルな構文や手続きも含め
``Revised^7 Report of Algorithmic Language Scheme'' (R7RS) に準拠しています。
``R7RS small'' と呼ばれるコア言語(@ref{R7RS small language}参照)に加え、
``R7RS large'' ライブラリの一部をサポートします(@ref{R7RS large}参照)。
@c COMMON

@itemize @bullet
@item
@c EN
Gauche has a special kind of symbols, called keywords.
They're symbols with its name beginning with a colon
(e.g. @code{:key}), but behaves as if it is automatically bound to
itself.  @xref{Keywords}, for the details.
Keywords are used extensively when
passing so-called keyword arguments (@pxref{Making procedures}).
@c JP
Gaucheには、キーワードと呼ばれる特殊なシンボルがあります。
コロンで始まる名前(例:@code{:key})を持つシンボルはキーワードで、
自動的に自分自身に束縛されます。
詳しくは@ref{Keywords}を参照してください。
主にキーワード引数を渡すときに使われます(@ref{Making procedures}参照)。
@c COMMON

@item
@c EN
Continuations created in a certain situation
(specifically, inside a Scheme code that is called from external
C routine) have limited extent (@xref{Continuations}, for details).
@c JP
ある条件下で作られた継続は限られたエクステントを持ちます
(具体的には、Cのコードからコールバックとして呼ばれるSchemeコード内で作られる継続
がこれにあたります)。詳しくは@ref{Continuations}を参照して下さい。
@c COMMON

@item
@c EN
Full numeric tower (integer, rational, real and complex numbers) are supported,
but rationals are only exact, and complex numbers are always inexact.
@c JP
完全なNumeric tower(整数、有理数、実数、複素数)がサポートされますが、
有理数は正確な表現のみで、また複素数は非正確な表現のみを持ちます。
@c COMMON
@end itemize

@c EN
Note that, since Gauche predates R7RS, most existing Gauche source
code doesn't follow the R7RS program/library structure.  Gauche can
read both traditional Gauche modules/scripts and R7RS programs/libraries
seamlessly.
@xref{Library modules - R7RS standard libraries}, for the details of how R7RS
is integrated into Gauche.
@c JP
GaucheはR7RS以前から開発されているため、既存のGaucheソースコードの多くはR7RSの
プログラムやライブラリの構造に従っていないことに注意してください。
Gaucheは、伝統的なGaucheのモジュール形式やスクリプトも、R7RS形式のプログラムや
ライブラリも、両方解釈することができます。
R7RSがどのようにGaucheに統合されているかについては、
@ref{Library modules - R7RS standard libraries}を参照してください。
@c COMMON


@c EN
Gauche also supports the following SRFIs (Scheme Request for Implementation).
@c JP
Gaucheはまた、以下のSRFIをサポートしています。
@c COMMON

@table @asis
@c xinclude srfis.texi
@end table

@node Multibyte strings, Multibyte scripts, Standard conformance, Concepts
@section Multibyte strings
@c NODE マルチバイト文字列

@c EN
Traditionally, a string is considered as a simple array of bytes.
Programmers tend to imagine a string as a simple
array of characters (though a character may occupy more than one byte).
It's not the case in Gauche.
@c JP
従来、文字列は単なるバイトの配列として扱われてきました。
そのため一文字が複数バイトを占めるようになっても
文字列は単純な文字の配列であると考えられがちですが、
Gaucheにおいては、そうではありません。
@c COMMON

@c EN
Gauche supports @emph{multibyte string} natively,
which means characters are represented by variable number of bytes
in a string.  Gauche retains semantic compatibility of
Scheme string, so such details can be hidden, but it'll be helpful
if you know a few points.
@c JP
Gaucheは内部的に@emph{マルチバイト文字列}をサポートします。
すなわち、文字列中の文字が占めるバイト数は一定していません。
Schemeの文字列プリミティブのセマンティクスは保たれているので、
詳細を気にしないでもプログラムは書けますが、
下にあげるいくつかの点を知っておいたほうが良いでしょう。
@c COMMON

@c EN
A string object keeps a type tag and a pointer to the storage
of the string body.  The storage of the body is managed in a sort of
``copy-on-write''
way---if you take substring, e.g. using directly by @code{substring}
or using regular expression matcher, or even if you copy a string
by @code{copy-string}, the underlying storage is shared
(the ``anchor'' of the string is different, so the copied string
is not @code{eq?} to the original string).
The actual string is copied only if you destructively modify it.
@c JP
文字列オブジェクトは型タグと文字列本体へのポインタを保持しています。
文字列本体は「copy-on-write」方式で管理されます。すなわち、@code{substring}
や正規表現を使って部分文字列を切り出したり、あるいは単に文字列をコピーした場合、
文字列オブジェクトそのものは別につくられますが、文字列本体は共有されます。
文字列が破壊的に変更される場合にのみ、文字列本体がコピーされます。
@c COMMON

@c EN
Consequently the algorithm like pre-allocating a string by
@code{make-string} and filling it with @code{string-set!}
becomes @emph{extremely} inefficient in Gauche.  Don't do it.
(It doesn't work with mulitbyte strings anyway).
Sequential access of string is much more efficient
using @emph{string ports} (@pxref{String ports}).
@c JP
したがって、@code{make-string}である大きさの文字列をあらかじめアロケート
しておき、@code{string-set!}で順に埋めて行くようなアルゴリズムは
Gaucheでは非常に効率が悪くなります。そのようなアルゴリズムは使わない方が良いでしょう。
(そのようなアルゴリズムはマルチバイト文字列とも相性が良くありません)。
文字列を順に埋めて行く場合は@emph{string ports}を使うのが
効率の良い方法です (@ref{String ports}参照)。
@c COMMON

@c EN
String search primitives such as @code{string-scan} (@pxref{String utilities})
and regular expression matcher (@pxref{Regular expressions})
can return a matched string directly, without
using index access at all.
@c JP
@code{string-scan} (@ref{String utilities}参照) や正規表現
(@ref{Regular expressions}参照) など文字列を検索するプリミティブは、
インデックスを介さずに一致した文字列を直接返すことができます。
@c COMMON

@c EN
Conversions from other encoding scheme is provided
as a special port. @xref{Character code conversion}, for details.
@c JP
他の文字エンコーディングからの変換は特別なポートを使って行われます。
@ref{Character code conversion} を参照して下さい。
@c COMMON

@c EN
The way to specify the encoding of source programs will be
explained in the next section.
@c JP
ソースプログラムのエンコーディングを指定する方法については
次の章で説明します。
@c COMMON

@node Multibyte scripts, Case-sensitivity, Multibyte strings, Concepts
@section Multibyte scripts
@c NODE マルチバイトスクリプト

@c EN
You can use characters other than @code{us-ascii} not only in
literal strings and characters, but in comments, symbol names,
literal regular expressions, and so on.
@c JP
リテラル文字列や文字以外にも、コメント、シンボル名、
リテラル正規表現など様々な箇所で、@code{us-ascii}以外の文字を
使うことができます。
@c COMMON

@c EN
By default, Gauche assumes a Scheme program is written in utf-8.
If you need to write a source other than utf-8, however,
you can add the following ``magic comment'' near the beginning of
the source code:
@c JP
デフォルトでは、GaucheはSchemeプログラムをutf-8で書かれているものとして扱います。
もし何らかの事情でutf-8以外のエンコーディングでソースを書かなければならない場合、
コードの先頭付近に次のような特殊なコメントを置いておくことができます。
@c COMMON

@c EN
When Gauche finds a comment something like the following within
the first two lines of the program source, it assumes the rest of
the source code is written in @code{<encoding-name>}, and does
the appropriate character encoding conversion to read the source code:
@c JP
Gaucheは、次のようなコメントがプログラムソースコードの
2行目までに現れた場合、ソースコードの残りの部分が@code{<encoding-name>}で
指定されるエンコーディングで書かれているものとして、必要ならば
適切なエンコーディング変換を行います。
@c COMMON
@example
;; coding: <encoding-name>
@end example

@c EN
More precisely, a comment in either first or second line that matches
a regular expression @code{#/coding[:=]\s*([\w.-]+)/} is recognized,
and the first submatch is taken as an encoding name.
If there are multiple matches, only the first one is effective.
The first two lines must not contain characters other than us-ascii
in order for this mechanism to work.
@c JP
より正確には、1行目または2行目のコメントで、
正規表現@code{#/coding[:=]\s*([\w.-]+)/}にマッチするものがあった場合に、
最初の部分マッチがエンコーディング名として認識されます。
複数のマッチがあった場合は最初のものが有効になります。
このメカニズムを利用するためには、最初の2行以内にus-ascii以外の文字を
含めないようにして下さい。
@c COMMON

@c EN
The following example tells Gauche that the script is written
in EUC-JP encoding.   Note that the string "@code{-*-}" around the coding
would be recognized by Emacs to select the buffer's encoding
appropriately.
@c JP
例えば次の例では、Gaucheはスクリプトがeuc-jpで書かれているものと
認識します。coding指定の周囲の"@code{-*-}"は、Emacsが
バッファのエンコーディングを適切に設定するのに使われます。
@c COMMON

@example
#!/usr/bin/gosh
;; -*- coding: euc-jp -*-

... script written in euc-jp ...
@end example

@c EN
Internally, the handling of this @emph{magic comment} is done by
a special type of port.  See @ref{Coding-aware ports} for the
details.  See also @ref{Loading Scheme file} for how to disable
this feature.
@c JP
内部では、この特殊なコメントの処理は特別なポートによって
行われています。詳細は@ref{Coding-aware ports}を参照して下さい。
また、この処理を行わないようにする方法については
@ref{Loading Scheme file}を参照して下さい。
@c COMMON

@node Case-sensitivity, Integrated object system, Multibyte scripts, Concepts
@section Case-sensitivity
@c NODE 大文字小文字の区別

@c EN
Historically, most Lisp-family languages are case-insensitive
for symbols.  Scheme departed from this tradition since R6RS, and
the symbols are read in case-sensitive way.
(Note that symbols have been case-sensitive internally even in R5RS Scheme;
case-insensitivity is about readers.)
@c JP
Lisp系の言語は歴史的にシンボルの大文字小文字を区別していません。
しかしSchemeはR6RSからその伝統より離脱し、シンボルを読む際に大文字小文字を区別
するようになりました。(但し、R5RSの範囲内でも処理系内部では
大文字小文字を区別することになってます。
ここで問題としているのは読み込み時の動作です。)
@c COMMON

@c EN
Gauche reads and writes symbols in case-sensitive manner by default, too.
However, to support legacy code, you can set the reader to case-insensitive
mode, in the following ways:
@c JP
Gaucheの入出力ルーチンも、デフォルトではシンボルの大文字小文字を区別します。
ただし、古いコードとの互換性のために、リーダを大文字小文字を区別しないモードにすることが
できます。
@c COMMON

@table @asis
@c EN
@item Use @code{#!fold-case} reader directive
When Gauche sees a token @code{#!fold-case} during reading a program,
the reader switches to case-insensitive mode.  A token
@code{#!no-fold-case} has an opposite effect---to make the
reader case-sensitive.  These tokens affect the port
from which they are read, and are in effect until EOF
or another instance of these tokens are read.
See @ref{Lexical structure} for more details on @code{#!} syntax.
This is the way defined in R6RS and R7RS.
@c JP
@item @code{#!fold-case}リーダディレクティブを使う
Gaucheはプログラムを読み込む時に、トークン@code{#!fold-case}を見ると大文字小文字を
区別しないモードに切り替わります。トークン@code{#!no-fold-case}は
その逆の効果、すなわち大文字小文字を区別するモードへと切り替えます。
これらのトークンは、それが読まれたポートからの以降の読み込みに影響を
与えます。切り替えるトークンが再び読まれるか、EOFに出会うまで影響は継続します。
@code{#!}構文についてより詳しくは@ref{Lexical structure}を参照してください。
この動作はR6RS及びR7RSで規定されています。
@c COMMON

@c EN
@item Use @code{-fcase-fold} command-line argument
Alternatively, you can give a command-line argument @code{-fcase-fold}
to the @code{gosh} command (@pxref{Invoking Gosh}).
In this mode, the reader folds uppercase characters in symbols to lowercase
ones.  If a symbol name contains uppercase characters, it is written
out using |-escape (@pxref{Symbols}).
@c JP
@item @code{-fcase-fold}コマンドライン引数を使う
また、@code{gosh}インタプリタの起動時に@code{-fcase-fold}コマンドライン引数を
与えると、Gaucheは大文字小文字を区別しないモードで動作します (@ref{Invoking Gosh}参照)。
このモードでは、リーダはシンボルの読み込みの際に大文字を小文字に変換します。
大文字を含んでいるシンボルに関しては、`|' 文字でエスケープされて書き出されます
(@ref{Symbols}参照)。
@c COMMON
@end table


@node Integrated object system, Module system, Case-sensitivity, Concepts
@section Integrated object system
@c NODE 統合されたオブジェクトシステム

@c EN
Gauche has a STklos-style object system, similar to CLOS.
If you have used some kind of object oriented (OO) languages,
you'll find it easy to understand the basic usage:
@c JP
GaucheはCLOSに類似した、STklosスタイルのオブジェクトシステムを持っています。
あなたが何らかのオブジェクト指向(OO)言語を使ったことがあれば、
基本的な使い方は簡単にわかるでしょう。
@c COMMON

@example
@c EN
;; @r{Defines a class point, that has x and y coordinate}
@c JP
;; @r{x, y座標を持つpointクラスを定義}
@c COMMON
(define-class point ()
  ((x :init-value 0)
   (y :init-value 0))
  )

(define-method move ((p point) dx dy)
  (inc! (slot-ref p 'x) dx)
  (inc! (slot-ref p 'y) dy))

(define-method write-object ((p point) port)
  (format port "[point ~a ~a]"
          (slot-ref p 'x)
          (slot-ref p 'y)))
@end example

@c EN
However, if you are familiar with mainstream OO languages but new to CLOS-style
object system, Gauche's object system may look strange
when you look deeper into it.
Here I describe several characteristics of Gauche object system quickly.
@xref{Object system}, for details.
@c JP
しかし、主流のオブジェクト指向言語に慣れてはいるがCLOSスタイルのオブジェクトシステムに
慣れていないプログラマは、Gaucheのオブジェクトシステムの詳細を見てゆくと
奇妙に感じることがあるのではないかと思います。
ここではGaucheのオブジェクトシステムの代表的な性質を簡単に述べておきます。
詳しくは@ref{Object system}の章を参照して下さい。
@c COMMON

@table @emph
@c EN
@item Everything is an object (if you care)
You have seen this tagline for the other languages.
And yes, in Gauche, everything is an object in the sense that you can
query its class, and get various meta information of
the object at run time.  You can also define a new method
on any class, including built-in ones.

Note that, however, in CLOS-like paradigm it doesn't really matter
whether everything is an object or not, because of the following
characteristics:
@c JP
@item 全てはオブジェクトである (それが気になる人には)
このような主張は他のOO言語でも見たことがあるでしょう。
Gaucheもその例にもれず、実行時にクラスを得たりメソッドを呼び出したりといった
操作が任意のオブジェクトに対して出来るという意味で、全てはオブジェクトです。
また組込みクラスを含めたどんなクラスに対しても新しいメソッドを定義することができます。

しかし、CLOS系のパラダイムでは、全てがオブジェクトかどうかという議論はあまり
問題ではありません。というのは次のような性質があるからです。
@c COMMON

@c EN
@item Method is dispatched by all of its arguments.
Unlike other object-oriented languages such as C++, Objective-C,
Python, Ruby, etc., in which a method always belong to a single
class, a Gauche method doesn't belong to a specific class.

For example, suppose you define a numeric vector class
@code{<num-vector>} and a numeric matrix class @code{<num-matrix>}.
You can define a method @code{product} with all possible combinations
of those type of arguments:
@c JP
@item メソッドは全ての引数によってディスパッチされる
C++、Objective C、Python、RubyなどのOO言語では、メソッドは特定のクラスに
所属しています。Gaucheではメソッドはクラスに従属しません。

例えば、数値だけを要素に持つベクタークラス@code{<num-vector>}と
行列クラス@code{<num-matrix>}を定義したとします。
プログラマは、以下のようなあらゆる場合についてメソッド@code{product}を
別々に定義することができます。
@c COMMON

@example
  (product <num-vector> <num-matrix>)
  (product <num-matrix> <num-vector>)
  (product <num-vector> <num-vector>)
  (product <num-matrix> <num-matrix>)
  (product <number>     <num-vector>)
  (product <number>     <num-matrix>)
  (product <number>     <number>)
@end example

@c EN
Each method belongs to neither @code{<num-vector>} class nor
@code{<num-matrix>} class.

Since a method is not owned by a class, you can always define your
own method on the existing class (except a few cases
that the system prohibits altering pre-defined methods).  The above
example already shows it; you can make @code{product} method work
on the built-in class @code{<number>}.   That is why I said
it doesn't make much sense to discuss whether everything is object
or not in CLOS-style object system.
@c JP
これらの各メソッドは、@code{<num-vector>}クラスや@code{<num-matrix>}
クラスに所属するわけではありません。

メソッドがクラスに所有されているわけではないので、既に存在するクラスに対していつでも
独自のメソッドを定義することができます(但し、いくつかの組込みクラスの既定のメソッドには
変更できないものがあります)。上の例で既にこれは示されています。プログラマは
メソッド@code{product}を組込みクラス@code{<number>}に対して定義することが
できます。これが、全てはオブジェクトであるかどうかはCLOSスタイルのオブジェクトシステム
では問題にならないと言った理由です。
@c COMMON

@c EN
To step into the details a bit, the methods are belong to a
@emph{generic function}, which is responsible for dispatching
appropriate methods.
@c JP
少し詳しいことを言えば、メソッドは@emph{ジェネリック関数}に属しており、
ジェネリック関数が適切なメソッドを選ぶ役割を果たします。
@c COMMON

@c EN
@item Class is also an instance.
By default, a class is also an instance of class
@code{<class>}, and a generic function is an instance of class
@code{<generic>}.  You can subclass @code{<class>} to customize
how a class is initialized or how its slots are accessed.
You can subclass @code{<generic>} to customize how the
applicable methods are selected, which order those methods are
called, etc.   The mechanism is called @emph{metaobject protocol}.
Metaobject protocol allows you to extend the language by
the language itself.

To find examples, see the files @code{lib/gauche/singleton.scm} and
@code{lib/gauche/mop/validator.scm} included in the distribution.
You can also read @code{lib/gauche/mop/object.scm}, which actually
defines how a class is defined in Gauche.
For more details about metaobject protocol, see
Gregor Kiczales, Jim Des Rivieres, Daniel Bobrow,
The Art of Metaobject Protocol,
The MIT Press.
@c JP
@item クラスはインスタンスでもある
デフォルトでは、クラスは@code{<class>}というクラスのインスタンスであり、
ジェネリック関数は@code{<generic>}というクラスのインスタンスです。
しかし、@code{<class>}を継承したクラスを定義することにより、
オブジェクトの初期化がどのように行われるかとか、スロットがどのように
アクセスされるかといった動作をカスタマイズすることができます。
また、@code{<generic>}を継承したクラスを定義することにより、
適用可能なメソッドがどのように選択されて、どのような順序で適用されるか
といったことがカスタマイズ可能です。このメカニズムは@emph{メタオブジェクトプロトコル}
と呼ばれています。メタオブジェクトプロトコルは、言語をその言語そのもので拡張する方法と
言えるでしょう。

例として、ディストリビューションに含まれる@code{lib/gauche/mop/singleton.scm}や
@code{lib/gauche/mop/validator}等があります。@code{src/libobj.scm}を
読めば、クラス自身がGaucheでどのように定義されているかがわかります。
メタオブジェクトプロトコルの更に詳しいことについては、次の書籍が参考になります:
Gregor Kiczales, Jim Des Rivieres, Daniel Bobrow,
The Art of Metaobject Protocol,
The MIT Press.
@c COMMON

@c EN
@item Class doesn't create namespace
In the mainstream OO language, a class often creates its own namespace.
This isn't the case in CLOS-style object system.
In Gauche, a namespace is managed by the module system
which is orthogonal to the object system.
@c JP
@item クラスは名前空間を作らない
メインストリームのOO言語ではクラスが名前空間を作ることがよくあります。
CLOSスタイルのオブジェクトシステムはそうではありません。
Gaucheでは、名前空間はオブジェクトシステムとは直交する、
モジュールシステムによって管理されます。
@c COMMON

@end table

@node Module system, Compilation, Integrated object system, Concepts
@section Module system
@c NODE モジュールシステム

@c EN
Gauche has a simple module system that allows
modularized development of large software.
@c JP
Gaucheは大きなソフトウェアをモジュール化して開発するための、
単純なモジュールシステムを備えています。
@c COMMON

@c EN
A higher level interface is simple enough from the user's point
of view.   It works like this:
When you want to use the features provided by module
@code{foo}, you just need to say @code{(use foo)} in your code.
This form is a macro and interpreted at compile time.
Usually it loads the files that defines @code{foo}'s features,
and imports the external APIs into the calling module.
@c JP
高レベルのインタフェースを使うのはユーザにとっては非常に簡単です。
モジュール@code{foo}が提供する機能を使いたければ、
プログラム中で@code{(use foo)}と表記するだけです。
このフォームはマクロで、コンパイル時に解釈されます。
通常は、@code{foo}の機能を実装したファイルをロードし、
その外部APIを呼び出したモジュール中にインポートします。
@c COMMON

@c EN
The @code{use} mechanism is built on top of two independent
lower mechanisms, namespace separation and file loading mechanism.
Those two lower mechanisms can be used separately, although it is much more
convenient when used together.
@c JP
@code{use}メカニズムは、名前空間の分離とファイルローディングという
二つの独立な低レベルのメカニズムの上に実装されています。
これらの低レベルメカニズムはそれぞれ別々に使うこともできます。
@c COMMON

@c EN
The @code{use} mechanism is not transitive; that is,
if a module B uses a module A, and a module C uses the module B,
C doesn't see the bindings in A.  It is because B and A is not in the
@code{is-a} relationship.
Suppose the module A implements a low-level functionality and
the module B implements a high-level abstraction; if C is using
B, what C wants to see is just a high-level abstraction, and
doesn't concern how B implements such functionality.  If C wants
to access low-level stuff, C has to @code{use} A explicitly.
@c JP
@code{use}メカニズムは非遷移的です。すなわち、
モジュールBがモジュールAを'use'し、さらにモジュールCがモジュールBを
'use'している場合、モジュールCからはモジュールA内の束縛は見えません。
BとAは@code{is-a}関係ではないためです。
例えばモジュールAが低レベルの操作を実装し、
モジュールBがその上に高レベルの抽象的なインタフェースを実装しているとしましょう。
モジュールCがモジュールBを'use'しているということは、
CはBの提供する抽象レイヤに興味があるということです。
もしCがさらに低レベルの層にもアクセスしたいならば、CはAを明示的に'use'しなければ
なりません。
@c COMMON

@c EN
There is another type of relationship, though.  You might want to
take an exiting module A, and add some interface to it and provide
the resulting module B as an extension of A.  In such a case,
B is-a A, and it'd be natural that the module that uses B can also
see A's bindings.   In Gauche, it is called @emph{module inheritance}
and realized by @code{extend} form.
@c JP
しかし、別の形の関係が必要な場合もあります。例えば既存のモジュールAに
ちょっと新しいインタフェースを付け加えたモジュールBをAの拡張として
提供したいという場合です。この時、BとAは@code{is-a}関係であり、Bを'use'
しているモジュールからA内の束縛も見えるのが自然です。
Gaucheでは、これをモジュールの継承と呼び、
@code{extend}フォームにより実現しています。
@c COMMON

@c EN
The following sections in this manual describes
modules in details.
@itemize @bullet
@item
@ref{Writing Gauche modules} explains the convention of
writing modules.
@item
@ref{Modules} describes special forms and macros to
define and to use modules, along the built-in functions
to introspect module internals.
@end itemize
@c JP
以下のセクションでモジュールの機能について詳しく説明しています。
@itemize @bullet
@item
@ref{Writing Gauche modules} ではモジュールの書き方について
説明します。
@item
@ref{Modules} ではモジュールを定義したり使うための特殊形式とマクロ、
およびモジュールの内部を調べるための組込み手続きについて説明します。
@end itemize
@c COMMON

@node Compilation,  , Module system, Concepts
@section Compilation
@c NODE コンパイル

@c EN
By default, Gauche reads toplevel Scheme forms one at a time,
compile it immediately to intermediate form and execute it on the VM.
As long as you use Gauche interactively, it looks like an
interpreter.
(There's an experimental ahead-of-time compiler as well.
See @file{HOWTO-precompile.txt} if you want to give a try.)
@c JP
デフォルトでは、GaucheはSchemeのトップレベルフォームをひとつづつ読み、
直ちに中間コードへとコンパイルして仮想マシンで実行します。
Gaucheをインタラクティブに使っている限りは、インタプリタのように思えるでしょう。
(実験的なAOTコンパイラもあります。試してみたい方は
@file{HOWTO-precompile.txt}を見てください。)
@c COMMON

@c EN
The fact that we have separate compilation/execution phase, even
interleaved, may lead a subtle surprise if you think Gauche as an interpreter.
Here's a few points to keep in mind:
@c JP
コンパイルと実行のフェーズが分かれていることによって、
Gaucheをインタプリタと考えていると少々驚くことがあるかもしれません。
いくつか念頭に置いておくべき点をあげておきます。
@c COMMON

@table @emph
@c EN
@item load is done at run time.
@code{load} is a procedure in Gauche, therefore evaluated at run time.
If the loaded program defines a macro, which is available for the compiler
after the toplevel form containing @code{load} is evaluated.  So, suppose
@code{foo.scm} defines a macro @code{foo}, and you use the macro
like this:
@c JP
@item loadは実行時に評価される
@code{load}はGaucheでは一般の関数なので、実行時に評価されます。
ロードされるファイル中でマクロを定義している場合、そのマクロは
その@code{load}の呼び出しを含むトップレベルフォームが評価された後で
有効になります。例えば、@code{foo.scm}がマクロ@code{foo}を定義しているとして、
次のような用法を考えてみてください。
@c COMMON
@example
;; @r{in ``foo.scm''}
(define-syntax foo
  (syntax-rules () ((_ arg) (quote arg))))

;; @r{in your program}
(begin (load "foo") (foo (1 2 3)))
  @result{} @r{error, bad procedure: `1'}

(load "foo")
(foo (1 2 3)) @result{} '(1 2 3)
@end example
@c EN
The @code{(begin (load ...))} form fails,  because the compiler
doesn't know @code{foo} is a special form at the compilation time
and compiles @code{(1 2 3)} as if it is a normal procedure call.
The latter example works, however, since the execution
of the toplevel form @code{(load "foo")} is done before
@code{(foo (1 2 3))} is compiled.
@c JP
@code{begin}で@code{load}と@code{foo}の呼び出しを囲んだ場合、
コンパイラはまず@code{begin}全体をコンパイルします。その時点でマクロ
@code{foo}は定義されていませんから、これは評価時にエラーになります。
一方、後者では@code{load}が評価されてから@code{foo}がコンパイルされるので、
問題は起きません。
@c COMMON

@c EN
To avoid this kind of subtleties, use @code{require} or @code{use}
to load a program fragments.  Those are recognized by the compiler.
@c JP
このような混乱を避けるために、別のプログラムファイルを読み込む必要がある時は
@code{require}か@code{use}を使うことを勧めます。これらは構文であり、
コンパイラに認識されます。
@c COMMON

@c EN
@item require is done at compile time
On the other hand, since @code{require} and @code{use} is recognized
by the compiler, the specified file is loaded even if the form
is in the conditional expression.   If you really need to load
a file on certain condition, use @code{load} or do dispatch in macro
(e.g. @code{cond-expand} form (@pxref{Feature conditional}).)
@c JP
@item require はコンパイル時に評価される
上記の裏返しですが、@code{require}と@code{use}はコンパイル時に
解釈されます。したがって、@code{if}などの条件文のボディにこれらのフォームを
置いておいても、指定されたファイルは条件にかかわらず読み込まれてしまいます。
どうしてももし条件によって読み込むかどうかを変えたい場合は、@code{load}を使うか、
条件判断自体をマクロで行うようにしてください。
(例えば、@code{cond-expand}フォーム等を使って。(@ref{Feature conditional}参照))
@c COMMON
@end table

@c Local variables:
@c mode: texinfo
@c coding: utf-8
@c end: