     [file front.txi not included]

This is the reference manual for the STAMP program.

Introduction to the STAMP program
*********************************

This manual describes STAMP, a computer program for adapting text in conjunction with the AMPLE program.  This combination falls under the Analysis Transfer Synthesis (ATS) paradigm.  It involves the following steps:

(1) AMPLE is a morphological parser that is applied to source language text to analyze each word into morphemes.

(2) STAMP is applied to these analyses to make changes that will produce the corresponding target language word.

(3) An interactive editor is applied to STAMP output to correct the words that AMPLE failed to analyze and for which AMPLE and STAMP produced multiple possibilities.  The result is a word-for-word draft of the source language text in the target language.

(4) After eliminating analysis failures and ambiguities, the text must be checked and corrected by a competent speaker of the target language.

STAMP incorporates no language-specific facts; the user makes linguistic facts known to STAMP entirely through external files.  STAMP is sufficiently general to serve over a wide range of language families. (However, AMPLE and STAMP do not adequately handle highly isolating languages, that is, languages which have virtually no morphology.)

The name STAMP is derived by taking AMP from AMPLE, and T and S from STAMP's main modules, TRANSFER and SYNTHESIS, which are applied in succession to the output of AMPLE.  Thus one can think of STAMP as S(T(AMP)), or more explicitly as:

     adapted text = Synthesis[Transfer[AMPLE[source text]]]

Note: much of this reference manual is based almost verbatim on the book published in 1990 (Weber, Black, McConnel, and Buseman), without explicit permission from the coauthors.

New features
............

1. Version 2.1 (May 1999) introduced punctuation environment constraints in the allomorph fields of the dictionary files.  These are handled by a new built-in test called PEC_ST.  This version also added two punctuation-oriented clauses to user-written tests.

Running STAMP
*************

STAMP is a batch process oriented program.  It reads a number of control files, and then processes one or more input analysis files to produce an equal number of output files.

STAMP Command Options
=====================

The STAMP program uses an old-fashioned command line interface following the convention of options starting with a dash character (-).  The available options are listed below in alphabetical order.  Those options which require an argument have the argument type following the option letter.

-a
     causes all possible syntheses to be generated.

-c character
     selects the control file comment character.  The default is the vertical bar (|).

-d number
     selects the maximum dictionary trie depth.  The default is 2, which favors reduced memory needs over speed.

-f filename
     opens a command file containing the names of the control and data files.  The default is to read those names from the standard input (keyboard); see Interaction.

-i filename
     selects a single input analysis file.

-m
     monitors progress of an analysis: * means an analysis failure, . means a single analysis, 2endash9 means 2endash9 ambiguities, and > means 10 or more ambiguities. This is not compatible with the -q option.

-n
     prevents root categories from being checked.

-o filename
     selects a single output text (or analysis if the -x option is also selected) file.

-q
     causes AMPLE to operate ``quietly'' with minimal screen output.  This is not compatible with the -m option.

-r
     causes morphnames that are not found in the dictionary to be reported.

-t
     causes the transfer and synthesis processes to be traced.  This produces a huge amount of output.

-u
     signals that dictionaries are unified, not split into prefix, infix, suffix, and root files.

-v
     verifies tests by pretty printing the parse trees.

-x
     restricts STAMP to only the transfer process.

The following options exist only in beta-test versions of the program, since they are used only for debugging.

-/
     increments the debugging level.  The default is zero (no debugging output).

-z filename
     opens a file for recording a memory allocation log.

-Z address,count
     traps the program at the point where address is allocated or freed for the count'th time.

Program Interaction
===================

If the -f, -i, and -o command options are not used, STAMP prompts for a number of file names, reading the standard input for the desired values.  The interactive dialog goes like this:

     C> stamp
     STAMP: Synthesis(Transfer(AMPle(text))) = adapted text
     Version 2.0b1 (July 21, 1998), Copyright 1998 SIL, Inc.
     Beta test version compiled Jul 27 1998 16:04:11
            Transfer/Synthesis Performed Tue Jul 28 14:54:04 1998
     STAMP declarations file (zzSTAMP.DEC): pnstamp.dec
     Transfer file (xxzzTR.CHG) [none]: hgpntr.chg
     Synthesis file (zzSYNT.CHG) [none]: pnsynt.chg
     Dictionary code table (zzSYCD.TAB): pnsycd.tab
     Dictionary orthography change table (zzORDC.TAB) [none]: pnordc.tab
     	10 changes loaded from suffix dictionary code table.
     Suffix dictionary file (zzSF01.DIC): pnsf01.dic
             SUFFIX DICTIONARY: Loaded 137 records
     	10 changes loaded from root dictionary code table.
     Root dictionary file (xxRTnn.DIC): pnsyrt.dic
             ROOT DICTIONARY: Loaded 176 records
     Next Root dictionary file (xxRTnn.DIC) [no more]:
     Output text control file (zzOUTTX.CTL) [none]: pnoutx.ctl
     10 output orthography changes were loaded from pnoutx.ctl

     First Input file: pntest.ana
     Output file: pntest.syn

     Next Input file (or RETURN if no more):
     C>

Note that each prompt contains a reminder of the expected form of the answer in parentheses and ends with a colon.  Several of the prompts also contain the default answer in brackets.

Using the command options does not change the appearance of the program screen output significantly, but the program displays the answers to each of its prompts without waiting for input.  Assume that the file pntest.cmd contains the following, which is the same as the answers given above:

     pnstamp.dec
     hgpntr.chg
     pnsynt.chg
     pnsycd.tab
     pnordc.tab
     pnsf01.dic
     pnsyrt.dic

     pnoutx.ctl

Then running STAMP with the command options produces screen output like the following:

     C> stamp -f pntest.cmd -i pntest.ana -o pntest.syn
     STAMP: Synthesis(Transfer(AMPle(text))) = adapted text
     Version 2.0b1 (July 21, 1998), Copyright 1998 SIL, Inc.
     Beta test version compiled Jul 27 1998 16:04:11
            Transfer/Synthesis Performed Tue Jul 28 14:59:34 1998
     STAMP declarations file (zzSTAMP.DEC): pnstamp.dec
     Transfer file (xxzzTR.CHG) [none]: hgpntr.chg
     Synthesis file (zzSYNT.CHG) [none]: pnsynt.chg
     Dictionary code table (zzSYCD.TAB): pnsycd.tab
     Dictionary orthography change table (zzORDC.TAB) [none]: pnordc.tab
     	10 changes loaded from suffix dictionary code table.
     Suffix dictionary file (zzSF01.DIC): pnsf01.dic
             SUFFIX DICTIONARY: Loaded 137 records
     	10 changes loaded from root dictionary code table.
     Root dictionary file (xxRTnn.DIC): pnsyrt.dic
             ROOT DICTIONARY: Loaded 176 records
     Next Root dictionary file (xxRTnn.DIC) [no more]:
     Output text control file (zzOUTTX.CTL) [none]: pnoutx.ctl
     10 output orthography changes were loaded from pnoutx.ctl

     C>

The only difference in the screen output is that the prompts for the input text file and the output analysis file are not displayed.

Standard format
***************

     [file stdfmt.txi not included]

STAMP Declarations File
***********************

The fields that STAMP recognizes in its "declarations file" are described below.  Fields that start with any other backslash codes are ignored by STAMP.

Analytic ambiguity delimiter: \ambig
====================================

When AMPLE produces more than one analysis, each analysis is set off by a unique character.  Likewise, when AMPLE fails to analyze a source language word, it flags this word with the same character, the default for which is a percent sign (%).  However, a user may override AMPLE's default.

Like AMPLE, STAMP assumes this delimiter to be a percent sign.  If an analyzed text does not use this character, STAMP must be informed as to what character was used.  To do this, use the \ambig field to define the desired character.  For example, the following would change the analytic ambiguity delimiter to @:

     \ambig @

Allomorph property declaration: \ap
===================================

Allomorph properties are defined by the field code \ap followed by one or more allomorph property names.  An allomorph property name must be a single, contiguous sequence of printing characters. Characters and words which have special meanings in tests should not be used.  For example, the following would declare the allomorph properties deletedK, deletedG, and underlyingV:

     \ap deletedK deletedG  | elided morpheme final velars
     \ap underlyingV        | underlying long vowel

A maximum of 255 properties (including both allomorph and morpheme properties) may be defined unless the \maxprops field is used to define a larger number.  Any number of \ap fields may be used so long as the number of property names does not exceed 255 (or the number defined by the \maxprops field).  Note that any \maxprops field must occur before any \ap or \mp fields.

Category declarations: \ca
==========================

Categories are defined by the field code \ca followed by one or more category names.  A category name must be a single, contiguous sequence of printing characters.  Characters and words which have special meanings in tests should not be used.

A maximum of 255 categories may be defined.  Any number of \ca fields may be used so long as the number of category names does not exceed 255.

Category output control: \cat
=============================

The category information to write to the analysis output file is defined by the field code \cat followed by one or two words. The first word must be either prefix or suffix (or an abbreviation of one of those words), either capitalized or lowercase.

The \cat field may appear any number of times, but once is enough.  If more than one such field occurs, the last one is the one that is used.

NOTE: at present, this does not do anything in the code.  Is this a feature that has never been used?  When was it introduced?  I'd be quite willing to rip it out of the code.

Category class declaration: \ccl
================================

A category class declaration has three parts: the field code \ccl, the name of the class, and the list of categories in the class (separated by spaces).  For example, the following defines the class IVERB containing the categories V1X and V1Y:

     \ccl IVERB V1X V1Y

The class name must be a single, contiguous sequence of printing characters.  Characters and words which have special meanings in tests should not be used.  The category names must have been defined by an earlier \ca field; see \ca.

In transfer, category classes can only be used in the match strings of lexical changes; see \lc.

Each \ccl field defines a single category class.  Any number of \ccl fields may appear in the file.

Maximum number of properties: \maxprops
=======================================

The maximum number of properties that can be defined can be increased from the default of 255 by giving the \maxprops field code followed by a number greater than or equal to 255 but less than 65536.

The \maxprops field may appear any number of times, but once is enough.  If more than one such field occurs, the one containing the largest valid value is the one that is used.

The \maxprops must be used before any properties are defined. This is the case for both morpheme and allomorph properties.

If no \maxprops fields appear in the declarations file, then STAMP limits the number of properties which can be defined to 255.

Morpheme class declaration: \mcl
================================

A morpheme class declaration has three parts: the field code \mcl, the name of the class, and the list of morphnames in the class (separated by spaces).  For example, a morpheme class DIRECTION could be defined as follows:

     \mcl DIRECTION UP DOWN IN OUT

Such a class could be used in conditioning environments for lexical changes, insertion rules, or substitution rules.  For example, the following environment would limit the rule to apply only preceding one of the directional morphemes:

     / _ [DIRECTION]

The class name must be a single, contiguous sequence of printing characters.  Characters and words which have special meanings in tests should not be used.  The morpheme names should be defined by an entry in one of the dictionary files.

Each \mcl field defines a single morpheme class.  Any number of \mcl fields may appear in the file.

Morpheme property declaration: \mp
==================================

Morpheme properties are defined by the field code \mp followed by one or more morpheme property names.  A morpheme property name must be a single, contiguous sequence of printing characters.  Characters and words which have special meanings in tests should not be used.  For example, the following would declare the morpheme properties XYZ, ABC, and DEF:

     \mp XYZ
     \mp ABC DEF

A maximum of 255 properties (including both allomorph and morpheme properties) may be defined unless the \maxprops field is used to define a larger number.  Any number of \mp fields may be used so long as the number of property names does not exceed 255 (or the number defined by the \maxprops field).  Note that any \maxprops field must occur before any \mp or \ap fields.

Punctuation class: \pcl
=======================

A punctuation class is defined by the field code \pcl followed by the class name, which is followed in turn by one or more punctuation characters or (previously defined) punctuation class names.  A punctuation class name used as part of the class definition must be enclosed in square brackets.

The class name must be a single, contiguous sequence of printing characters.  The individual members of the class are separated by spaces, tabs, or newlines.

Each \pcl field defines a single punctuation class.  Any number of \pcl fields may appear in the file.

If no \pcl fields appear in the declarations file, then STAMP does not allow any punctuation classes in tests, and does not allow any punctuation classes in punctuation environment constraints.

Root delimiter: \rd
===================

For each analysis, the root (or roots), and the category of the first root, are delimited by a pair of reserved characters.  By default, AMPLE uses wedges (< and >).  If some characters other than wedges are used for this purpose, they must be declared using the \rd field.  (\rd is mnemonic for "root delimiter".)  For example, the following line might be included in the input control file:

     \rd ( )

Two characters are expected after the field code, optionally separated by white space.  The first is taken to be the opening (that is, left) delimiter and the second is taken to be the closing (that is, right) delimiter.  Different characters must be used for the opening and closing delimiters.

The delimiters used to set off the root should not be used for any other purpose in the analysis field.  The following may not be used for a delimiter: the backslash (\), whatever character is used to indicate analytic failures and ambiguities, or any orthographic character.

The \rd field may appear any number of times, but once is enough.  If more than one such field occurs, the last one is the one that is used.

If no \rd fields appear in the declarations file, then STAMP uses the delimiter characters < and >.

String class declaration: \scl
==============================

A string class declaration has three parts: the field code \scl, the name of the class, and the list of strings in the class (separated by spaces).  String classes are used in synthesis in specifying string environment constraints on regular sound changes and on allomorph entries in the dictionaries.

The class name must be a single, contiguous sequence of printing characters.  Characters and words which have special meanings in tests should not be used.  The actual character strings have no such restrictions.  The individual members of the class are separated by spaces, tabs, or newlines.

Each \scl field defines a single string class.  Any number of \scl fields may appear in the file.

Valid allomorph and string environment characters: \strcheck
============================================================

The characters considered to be valid for allomorph strings and string environment constraints are defined by a \strcheck field code followed by the list of characters.  Spaces are not significant in this list.

The \strcheck field may appear any number of times, but once is enough.  If more than one such field occurs, the last one is the one that is used.

If no \strcheck fields appear in the analysis data file, then STAMP does not check allomorph strings and string environment constraints for containing only valid characters.

Transfer Control File
*********************

The transfer control file for the STAMP program is a standard format file containing a single data record.

Transfer file fields
====================

The fields marked with an asterisk above can appear in the STAMP declarations file or the synthesis control file instead.

Analytic ambiguity delimiter: \ambig
------------------------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis control file instead; see \ambig (zzSTAMP.DEC).

Allomorph property declaration: \ap
-----------------------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis control file instead; see \ap.

Category declarations: \ca
--------------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis control file instead; see \ca.

Category class declaration: \ccl
--------------------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis control file instead; see \ccl.

Copy rule: \cr
--------------

Suppose that a single source language morpheme corresponds to either of two target language morphemes, where the choice between them is not determined by any contextual factor within the word.  For example, Huallaga Quechua -ra `PAST' (simple past) corresponds to two suffixes in Pasco Quechua, in some cases to -rqU `RECPST' (recent past) and in other cases to -rqa `REMPST' (remote past).  Whether the recent or remote past tense is appropriate is a semantic matter, not determinable by any structural factor, morphological or syntactic.

The best one can do in such a case is to create ambiguous output for every instance of the past tense morpheme and leave the choice between them to the person who edits the computer-adapted text.  Thus, for every Huallaga Quechua word containing -ra `PAST' (as in 1 below) the program should produce two Pasco Quechua words (as in 2), one with -rqU `RECPST' and the other with -rqa `SIMPST':

     1. aywaran
     2. %2%aywarqun%aywarqan%

This can be accomplished by means of a copying rule.  A copying rule produces two output analyses.  It produces a copy of the input and then the result of applying the rule as though it were a substitution rule; see \sr. The only syntactic difference between a copying rule and a substitution rule is that the former begins with the field code \cr and the latter begins with a \sr.  See Syntax of transfer rules For a description of the syntax for these rules.

Returning to the Quechua example, the copying rule in 3 would apply to the analysis in 4 to produce the two analyses in 5:

     3. \cr "PAST" "REMPST"
     4. < V1 *aywa > PAST 3
     5. %2%< V1 *aywa > PAST 3%< V1 *aywa > REMPST 3%

Copying rules apply to the output of previous rules in the transfer file, and subsequent rules apply to each of the outputs.  Because subsequent rules apply to each of the outputs of a copying rule, it is possible for copying rules to feed copying rules.  For example, consider the two hypothetical copying rules in a below.  If these are applied to a single analysis containing A and Q (as schematized in 7 below), they would produce the four analyses shown in 9.

     6. \cr "A" "B"
        \cr "Q" "R"
     7. ...A...Q...
     8. %2%...A...Q...%...B...Q...%
     9. %4%...A...Q...%...A...R...%...B...Q...%...B...R...%

That is, the first rule of a produces the two analyses in 8.  Then the the second rule of a applies to each of these outputs, producing two outputs for each as in 9.

Note that if the original analysis had been ambiguous (with two analyses each containing A and Q), the two copying rules would have produced an eight-way ambiguity.  The moral: if copying rules are used too liberally, there might be a dramatic increase in the levels of ambiguity produced. Let the user beware!

Flag rule: \fl
--------------

Flags are a mechanism for temporarily remembering some information about an analysis.  A rule conditioned by one or more flags affects an analysis only if all the conditions implied by those flags are true for that analysis.  Flags make it possible to "insulate" source language phenomena from target language phenomena.

The definition of a flag has three obligatory parts: (1) the field code \fl, (2) the name of the flag, and (3) the list of morphnames which trigger the raising of that flag.  For example, consider the following definition:

     \fl PLURAL PLIMPF PLDIR PLSTAT

The name of the flag is PLURAL.  The morphnames whose presence causes the flag to be raised are PLIMPF, PLDIR, and PLSTAT.

Flag definitions are a type of rule.  Recall that rules are applied in the order in which they are given in the transfer file.  (This excludes lexical changes, which are applied before all rules.)  Thus, a flag is raised only if one of the morphnames in its definition is present in the analysis resulting from all previous rules (in the order they are given in the transfer file).  For example, the plural flag defined above would be raised only if PLIMPF, PLDIR, or PLSTAT were present in an analysis at the point where the rule is defined in the transfer file.

Suppose there are two rules.  The first deletes PLIMPF.  The next one is a flag definition which raises the PLURAL flag whenever PLIMPF is present in an analysis.  This flag-raising rule only sees the result of all previous rules.  Thus it would never raise the PLURAL flag in this case, since PLIMPF would always have been deleted by the preceding rule.  To get the proper effect, the flag definition rule should be ordered before the rule which deletes the morphname that causes the flag to be raised.

Flags cannot be used in a rule until they have been defined with a \fl field.  Sometimes it is conceptually simpler to define all the flags at the beginning of the transfer file; in other cases it is advantageous to define each of them close to---but preceding---the rules which use them.

Flags may be tested in copy and substitution rules following the match and substitution strings, or in insertion rules following the string to be inserted.  The flag names must always precede any conditioning environments.  A flag name can be preceded by tilde to complement the sense of the flag; that is, a rule so modified applies only if the named flag is not raised.

When a particular analysis has undergone all the rules of the transfer file, all the flags are automatically lowered before another analysis is considered.  To put it another way, flags do not stay raised from one word to another.  Many flags are raised and never lowered until the next word, but in some cases it is desirable to have the flags lowered before some subsequent rule.

Whenever an analysis changes as the result of a rule that tests a flag (or flags), then that rule's flags are automatically lowered.  The user does not have to do anything because TRANSFER is designed to automatically lower flags under this condition.  This avoids the application of subsequent rules on the basis of the same flag.  For example, consider the following rules.  (Insertion rules are discussed in the next section.)

     \fl XFLG M1 M2       |raise flag when M1 or M2 present
     \ir "X1" XFLG / M1 _ |insert X1 after M1 when XFLG up
     \ir "X2" XFLG / _ M2 |insert X2 before M2 when XFLG up

Given an analysis with the sequence M1 M2, the result of these changes is M1 X1 M2.  It would not be M1 X1 X2 M2 because, when the first insertion rule applies, it lowers XFLG. Consequently, the second insertion rule does not apply.

Suppose one wished to drop a flag (say PFLG) whenever a particular morpheme (say XY) is present in an analysis.  The following rule would do it.  (Substitution rules are discussed below.)

     \sr "XY" "XY" PFLG |substitute XY for XY when PFLG up

When this rule applies, it produces no net change in the analysis, but it has the important side effect of dropping the PFLG flag.

Consider the following substitution rule, where the FLG flag is followed by three environments:

     \sr "XX" "YY" FLG / M1 _ / M2 _ / M3 _

This is equivalent to the following sequence of rules:

     \sr "XX" "YY" FLG / M1 _
     \sr "XX" "YY" FLG / M2 _
     \sr "XX" "YY" FLG / M3 _

Note that if the first applies, FLG is lowered so the second and third could not apply.  Likewise, if the second applies, the third could not apply.  Only one rule could possibly apply; transfer's behavior is the same even when multiple environments are included in a single rule or spread across several rules.

It is possible to limit a rule by a complemented flag, in which case the rule applies only if the flag is not raised.  For example, definition 1 would raise the flag KUFLAG when REFL, INTNS, or CMPLT were present, and rule 2 would insert KU when KUFLAG is not raised and INSERTKUFLAG is raised:

     1. \fl KUFLAG REFL INTNS CMPLT
     2. \ir "KU" ~KUFLAG INSERTKUFLAG

Note that the constraint imposed by each of these flags must be simultaneously met for the rule to apply.

In general, a flag automatically lowers whenever a rule constrained by that flag applies.  Note, however, that the converse is not true for a complemented flag that constrains a rule that applies.  If rule 2 above were to apply, then INSERTKUFLAG would be lowered but KUFLAG would not be affected, that is, it would remain lowered.

Flags and morpheme classes have some interesting similarities and differences.  Both are defined in the same way (but with different field codes), and both are used as conditions on rules.  They differ, however, in where they are used in rules: morpheme classes occur in environments, whereas flags occur between the rule's main part and before any conditioning environments.  Perhaps the most important difference is one of persistence.  Once defined, a morpheme class persists until STAMP finishes; there is simply no way to "undefine" a class.  But flags are volatile: they are raised when certain morphemes are present in an analysis and lowered when a rule having the flag applies effectively.

Insertion rule: \ir
-------------------

Insertion rules insert morphnames into an analysis.  An insertion rule may have (in order): (1) the field code \ir, (2) the morphname to be inserted, (3) optionally one or more flags, (4) optionally one or more environments into which the morphname should be inserted, and (5) a comment.  The insertion string is delimited by some printing character. The morphname is inserted into an analysis if all the rule's flags are raised (or, for complemented flags, not raised) and at least one of its environments is satisfied (if any are specified).

Of the five parts listed above, only the first two are obligatory. However, an insertion rule comprised only of a field code and the morphname (without any conditioning flags or environments) would insert the morphname into every analysis.  The following example has the first three parts; it would insert PL whenever the PLFLG flag is up:

     \ir "PL" PLFLG

(How transfer determines where to insert PL is discussed below.)  The following inserts PXT immediately after BDJ:

     \ir "PXT" / BDJ _

The following inserts PLDIR whenever both the PLURAL flag is up and a directional suffix (that is, a member of the class DIR) is present.  PLDIR is inserted immediately following the directional morpheme.

     \ir "PLDIR" PLURAL / [DIR] _

When an insertion rule has multiple environments, it applies only for the first environment satisfied by a given analysis.  For example, consider the following:

     \ir "PXT" / BDJ _  / QMR _

This rule is applied in the following way.  Potential insertion sites in the current analysis are considered in order from left to right.  At the first one, if BDJ occurs to the left, PXT is inserted, and nothing more is done by this rule.  If BDJ does not occur there but QMR does, PXT is inserted and nothing more is done by this rule.  Failing to find either BDJ or QMR to the left, the potential insertion site is shifted one place to the right and the process is repeated.  In this way, all potential insertion sites in the analysis are evaluated until either an insertion is made or there are no more potential insertion sites in the analysis.  When one of these conditions is met, the next rule in the transfer file is applied.

Each insertion rule may affect an analysis only once.  This prevents multiple insertions in cases where more than one environment is satisfied.  For example, consider the following rule:

     \ir "X" / _ Y / Z _

Consider how this affects an analysis with the sequence Z Y.  Both environments are satisfied, so if multiple insertions were permitted by a single rule, the result would be Z X X Y.  However, the desired result is more likely to be Z X Y, which is what the program will produce.  Note, it is possible to get the former result by using two rules:

     \ir "X" / _ Y
     \ir "X" / Z _

Since there are two rules, both would apply to Z Y, the first producing Z X Y, the second applying to Z X Y to produce Z X X Y.

Insertion rules are frequently conditioned by flags; thus some comments about them are in order.  First, recall the discussion above: the application of a rule automatically results in the lowering of any flags in that rule.

Second, flags may be complemented by prefixing a tilde (~).  The following set of rules illustrates the use of a complemented flag.  It is motivated by a situation in Quechua, where pluralization with -pakU occurs only in the absence of other morphemes which have kU.

     \fl KUFLG REFL CMPL INTNS |flag for suffixes with kU
     \fl PLFLG PL1 PL2         |flag for pluralizers
     \sr "PL1" ""              |remove PL1
     \sr "PL2" ""              |remove PL2
     \ir "PLKU" PLFLG ~KUFLG   |insert if plural and no kU

The first line defines a flag for suffixes containing kU; the second defines a flag for pluralizers.  The third and fourth lines delete the pluralizers.  The last line is a rule that inserts PLKU if the PLFLG is up and the KUFLG is down, that is, the original analysis had a pluralizer and no suffix with kU is now present in the analysis.  If PLKU is ever inserted by this rule, PLFLG will be lowered.

Determining the site for insertion
----------------------------------

If an insertion rule has an environment with a simple environment bar, then the position of the bar defines the site for insertion.  But when the rule has no environment, or when the environment bar has ellipsis marking, then the insertion site is not explicitly defined.  TRANSFER has mechanisms for treating these cases.

Generally, the items to be inserted are either prefixes or suffixes.  In the absence of an explicit environment statement, prefixes are inserted somewhere before the leftmost root and suffixes are inserted somewhere after the rightmost root.  TRANSFER determines whether the morpheme to be inserted is a prefix or a suffix by determining which dictionary it occurs in.  (For this reason each affix should have a unique morphname.) Then it uses the orderclass of the morpheme, as defined in the dictionary entry, to determine exactly where to insert the morpheme.

Consider an insertion rule with no environment, such as the following one which inserts ABC whenever XYZFLAG is raised:

     \ir "ABC" XYZFLAG

TRANSFER determines the orderclass of ABC from the affix dictionaries of the target language.  Given an analysis, if the XYZFLAG is up at the point this insertion rule is applied, TRANSFER searches for an acceptable place to put ABC, attempting to place it as far right as possible without violating orderclass, that is, without placing it after an affix with a greater orderclass.  To illustrate, consider an analysis like the following (with the orderclasses given below each morphname):

     < C1 root > M1 M2 M3 M4 M5
                 10 20 30 40 50

Assuming that the orderclass of ABC is 40, the result of the insertion rule would be the following:

     < C1 root > M1 M2 M3 M4 ABC M5

If it is necessary to insert a sequence of morphnames, they can be inserted by a sequence of insertion rules.  For example, the following three rules inserts ABC DEF GHI when XYZFLAG is up:

     \ir "ABC" XYZFLAG
     \ir "DEF" / ABC _
     \ir "GHI" / DEF _

(A slightly more complicated solution would be needed if there were analyses containing ABC or DEF into which these rules would incorrectly insert DEF or GHI.)  Applied to the previous example, the result would be:

     < C1 root > M1 M2 M3 M4 ABC DEF GHI M5

Whenever the insertion site is not precisely defined by the environment bar, insertion will be based on orderclass.  Therefore, ellipsis marking can be used to constrain an insertion by the presence of one or more morphnames and yet have the insertion based on orderclass.  For example, either of the following rules inserts PQR as far right as possible without violating orderclass whenever M4 occurs in an analysis:

     \ir "PQR" / _... M4
     \ir "PQR" / M4 ..._

Lexical change: \lc
-------------------

FIX ME!

Maximum number of properties: \maxprops
---------------------------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis file instead; see \maxprops.

Morpheme class declaration: \mcl
--------------------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis control file instead; see \mcl.

Morpheme property declaration: \mp
----------------------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis control file instead; see \mp.

Punctuation class: \pcl
-----------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis file instead; see \pcl.

Root delimiter: \rd
-------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis control file instead; see \rd.

String class declaration: \scl
------------------------------

This field can also occur in the STAMP declarations file or the STAMP synthesis control file instead; see \scl (zzSTAMP.DEC).

Substitution rule: \sr
----------------------

FIX ME!

Syntax of transfer rules
========================

FIX ME!

Syntax of lexical changes
=========================

FIX ME!

Synthesis Control File
**********************

Analytic ambiguity delimiter: \ambig
====================================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \ambig (zzSTAMP.DEC).

Allomorph property declaration: \ap
===================================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \ap.

Category declarations: \ca
==========================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \ca.

Category class declaration: \ccl
================================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \ccl.

Lexical change: \lc
===================

FIX ME!

Maximum number of properties: \maxprops
=======================================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \maxprops.

Morpheme class declaration: \mcl
================================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \mcl.

Morpheme property declaration: \mp
==================================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \mp.

Punctuation class: \pcl
=======================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \pcl.

Root delimiter: \rd
===================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \rd.

Regular sound change: \rsc
==========================

FIX ME!

Regular sound change markers: \rscid
====================================

FIX ME!

String class declaration: \scl
==============================

This field can also occur in the STAMP declarations file or the STAMP transfer control file instead; see \scl (zzSTAMP.DEC).

Synthesis test: \test
=====================

FIX ME!

Dictionary Code Table File
**************************

     [file dictcode.txi not included]

Dictionary Orthography Change Table File
****************************************

     [file dictochg.txi not included]

Dictionary Files
****************

     [file dictfile.txi not included]

Text Output Control File
************************

     [file textout.txi not included]

Input Analysis Files
********************

     [file anafiles.txi not included]

Bibliography
************

 1. Weber, David J., H. Andrew Black, and Stephen R. McConnel. 1988. AMPLE: a tool for exploring morphology. Occasional Publications in Academic Computing No. 12. Dallas, TX: Summer Institute of Linguistics.

 2. Weber, David J., H. Andrew Black, Stephen R. McConnel, and Alan Buseman. 1990. STAMP: a tool for dialect adaptation. Occasional Publications in Academic Computing No. 15. Dallas, TX: Summer Institute of Linguistics.