%% LyX 1.1 created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[11pt,english]{article}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{babel}
\setlength\parskip{\medskipamount}
\setlength\parindent{0pt}
\usepackage{url}

\makeatletter

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
 \newenvironment{lyxcode}
   {\begin{list}{}{
     \setlength{\rightmargin}{\leftmargin}
     \raggedright
     \setlength{\itemsep}{0pt}
     \setlength{\parsep}{0pt}
     \normalfont\ttfamily}%
    \item[]}
   {\end{list}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.

\usepackage[T1]{fontenc}
\usepackage{xspace}
\newcommand{\nach}{$\to$\xspace}
\newcommand{\hoch}{\texttt{$^\wedge$}}

\usepackage{html}

\newcommand{\doubledash}{-\hspace{0.1em}-}
\newcommand{\doubledashb}{-\/-}
\newcommand{\dlt}{{\footnotesize$\ll$}}
\newcommand{\dgt}{{\footnotesize$\gg$}}

\begin{htmlonly}

\renewenvironment{lyxcode}
  {\begin{list}{}{
    \setlength{\rightmargin}{\leftmargin}
    \raggedright
    \setlength{\itemsep}{0pt}
    \setlength{\parsep}{0pt}
    \ttfamily}%
   \item[] 
   \begin{ttfamily}}
   {\end{ttfamily}
    \end{list} }

\newenvironment{LyXParagraphIndent}[1]%
{\begin{quote}}
{\end{quote}}

\renewcommand{\LyX}{LyX}

\renewcommand{\doubledash}{\rawhtml --\endrawhtml}
\renewcommand{\doubledashb}{\rawhtml --\endrawhtml}
\renewcommand{\dlt}{«}
\renewcommand{\dgt}{»}

\renewcommand{\nach}{\rawhtml <i>to</i> \endrawhtml}
\renewcommand{\hoch}{\rawhtml &#94;\endrawhtml}

\end{htmlonly}

\makeatother
\begin{document}

\title{Aspell Devel Docs}


\author{Copyright (c) 2002\\
Kevin Atkinson\\
kevina@gnu.org}

\maketitle
\tableofcontents{}


\section*{Notes}

This manual is designed for those who which to developer Aspell. It
is currently very sketchy. However, it should improve over time. The
latest version of this document can be found at \url{http://savannah.gnu.org/download/aspell/manual/devel/devel.html}.

The eventual goal is to convert this manual into Texinfo. However,
since I do not have the time to learn Texinfo right now, I decided
to use something I am already conferable with. Once someone goes through
the trouble of converting it into Texinfo I will maintain the Texinfo
version.


\section*{Copyright}

Copyright (c) 2002 Kevin Atkinson. Permission is granted to copy,
distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.1 or any later version published
by the Free Software Foundation; with no Invariant Sections, no Front-Cover
Texts. and no Back-Cover Texts. A copy of the license is included
in the section entitled \char`\"{}GNU Free Documentation License\char`\"{}.


\section{Style Guidelines}

As far as coding styles go I am really not that picky. The important
thing is to stay consistent. However, please what ever you do, do
not indent with more than 4 characters as I find indenting with more
than that extremely difficult to read as most of the code ends up
on the right side of the window.


\section{C++ Standard Library}

The C++ Standard library is not used directly except under very specific
circumstances. The string class and the STL is used indirectly though
wrapper classes and all I/O is done using the standard C library with
light right helper classes to make using C I/O a bit more C++ like.

However the new, new{[}{]}, delete and delete{[}{]} operates are used
to allocated memory when appropriate.


\section{Templates}

Templates are used in Aspell when there is a clear advantage to doing
so. When ever you use templates please use them carefully and try
very hard not to create code bloat by generating a lot of unnecessary,
and duplicate code.


\section{Error Handling}

Exceptions are not used in Aspell as I find them more trouble than
they are worth. Instead an alternate method of error handling is used
which is based around the PosibErr class. PosibErr is a special Error
handling device that will make sure that an error is properly handled.
It is defined in {}``posib\_err.hpp''. PosibErr is expected to be
used as the return type of the function It will automatically convert
to the \char`\"{}normal\char`\"{} return type however if the normal
returned type is accessed and there is an \char`\"{}unhandled\char`\"{}
error condition it will abort It will also abort if the object is
destroyed with an \char`\"{}unhandled\char`\"{} error condition. This
includes ignoring the return type of a function returning an error
condition. An error condition is handled by simply checking for the
presence of an error, calling ignore, or taking ownership of the error.

The PosibErr class is used extensively though out Aspell. Please refer
to the Aspell source for examples of using PosibErr until better documentation
is written.


\section{Source Code Layout }

\begin{description}
\item [common/]Common code used by all parts of Aspell
\item [lib/]Library code used only by the actual Aspell library
\item [data/]Data files used by Aspell
\item [modules/]Aspell modules which are eventually meant to be pluggable

\begin{description}
\item [speller/]~

\begin{description}
\item [default/]Main speller Module.
\end{description}
\item [filter/]~
\item [tokenizer/]~
\end{description}
\item [auto/]Scripts and data files to automatically generate code used
by Aspell
\item [interface/]Header files and such that external programs should use
when in order to use the Aspell library.

\begin{description}
\item [cc/]The external {}``C'' interface that programs should be using
when they wish to use Aspell.
\end{description}
\item [prog/]Actual programs based on the Aspell library. The main {}``aspell''
utility is included here.
\item [scripts/]Misc. scripts used by Aspell
\item [manual/]~
\item [examples/]Example programs demonstrating the use of the Aspell library
\end{description}

\section{Strings}


\subsection{String}

The String class provided the same functionally of the C++ string
except for fewer constructors. It also inherits OStream so that you
can write to it with the {}``<\/<'' operator. It is defined in {}``string.hpp''.


\subsection{ParmString}

ParmString is a special string class that is designed to be used as
a parameter for a function that is expecting a string. It is defined
in {}``parm\_sting.hpp''. It will allow either a \char`\"{}const
char {*}\char`\"{} or \char`\"{}String\char`\"{} class to be passed
in. It will automatically convert to a \char`\"{}const char {*}\char`\"{}.
The string can also be accesses via the \char`\"{}str\char`\"{} method.
Usage example:

\begin{lyxcode}
void~foo(ParmString~s1,~ParmString~s2)~\{~\\
~~~const~char~{*}~str0~=~s1;~\\
~~~unsigned~int~size0~=~s2.size()~\\
~~~if~(s1~==~s2~||~s2~==~\char`\"{}bar\char`\"{})~\{~\\
~~~~~...~\\
~~~\}~\\
\}~\\
...~\\
String~s1~=~\char`\"{}...\char`\"{};~\\
foo(s1);~\\
const~char~{*}~s2~=~\char`\"{}...\char`\"{};~\\
foo(s2);
\end{lyxcode}
This class should be used when a string is being passed in as a parameter.
It is faster than using {}``const String \&'' (as that will create
an unnecessary temporary when a const char {*} is passed in), and
is less annoying than using {}``const char {*}'' (as it doesn't
require the c\_str() method to be used when a String is passed in).


\subsection{CharVector}

A character vector is basically a Vector<char> but it has a few additional
methods for dealing with strings which Vector does not provide. It,
like String, is also inherits OStream so that you can write to it
with the {}``<\/<'' operator. It is defined in {}``char\_vector.hpp''.
Use it when ever you need a string which is guaranteed to be in a
continuous block of memory which you can write to.


\section{Smart Pointers}

Smart pointers are used extensively in Aspell to avoid simplify memory
management tasks and to avoid memory leaks.


\subsection{CopyPtr}

The CopyPtr class makes a deep copy of an object when ever it is copied.
The CopyPtr class is defined in {}``copy\_ptr.hpp''. This header
should be included where ever CopyPtr is used. The complete definition
of the object CopyPtr is pointing to does not need to be defined at
this point. The implementation is defined in {}``copy\_ptr-t.hpp''.
The implementation header file should be included at a point in your
code where the class CopyPtr is pointing to is completely defined.


\subsection{ClonePtr}

ClonePtr is like copy pointer except the clone() method is used instead
of the copy constructor to make copies of an object. If is defined
in {}``clone\_ptr.hpp'' and implemented in {}``clone\_ptr-t.hpp''.


\subsection{StackPtr}

A StackPtr is designed to be used when ever the only pointer to a
new object allocated with \textbf{new} is on the stack. It is similar
to the standard C++ auto\_ptr but the semantics are a bit different.
It is defined in {}``stack\_ptr.hpp'' unlike CopyPtr of ClonePtr
it is defined and implemented in this header file.


\subsection{GenericCopyPtr}

A generalized version of CopyPtr and ClonePtr which the two are based
on. It is defined in {}``generic\_copy\_ptr.hpp'' and implemented
in {}``generic\_copy\_ptr-t.hpp''.


\section{I/O}

Aspell does not use C++ I/O classes and function in any way since
they do not provide a way to get at the underlying file number and
can often be slower than the highly tuned C I/O functions found in
the standard C library. However, some light weight wrapper classes
are provided so that standard C I/O can be used in a more C++ like
way.


\subsection{IStream/OStream}

These two base classes mimic some of the functionally of the C++ functionally
of the corresponding classes. They are defined in {}``istream.hpp''
and {}``ostream.hpp'' respectfully. They are however based on standard
C I/O and are not proper C++ streams.


\subsection{FStream}

Defined in {}``fstream.hpp''


\subsection{Standard Streams}

CIN/COUT/CERR. Defined in {}``iostream.hpp''.


\section{Config Class}

The Config class is used to hold configuration information. It has
a set of keys which it will except. Inserting or even trying to look
at a key that it does not know will produce an error. It is defined
in {}``common/config.hpp''


\section{Filter Interface}


\subsection{Overview}

In Aspell there are 5 types of filters:

\begin{enumerate}
\item \textbf{Decoders} which take input in some standard format such as
iso8859-1 or UTF-8 and convert it into a string of FilterChars.
\item \textbf{Decoding filters} which manipulates a string of FilterChars
by decoding the text is some way such as converting SGML character
into its Unicode value. 
\item \textbf{True filters} which manipulates a string of FilterChars to
make it more suitable for spell checking. These filers generally blank
out text which should not be spell checked
\item \textbf{Encoding filters} which manipulates a string of FilterChars
by encoding the text is some way such as converting certain Unicode
characters to SGML characters.
\item \textbf{Encoders} which take a string of FilterChars and convert into
a standard format such as iso8859-1 or UTF-8
\end{enumerate}
Which types of filters are used depends on the situation

\begin{enumerate}
\item When \textbf{decoding words} for spell checking:

\begin{itemize}
\item The \textbf{decoder} to convert from a standard format
\item The \textbf{decoding filter} to perform high level decoding if necessary
\item The \textbf{encoder} to convert into an internal format used by the
speller module
\end{itemize}
\end{enumerate}
\begin{itemize}
\item When \textbf{checking a document}

\begin{itemize}
\item The \textbf{decoder} to convert from a standard format
\item The \textbf{decoding filter} to perform high level decoding if necessary
\item A \textbf{true filter} to filter out parts of the document which should
not be spell checked
\item The \textbf{encoder} to convert into an internal format used by the
speller module
\end{itemize}
\end{itemize}
\begin{enumerate}
\item When \textbf{encoding words} such as those returned for suggestions:

\begin{itemize}
\item The \textbf{decoder} to convert from the internal format used by the
speller module
\item The \textbf{encoding filter} to perform high level encodings if necessary
\item The \textbf{encoder} to convert into a standard format
\end{itemize}
\end{enumerate}
A FilterChar is a struct defined in {}``common/filter\_char.hpp''
which contains two members, a character, and a width. Its purpose
is to keep track of the width of the character in the original format.
This is important because when a misspelled word is found the exact
location of the word needs to be returned to the application so that
it can highlight it for the user. For example if the filters translated
this:

\begin{lyxcode}
Mr.~foo~said~\&quot;I~hate~my~namme\&quot;.
\end{lyxcode}
to this

\begin{lyxcode}
Mr.~foo~said~\char`\"{}I~hate~my~namme\char`\"{}.
\end{lyxcode}
without keeping track of the original width of the characters the
application will likely highlight {}``e my '' as the misspelling
because the spell checker will return 25 as the offset instead of
30. However with keeping track of the width using FilterChar the spell
checker will now that the real position it 30 since the quote is really
6 characters wide. In particular the text will be annotated something
like the following:

\begin{lyxcode}
1111111111111611111111111111161~\\
Mr.~foo~said~\char`\"{}I~hate~my~namme\char`\"{}.
\end{lyxcode}
The standard \textbf{encoder} and \textbf{decoder} filters are defined
in {}``common/convert.cpp''. There should generally not be any need
to deal with them so they will not be discussed here. The other three
filters, the \textbf{encoding filter}, the \textbf{true filter}, and
the \textbf{decoding filter}, are all defined the exact same way;
they are inherited from the IndividualFilter class.


\subsection{Adding a New Filter}

To add a new filter create a new file in the modules/filter directory,
the file should be a C++ file and end in {}``.cpp''. The file should
contain a new filter class inherited from IndividualFilter, a function
to return a new filter, and an optional KeyInfo array for adding options
to control the behavior of the filter. The file then needs to be added
to Makefile.am so that the build system knows about the filter and
lib/new\_filter.cpp must be modified so that Aspell knows about the
filter.


\subsection{IndividualFilter class}

All filters are required to inherit from the IndividualFilter class
found in {}``indiv\_filter.hpp''. See that file for more details
and the other filter modules for examples of how it is used.


\subsection{Constructor Function}

After the class is created a function must to created which will return
a new filter allocated with \textbf{new}. The function must have the
following prototype:

\begin{lyxcode}
IndividualFilter~{*}~new\_\dlt{}filter\_name\dgt{}
\end{lyxcode}
Filters are defined in groups where each group contains an \textbf{encoding
filter}, a \textbf{true filter}, and a \textbf{decoding filter}. Only
one of them is required to be defined, however they all need a separate
constructor function.


\subsection{Config Options}

A filter group may have any number of options associated with it as
long as they all start with the filter name. See the \TeX{} and SGML
filter for examples of what to do and {}``config.hpp'' for the definition
of the KeyInfo struct.


\subsection{Makefile Modifications}

After the new file is created simply add the file to the {}``libaspell\_filter\_standard\_la\_SOURCES''
line in {}``modules/filter/Makefile.am'' so that the build system
knows about it.


\subsection{New\_filter Modifications}

Finally modify {}``lib/new\_filter.cpp'' so that Aspell knows about
the new filter. Follow the example there for the other filter modules.
The filter\_modules array should only be modified if there your filter
has config options.


\section{Data Structures}

When ever possible you should try to use on of the data structures
available. If the data structures do not provide enough functionally
for your needs you should consider enhancing them rather than written
something from scratch.


\subsection{Vector}

The vector class is defined in {}``vector.hpp'' and works the same
way as the standard STL vector does except that it doesn't have as
many constructors.


\subsection{BasicList}

BasicList is a simple list structure which can either be implemented
as a singly or doubly linked list. It is defined in {}``basic\_list.hpp''.


\subsection{StringMap}

StringMap is a associative array for strings. You should try to use
this when ever possible to avoid code bloat. It is defined in {}``string\_map.hpp''


\subsection{Hash Tables}

Several hash tables are provided when StringMap is not appropriate.
These hash tables provide a hash\_set, hash\_multiset, hash\_map and
hash\_multimap which are very similar to SGI STL's implementation
with a few exceptions. It is defined in {}``hash.hpp''


\subsection{BlockSList}

BlockSList provided a pool of nodes which can be used for singly linked
lists. It is defined in {}``block\_slist.hpp''.


\section{Mk-Src Script}

A good deal of interface code is automatically generated by the {}``mk-src.pl''
Perl script. I am doing it this way to avoid having to write a lot
of relative code for the C++ interface. This should also make adding
interface for other languages a lot less tedious and will allow the
interface to automatically take advantage of new Aspell functionality
as it is made available. The {}``mk-src.pl'' script uses {}``mk-src.in''
as its input.

\subsection{mk-src.in\label{mk-src_in}\index{mk-src.in}}


The format of mk-src.in is as follows:

\begin{verbatim}
  The following charaters are literals: { } / '\ ' \n = >
\end{verbatim}
\begin{verbatim}
  <items>
  <items> := (<item>\n)+
  <items> := <category>:\ <name> {\n<details>\n} | <<tab>><details>
  <details> := <options>\n /\n <items>
  <options> := (<option>\n)*
  <option> := <key> [=> <value>]
\end{verbatim}
\begin{verbatim}
  <<tab>> means everything should be indented by one tab
\end{verbatim}


See MkSrc::Info for a description of the categorys and options

\subsection{MkSrc::Info\label{MkSrc::Info}\index{MkSrc::Info}}
\subsubsection*{\%info\label{_info}\index{\%info}}


The info array contains information on how to process the info in 
mk-src.pl.  It has the following layout

\begin{verbatim}
   <catagory> => options => [] 
                 groups => [] # if undef than anything is accepted
                 creates_type => "" # the object will create a new type
                                    # as specified
                 proc => <impl type> => sub {}
\end{verbatim}


where <impl type> is one of:

\begin{verbatim}
  cc: for "aspell.h" header file
  cxx: for C++ interface implemented on top of cc interface
  native: for creation of header files used internally by aspell
  impl: for defination of functions declared in cc interface.
        the definations use the native hedaer files
  native_impl: for implementations of stuff declared in the native
                header files
\end{verbatim}


each proc sub should take the following argv

\begin{verbatim}
   $data: a subtree of $master_data
   $accum:
\end{verbatim}


<options> is one of:

\begin{verbatim}
  desc: description of the object
  prefix:
  posib err: the method may return an error condition
  c func:
  const: the method is a const member
  c only: only include in the external interface
  c impl headers: extra headers that need to be included in the C impl
  c impl: use this as the c impl instead of the default
  cxx impl: use this as the cxx impl instead of the default
  returns alt type: the constructor returns some type other than
    the object from which it is a member of
  no native: do not attemt to create a native implementation
  treat as object: treat as a object rather than a pointer
\end{verbatim}


The \%info structure is initialized as follows:

\begin{verbatim}
 our %info =
 (
  root => { 
    options => [],
    groups => ['methods', 'group']},
  methods => {
    # methods is a collection of methods which will be inserted into
    # a class after some simple substation rules.  A $ will be
    # replaced with name of the class.
    options => ['strip', 'prefix', 'c impl headers'],
    groups => undef},
  group => {
    # a group is a colection of objects which should be grouped together
    # this generally means they will be in the same source file
    options => ['no native'],
    groups => ['enum', 'struct', 'union', 'func', 'class', 'errors']},
  enum => {
    # basic C enum
    options => ['desc', 'prefix'],
    creates_type => 'enum'},
  struct => {
    # basic c struct
    options => ['desc', 'treat as object'],
    groups => undef,
    creates_type => 'struct',},
  union => {
    # basic C union
    options => ['desc', 'treat as object'],
    groups => undef,
    creates_type => 'union'},
  class => {
    # C++ class
    options => ['c impl headers'],
    groups => undef,
    creates_type => 'class'},
  errors => {}, # possible errors
  method => {
    # A class method
    options => ['desc', 'posib err', 'c func', 'const',
                'c only', 'c impl', 'cxx impl'],
    groups => undef},
  constructor => {
    # A class constructor
    options => ['returns alt type', 'c impl', 'desc'],
    groups => 'types'},
  destructor => {
    # A class destructor
    options => [],
    groups => undef},
  );
\end{verbatim}


In addition to the categories listed above a "methods" catagory by
be specified in under the class category.  A "methods" catagory is
created for each methods group under the name "<methods name> methods"
When groups is undefined a type name may be specified in place of
a category

\subsubsection*{\%types\label{_types}\index{\%types}}


types contains a master list of all types.  This includes basic types
and ones created in mk-src.in. The basic types include:

\begin{verbatim}
     'void', 'bool', 'pointer', 'double',
     'string', 'encoded string', 'string obj',
     'char', 'unsigned char',
     'short', 'unsigned short',
     'int', 'unsigned int',
     'long', 'unsigned long'
\end{verbatim}
\subsubsection*{\%methods\label{_methods}\index{\%methods}}


\%methods is used for holding the "methods" information

\subsection{MkSrc::Util\label{MkSrc::Util}\index{MkSrc::Util}}


This module contains various useful utility functions:

\begin{description}

\item[false] \mbox{}

Returns 0.


\item[true] \mbox{}

Returns 1.


\item[cmap EXPR LIST] \mbox{}

Apply EXPR to each item in LIST and than concatenate the result into
a string


\item[one\_of STR LIST] \mbox{}

Returns true if LIST contains at least one of STR.


\item[to\_upper STR] \mbox{}

Convert STR to all uppercase and substitute spaces with underscores.


\item[to\_lower STR] \mbox{}

Convert STR to all lowercase and substitute spaces with underscores.


\item[to\_mixed STR] \mbox{}

Convert STR to mixed case where each new word startes with a
uppercase letter.  For example "feed me" would become "FeedMe".

\end{description}
\subsection{MkSrc::Read\label{MkSrc::Read}\index{MkSrc::Read}}
\begin{description}

\item[read] \mbox{}

Read in "mk-src.in" and returns a data structure which has the
following format:

\begin{verbatim}
    <tree>
    <tree> := <options>
              data => <tree>
  where each tree represents an entry in mk-src.in.  
  The following two options are always provided:
    name: the name of the entry
    type: the catagory or type name
  Additional options are the same as specified in %info
\end{verbatim}
\end{description}
\subsection{MKSrc::Create\label{MKSrc::Create}\index{MKSrc::Create}}
\begin{description}

\item[create\_cc\_file PARMS] \mbox{}

Create a source file.

\begin{verbatim}
  Required Parms: type, dir, name, data
   Boolean Parms: header, cxx
  Optional Parms: namespace (required if cxx), pre_ext, accum
\end{verbatim}

\item[create\_file FILENAME DATA] \mbox{}

Writes DATA to FILENAME but only if DATA differs from the content of
the file and the string:

\begin{verbatim}
    Automatically generated file.
\end{verbatim}


is present in the existing file if it already exists.

\end{description}
\subsection{Code Generation Modes\label{Code_Generation_Modes}\index{Code Generation Modes}}


The code generation modes are currently one of the following:

\begin{verbatim}
  cc: Mode used to create types suitable for C interface
  cc_cxx: Like cc but typenames don't have a leading Aspell prefix
  cxx: Mode used to create types suitable for CXX interface
  native: Mode in which types are suitable for the internal implementation
  native_no_err: Like Native but with out PosibErr return types
\end{verbatim}
\subsection{MkSrc::CcHelper\label{MkSrc::CcHelper}\index{MkSrc::CcHelper}}


Helper functions used by interface generation code:

\begin{description}

\item[to\_c\_return\_type ITEM] \mbox{}

.


\item[c\_error\_cond ITEM] \mbox{}

.


\item[make\_func NAME @TYPES PARMS ; \%ACCUM] \mbox{}

Creates a function prototype



Parms can be any of:

\begin{verbatim}
  mode: code generation mode
\end{verbatim}

\item[call\_func NAME @TYPES PARMS ; \%ACCUM] \mbox{}

Return a string to call a func.  Will prefix the function with return
if the functions returns a non-void type;



Parms can be any of:

\begin{verbatim}
  mode: code generation mode
\end{verbatim}

\item[to\_type\_name ITEM PARMS ; \%ACCUM] \mbox{}

Converts item into a type name.



Parms can be any of:

\begin{verbatim}
  mode: code generation mode
  use_type: include the actual type
  use_name: include the name on the type
  pos: either "return" or "other"
\end{verbatim}

\item[make\_desc DESC ; LEVEL] \mbox{}

Make a C comment out of DESC optionally indenting it LEVEL spaces.


\item[make\_c\_method CLASS ITEM PARMS ; \%ACCUM] \mbox{}

Create the phototype for a C method which is really a function.



Parms is any of:

\begin{verbatim}
  mode: code generation mode
  no_aspell: if true do not include aspell in the name
  this_name: name for the paramater representing the current object
\end{verbatim}

\item[call\_c\_method CLASS ITEM PARMS ; \%ACCUM] \mbox{}

Like make\_c\_method but instead returns the appropriate string to call
the function.  If the function returns a non-void type the string will
be prefixed with a return statement.


\item[form\_c\_method CLASS ITEM PARMS ; \%ACCUM] \mbox{}

Like make\_c\_method except that it returns the array:

\begin{verbatim}
  ($func, $data, $parms, $accum)
\end{verbatim}


which is suitable for passing into make\_func.  It will return an 
empty array if it can not make a method from ITEM.


\item[make\_cxx\_method ITEM PARMS ; \%ACCUM] \mbox{}

Create the phototype for a C++ method.



Parms is one of:

\begin{verbatim}
  mode: code generation mode
\end{verbatim}
\end{description}


% fdl.tex 
% This file is a section.  It must be included in a larger document to work
% properly.

\section{GNU Free Documentation License}

Version 1.1, March 2000\\

 Copyright \copyright\ 2000  Free Software Foundation, Inc.\\
     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA\\
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

\subsection*{Preamble}

The purpose of this License is to make a manual, textbook, or other
written document ``free'' in the sense of freedom: to assure everyone
the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially.  Secondarily,
this License preserves for the author and publisher a way to get
credit for their work, while not being considered responsible for
modifications made by others.

This License is a kind of ``copyleft'', which means that derivative
works of the document must themselves be free in the same sense.  It
complements the GNU General Public License, which is a copyleft
license designed for free software.

We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does.  But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book.  We recommend this License
principally for works whose purpose is instruction or reference.

\subsection{Applicability and Definitions}

This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be distributed
under the terms of this License.  The ``Document'', below, refers to any
such manual or work.  Any member of the public is a licensee, and is
addressed as ``you''.

A ``Modified Version'' of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.

A ``Secondary Section'' is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
within that overall subject.  (For example, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.)  The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding
them.

The ``Invariant Sections'' are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License.

The ``Cover Texts'' are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License.

A ``Transparent'' copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input
to text formatters.  A copy made in an otherwise Transparent file
format whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent.  A copy that is
not ``Transparent'' is called ``Opaque''.

Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, \LaTeX~input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML designed for human modification.  Opaque formats include
PostScript, PDF, proprietary formats that can be read and edited only
by proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the
machine-generated HTML produced by some word processors for output
purposes only.

The ``Title Page'' means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page.  For works in
formats which do not have any title page as such, ``Title Page'' means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.


\subsection{Verbatim Copying}

You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License.  You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute.  However, you may accept
compensation in exchange for copies.  If you distribute a large enough
number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and
you may publicly display copies.


\subsection{Copying in Quantity}

If you publish printed copies of the Document numbering more than 100,
and the Document's license notice requires Cover Texts, you must enclose
the copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover.  Both covers must also clearly and legibly identify
you as the publisher of these copies.  The front cover must present
the full title with all words of the title equally prominent and
visible.  You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.

If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location containing a complete
Transparent copy of the Document, free of added material, which the
general network-using public has access to download anonymously at no
charge using public-standard network protocols.  If you use the latter
option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this
Transparent copy will remain thus accessible at the stated location
until at least one year after the last time you distribute an Opaque
copy (directly or through your agents or retailers) of that edition to
the public.

It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the Document.


\subsection{Modifications}

You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it.  In addition, you must do these things in the Modified Version:

\begin{itemize}

\item Use in the Title Page (and on the covers, if any) a title distinct
   from that of the Document, and from those of previous versions
   (which should, if there were any, be listed in the History section
   of the Document).  You may use the same title as a previous version
   if the original publisher of that version gives permission.
\item List on the Title Page, as authors, one or more persons or entities
   responsible for authorship of the modifications in the Modified
   Version, together with at least five of the principal authors of the
   Document (all of its principal authors, if it has less than five).
\item State on the Title page the name of the publisher of the
   Modified Version, as the publisher.
\item Preserve all the copyright notices of the Document.
\item Add an appropriate copyright notice for your modifications
   adjacent to the other copyright notices.
\item Include, immediately after the copyright notices, a license notice
   giving the public permission to use the Modified Version under the
   terms of this License, in the form shown in the Addendum below.
\item Preserve in that license notice the full lists of Invariant Sections
   and required Cover Texts given in the Document's license notice.
\item Include an unaltered copy of this License.
\item Preserve the section entitled ``History'', and its title, and add to
   it an item stating at least the title, year, new authors, and
   publisher of the Modified Version as given on the Title Page.  If
   there is no section entitled ``History'' in the Document, create one
   stating the title, year, authors, and publisher of the Document as
   given on its Title Page, then add an item describing the Modified
   Version as stated in the previous sentence.
\item Preserve the network location, if any, given in the Document for
   public access to a Transparent copy of the Document, and likewise
   the network locations given in the Document for previous versions
   it was based on.  These may be placed in the ``History'' section.
   You may omit a network location for a work that was published at
   least four years before the Document itself, or if the original
   publisher of the version it refers to gives permission.
\item In any section entitled ``Acknowledgements'' or ``Dedications'',
   preserve the section's title, and preserve in the section all the
   substance and tone of each of the contributor acknowledgements
   and/or dedications given therein.
\item Preserve all the Invariant Sections of the Document,
   unaltered in their text and in their titles.  Section numbers
   or the equivalent are not considered part of the section titles.
\item Delete any section entitled ``Endorsements''.  Such a section
   may not be included in the Modified Version.
\item Do not retitle any existing section as ``Endorsements''
   or to conflict in title with any Invariant Section.

\end{itemize}

If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant.  To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.

You may add a section entitled ``Endorsements'', provided it contains
nothing but endorsements of your Modified Version by various
parties -- for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.

You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version.  Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity.  If the Document already
includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of,
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.


\subsection{Combining Documents}

You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice.

The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy.  If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled ``History''
in the various original documents, forming one section entitled
``History''; likewise combine any sections entitled ``Acknowledgements'',
and any sections entitled ``Dedications''.  You must delete all sections
entitled ``Endorsements.''


\subsection{Collections of Documents}

You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.



\subsection{Aggregation With Independent Works}

A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version
of the Document, provided no compilation copyright is claimed for the
compilation.  Such a compilation is called an ``aggregate'', and this
License does not apply to the other self-contained works thus compiled
with the Document, on account of their being thus compiled, if they
are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one quarter
of the entire aggregate, the Document's Cover Texts may be placed on
covers that surround only the Document within the aggregate.
Otherwise they must appear on covers around the whole aggregate.


\subsection{Translation}

Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections.  You may include a
translation of this License provided that you also include the
original English version of this License.  In case of a disagreement
between the translation and the original English version of this
License, the original English version will prevail.


\subsection{Termination}

You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License.  Any other attempt to
copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License.  However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.


\subsection{Future Revisions of This License}

The Free Software Foundation may publish new, revised versions
of the GNU Free Documentation License from time to time.  Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation.  If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.

\subsection*{ADDENDUM: How to use this License for your documents}

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and
license notices just after the title page:

\begin{quote}

      Copyright \copyright\ YEAR  YOUR NAME.
      Permission is granted to copy, distribute and/or modify this document
      under the terms of the GNU Free Documentation License, Version 1.1
      or any later version published by the Free Software Foundation;
      with the Invariant Sections being LIST THEIR TITLES, with the
      Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
      A copy of the license is included in the section entitled ``GNU
      Free Documentation License''.

\end{quote}

If you have no Invariant Sections, write ``with no Invariant Sections''
instead of saying which ones are invariant.  If you have no
Front-Cover Texts, write ``no Front-Cover Texts'' instead of
``Front-Cover Texts being LIST''; likewise for Back-Cover Texts.

If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License,
to permit their use in free software.


\end{document}