"To the only wise God be glory forever through Jesus Christ! Amen."
(Romans 16:27)
1.0 General Introduction
This section describes the conditions on distribution, support of the language, history, objectives and implementation, and gives a script for a quick start in using Fonol.
Online, you can look in the table of contents (TOC) by typing ?/toc.
1.1 Fonol Distribution
Fonol is distributed with my blessings. You may give away copies to your heart's content so long as you do not charge for the copies and so long as you give all the distribution files in unmodified form.
1.2 Fonol Support
I intend to support Fonol as much as is possible with a spare time project and I welcome your bug reports and suggestions for improvements. When sending in bug reports, please give all the details of what happened including the matrix and rules you were trying to run. The transcription and batch file features will help in this (i.e. send a diskette with a batch file to set up the problem if it is at all complex). If you have the source code, please don't fix things yourself -- let me centralize the versions, OK? I also welcome any help on the documentation so as to make sure that it is clear.
Positive reinforcement is naturally also welcome!
My current address is:
Frank R. Brandon
3937 Anewby Way
Fort Worth, TX 76133-6860
(817) 294-0239.
1.3 Porting Fonol
Porting to other machines that run Pascal or C, especially Turbo Pascal, should be fairly transparent since I wrote Fonol as generically as possible. I developed this version of Fonol on an AT&T 6300 using Turbo Pascal 4.0, a version of Pascal that has incorporated many of the low level conveniences of C.
1.4 Fonol Objectives
Fonol is a programming language that simulates phonological rules of the sort described in Chomsky and Halle 'Sound Pattern of English' or Schane 'Generative Phonology'. It also incorporates the input and output filters (conditions) which came into common use about the same time. These filters are currently restricted to the identification of a pattern and two actions: preventing the successful application of a specific rule or blocking (starring) the entire derivation. Some standard conventions on rule application are supported. Cycles of several types are allowed for and other means of appropriate control are also provided. Further extensions, variations, and deviations are included from later phonological folklore. (Let me know if there is something truly vital missing -- I'll try to add it if I can.)
Fonol is designed to provide a way of writing phonological rules and viewing their effects. It is intended to aid students of phonology to grasp the ideas behind phonological rules and to help phonologists manage large complex bodies of rules in the theory of their choice. Considering how many competing theories and partial theories of phonology exist, it may fail in the second case, even though I would like to accommodate as many theoretical variations as possible. Since an attempt will be made to provide for all theories, those who use more restrictive theories will simply have to avoid using some features of the Fonol language. In any case, it should be useful for students and in beginning work on undescribed phonological systems. In some cases, Fonol will allow for the same effects as theoretical systems it does not directly support. In this case, try using what is provided and fixing up or beautifying your rules when you put them in paper form. A program written for the IBMs character oriented display is not able to directly print the typographically complex forms of phonological rules, anyway.
Computer simulation of phonological rules helps to advance the broad generative program as well, in that no amount of hand-waving on the part of the rule writer or good will on the part of the rule reader will have any effect on the way the software interprets what is written. In this sense, it forces the clarification of our ideas just as the whole explicit rule writing approach was meant to, only without any generosity in assumptions. In the 'wins-no-friends' department, it also has been beneficial in revealing how many 'radically new' ideas are reinventions of the wheel and in raising the question of how we select one theory over another of similar descriptive power -- the problem of notational variants. I personally do not want to solve all these problems by myself. For this reason, you will find the documentation to be written in an informal style and filled with invitations for you to write me with your ideas.
1.5 Fonol History
Fonol 1.0 was written in Microsoft's MBasic 5.2 under CP/M in 1983 while I was employed in the Linguistics Department at the Universidade Estadual de Campinas. A paper on it ('A Phonological Rule Interpreter for Microcomputers') was eventually published in 1985 in the Proceedings of the Eleventh International Conference of the Association for Literary and Linguistic Computing ["Computers in Literary and Linguistic Computing", Slatkine Reprints, Rue des Chaudronniers, 5 - Case 765, CH-1211 Geneve 3, Switzerland]. Intermediate versions through 3.0._ were written in my spare time after work while I was employed in the Human Factors Technology Group at General Dynamics-Fort Worth. There was a hiatus of three years between version 3.0._ and 3.1.0 due to lack of interest. This dearth of stimulus was broken in late 1990 by Dr. Wayne Redenbarger -- to whom much appreciation! Recent versions from 3.1.0 to 4.0.0 were funded in part by Aetna Insurance and the Social Security Administration, I suppose, since they've been written while I've been on disability leave and under treatment. The present version is written in Borland's Turbo Pascal 4.0 under MS-DOS.
The name 'Fonol' was chosen for similarities to Cobol, Snobol, Algol, etc. and because, since I was teaching in Brazil at the time, it seemed like a good abbreviation of 'Linguagem de Programaçäo Fonológica'. I forgot that some people don't speak Portuguese.
1.6 Quick Start in Fonol
If you can't stand reading documentation, then please follow this script to get started:
--Type fonol at the A> prompt and hit Return.
--When you see the cursor flashing after the Fnl: prompt then enter 'a --> b __d' and hit Return. You will see an error message with the Atn: prompt followed by a Rec: prompt with what you entered. This means you have an opportunity to recuperate the rule or recover from the error.
--Now use the arrows to go into the rule and put a '/' between b and the '__'. Take this opportunity to remove any single quotes you may have entered. Now hit Return.
--Now type d. You will see your rule and some information about space usage.
--Now type '<<cad' and hit Return. If you left out the single quotes then you will see your rule apply and yield 'cbd'.
--Now type 'l/swa.max' to load the demo Swahili phonological matrix. Type 'm' and hit return to see the matrix (F9 to exit again).
--Type l/swa and hit Return and the swa.fon file of rules for Swahili will be loaded. Your rule is lost.
--Type d/symbols and hit Return and you will see a list of the phonemes, features, and other symbols loaded in.
--Type d/ and hit Return and the rules will be displayed. The ][ lines are declarations, mostly abbreviations to provide 'syntactic sugar'. The rules with --> are obvious. The ones with * are input and output conditions.
--Now when the Fnl: prompt reappears, type << [A# Cl9 + pya #] and hit Return. The rules will be applied and those that do apply will be printed together with their effects. If you want to see a lot of these forms, type 'l/swa.fbf'. This will load and run a batch file of derivations. Keep hitting Q if you get bored, OK?
--Display the rules with d/ again. Note the numbers? Pick a rule at random and from the Fnl: prompt type i/ N where N is the number of the rule. Now type '[] this is my comment' and hit Return. If you left out the single quotes, then there will be no error message, otherwise use backspace or ^g or DEL to delete the first one at least and hit Return again. You will still see the Ins: prompt. Hit return on an empty line or ESC or ^y and you will be back at the Fnl: prompt. Now redisplay the rules. Note where your comment went and the way the other rules have been renumbered. Now take the number of your rule and type r/ number. Redisplay the rules and you will see that yours is now gone and the numbering is as it was previously.
--You could type 'l/demo.fbf' to see the English, Turkish, and Swahili demo rule sets loaded and applied to some forms, or...
--Type x/ to exit Fonol; say 'no' to its suggestion that you save the edited rules; and now please do familiarize yourself with the documentation!
1.7 Fonol Files Supplied
Fonol.exe
Fonol.doc
Doc-Help.exe (Utility that converts Fonol.doc into on-line help
files which are kept in a subdirectory called
..\fonhelp)
(Sample matrices and rule sets for various languages)
Swa.Max
Swa.Fon
Turk.Max
Turk.Fon
SPE-ex.Max (English rules from Sound Pattern of English)
SPE-ex.Fon
TestPat.Max (to practice moving columns and rows in the matrix)
(Sample batch files of base forms)
Swa.FBF, Turk.FBF, Demo.FBF
2.0 System Commands
After Fonol is loaded you will see a title display and a prompt in inverse (Fnl:). At this point you may type in a system command or a phonological rule. System commands allow you to load a phonological matrix or a set of rules, save the rules that are in memory, edit a rule, display the rules on the screen, remove rules, insert rules, apply the rules to a base form to derive a surface form, get further information (on-line help), customize the environment, or exit Fonol to your operating system. These commands mostly consist of a single letter followed by a slash (/). This is a way of distinguishing them from Fonol rules. Case is not important for the letter, although you will probably be in lower case all the time. The command letter and slash may be followed by various types of arguments: line numbers, file names, or strings. When there is no argument, the slash is not required. Line numbers are supplied by the system as a convenient way of referring to a rule or range of rules. You can find out the number of a rule by displaying the rules - you never add them yourself. The file names will refer to your matrix and rule files. The editing commands are available most of the time, even outside of the edit mode. The following is a list of the commands and their options. Anything that is not a command is assumed to be a rule. The prompt will tell you if you are in a 'mode': edit (Edt), insert (Ins), recovery (Rec). The attention (Atn) prompt distinguishes errors that must be fixed from mere information.
General System Messages:
Bad Parameters (Read the documentation on the command you gave)
Press RETURN for More (Hit return key to see the rest)
2.1 File System Commands
Files may be loaded, saved with a set number of backup copies, listed from the current disk, and erased from the disk.
2.1.1 Loading Files
l/ name
Loads the file name. If there is no file extension, then .FON is assumed (=the file extension for rules). Rules will be compiled with the matrix currently loaded. If no matrix is loaded, an advisory message or an error message will be given as described below. To load a phonological matrix you must supply the .MAX extension of the matrix file. If the extension is given as .*, then name.MAX and name.FON will be loaded. Any matrix or rules currently in memory will be overwritten when a new one is loaded. A batch file (.FBF) will be run as it is loaded. If any commands cannot be executed the batch file will terminate (See 2.3.2).
Load Messages: (Also see 2.2.2 -- Edit -- and all the 3.x.x -- Rules
-- message sections)
Expected File Types: X, or... (Check your spelling)
name Not Found
Enter New Name or RETURN to Quit:
Check your spelling or use d/files or l/ to look at the file
names.
.Fon Files:
Loading...
Loaded.
Cannot Compile Features Without Matrix File
Load the matrix file first!
Unread Rules in File
This message is given when a file load is interrupted by an
unfixable error
.Max files:
Loading..
Every 10 lines another dot (.) is printed for reassurance
Loaded.
** Out of Phoneme Space **
Should never happen! Let me know.
** Cannot Read File Format **
Not a .Max file or glitches on media have corrupted your
data.
.FBF files:
Reading From Batch File...
Batch File Read.
2.1.2 Saving Files
s/
If name is not specified, the name of the current or last loaded file is used, if one exists. The current file is always renamed with a .FN1 extension and all other backup files up to the maximum number of generations have 1 added to their extension (i.e. myfile.fon --> myfile.fn1, myfile.fn1 --> myfile.fn2 etc. up to the number declared with /[gen).
s/ name
Saves the rules in memory as file name. The .FON extension will be added, if not present. Matrix (.MAX) files are only saved from the Matrix Editor and two generations of backup are automatically kept (.mx1 and .mx2).
/[gen
This is a system declaration placed in the rule file, which determines the number of generations of backup copies kept (see 3.2).
Save Messages:
Filename exists
Enter New Name or RETURN to Write Over Filename
You have given an already existing name to a newly created
rule file or matrix file. Decide if you want to write over
it or not.
Expected File Types: X, or...
Check your spelling
Rules Edited But Not Saved. Save? (y/n)
Matrix Edited But Not Saved. Save? (y/n)
These messages are issued as you try to leave Fonol.
2.1.3 Listing Files
l/
This lists the loadable files in the current directory, i.e. .FON or .MAX files and their respective back-up files.
d/files
This shows every file in the current directory like dir in DOS.
2.1.4 Erasing Files
r/name.ext
This removes file name.ext from the current directory.
2.2 Rule Manipulation Commands
These are commands for displaying, editing, inserting, and removing rules.
2.2.1 Displaying Rules
d/
This displays the rules present in memory and assigns a reference number to each. It also follows the rules with a status report on the amount of internal storage space in use and the names of currently loaded files.
d/ N
d/ N M
These display particular rules or ranges of rules using the numbers supplied by the system (i.e. d/1, d/3 5). Any non-number may be used as a separator between numbers (e.g. d/3-5, d/ 3 to 5, etc).
d/' string
This displays all rules containing string (e.g. d/ts, d/][gen). A message: No Matching Rule is displayed if string can't be found. ' is required in front of the string only if you are looking for a string beginning with a number or the single quote character (i.e. ''abc to find 'abc. d/1 displays rule one, but d/'1 finds all the 1 characters in your rules).
d/symbols
This displays a quick summary of some elements of the current matrix: a list of phoneme symbols and a list of feature names. It also shows all the atom and abbreviation symbols. M will bring up the entire matrix in the matrix editor and d/=# and d/== will show all the atoms and abbreviations in the rule set. d/symbols sometimes is more convenient.
d/files
This displays all the files on the currently logged diskette. (l/ shows only loadable .MAX and .FON files.)
/[hide
/[show
/[step
These are system declarations which can be inserted in a rule set to turn rule display on or off during a derivation or to allow for pausing the display. See 3.2.
2.2.2 Editing Rules
e/
This, by itself, brings up the last entered or edited rule, if any exists, to be reedited.
e/ N
This allows rule number N to be edited. The number of a rule may be found by typing d (see display) to show the rules. The prompt Edt: appears. The rule editor allows lines of up to 245 characters to be input. It automatically wraps around at the end of the screen line. The rule can be edited using cursor and/or control keys. All editing keys are available for input even without the Edt: prompt. The Rec: prompt is a special edit prompt for recovery from a fatal error in a rule and is invoked by the compiler. If you edit or delete an atom or equality definition, Fonol will attempt to recompile the rule set to maintain consistency (see note below).
e/matrix
m
This puts you in the matrix editor and brings up the currently loaded matrix. (M is a shortcut.) If no matrix is loaded, then a 'dummy' matrix is displayed. After entering a new matrix or modifying an existing one, Fonol attempts to recompile the rules to keep them consistent. See the section below on the matrix editor.
Edit Messages (see also Rule and Load sections):
** Out of Rule Text Space **
Fix by reducing text size if possible.
** Out of Rule Space **
** Out of Compiled Rule Space **
Not fixable. Write me if this happens. If you enter the
rules with the built-in editor, these errors will not
surprise you. A look at the status line after rule display
with d will tell you how much space is left.
** Out of Symbol Definition Space **
Atoms and abbreviations have exceeded the magic number.
Write me if it is too small. Currently 80.
** Out of Abbreviation Expansion Space **
Room for expansions is gone. Write me. Currently 40.
** Rule Buffer Too Small for Rule **
The compiler buffer for a single line has overflowed. No fix
is available. Write me.
Not Identifiable as Rule!
No specific error is detectable, but the rule cannot be
read. It will be displayed with the Rec: prompt for editing.
No Matrix Loaded - Compiled as String
The rule you just entered may not have been compiled as you
desired. However there is nothing to prevent you from
writing rule systems with undifferentiated symbols -- all
non-phonemic -- so it is accepted as is, with this caveat.
Cannot Compile Features Without Matrix File
No doubt on this one. Load a matrix first.
Automatic Recompilation After Editing
When the matrix or the atom or equality/abbreviation parts of your rule set are edited, Fonol attempts to recompile the matrix and the rules to conserve internal consistency the next time you try to derive something. Up to the point you type in <<string, you may edit and even save inconsistent files. If something goes very wrong, you may 'lose' your rules. Don't panic! The changed rules are on disk under the name 'FNLTMP.FON'. Your previous rules and matrix are still there on disk (unless you deleted them -- bad move!). You must fix whatever is wrong to successfully compile, i.e. re-load. Sometimes this can be done at the Rec: prompt. Sometimes for extensive changes it is easier to edit the rules in your word processor (don't forget to save as ASCII without tabs), edit the matrix in Fonol and then put them together. The main trick is to edit all abbreviations, atoms, and the matrix with care, before attempting to derive something.
[To practice not panicking, load the supplied Swa.Max and Swa.Fon and go in and change the feature syll to voc in the matrix. Now try deriving something. As the complaints about syll show up, fix them at the Rec: prompt. But wait, an equality declaration uses syll! There is no escape! Go back to the matrix and change voc back to syll first, so the old Swa.fon will load and, now, if this were serious, you'd fix the atom and abbreviation declarations, before changing syll to voc.]
Recompilation Messages:
Recompiling...
Recompiled.
** Rules and Matrix Are In An Inconsistent State! **
The recompile failed on the error you could not fix. This is
like the 'Unread Rules in File' message.
2.2.2.1 Special Editing Keys
(Note: ^X means control-X)
Editing Commands
WordStar type commands are a historical residue. Older keyboards
also did not have cursor keys.
^s moves left one character (or Left Arrow)
^d moves right one character (or Right Arrow)
^e moves up one line or to the beginning of the line (Up Arrow)
^x moves down one line or to the end of the line (Down Arrow)
^g, DEL and Backspace delete characters. Characters are normally
inserted. There is no overwrite mode.
^y or ESC or ^c will erase the whole entry -- abandon edit.
RETURN enters or accepts the rule mostly -- it erases in Rec: mode
since a fatal error is being ignored!
Symbol Entry Short Cuts
^a inserts the arrow (-->) with blanks around it.
^b inserts the curly braces used in extended rules ({| |}) and
positions the cursor between them to insert the contents
^t inserts the transformation arrow (==>) with blanks around it.
^v inserts the variable symbol ... with blanks on either side.
Short Cut Alternative to Retyping
^r restores the last entry, inserting it at the cursor position.
Pressing ^r again replaces the last entry with preceding entries
on the history stack until the history stack is empty, then there
is a beep and the next ^r will give you the bottom of the history
stack (i.e. the last entry) again. Any other key than ^r will
accept what ^r has entered, reset ^r to the last entry, and return
to normal editing.
Disambiguation
blank can be used to separate potentially ambiguous sequences. (If you
have /t/,/s/, and /ts/ as phonemes, a-->b/__ts will only mean
/ts/, but typing a blank after the t (a-->b/__t s) will
distinguish the sequence as /t/,/s/. Blanks are skipped in match.)
2.2.2.2 Special Characters
The full IBM character set is supported as a minimum by Fonol. Special characters in the 'high' ASCII set used by IBM can be entered by typing an accent followed by a letter. You type ^a and get â. Use blanks between an accent and a letter to prevent accenting (^ a will not be converted). Type ?/~ to see supported special characters (i.e. this section). The accents and letters they combine with are:
Other special characters must still be entered with the Alt key and code.
2.2.2.3 Matrix Editor
e/matrix
m
Editing the matrix is somewhat different from editing rules. The matrix is represented as a large space you move through freely, not numbered lines. Because of this, function keys are used for special commands instead of commands entered on a line. A help prompt bar on the bottom of the screen will show what keys are available at each point as you move the cursor. The eight arrow keys (including the diagonals such as 9/PgUp) are used to move all over the page. You cannot fall off the screen, but since matrices can be bigger than the physical screen, Control Arrow is used to scroll between sections or pages. Hold down the CTRL key and push the appropriate arrow key. Using the arrows, move into the feature name column on the left hand side and type in any sequence of up to four lower-case characters as a feature name. After typing the name, either Return or the arrow keys will move you back out of the feature name column. Move to the phoneme representation row on the top of the page and type in up to three characters to represent a phoneme. Go back into the value space and put in the appropriate + or -. If you move beyond the edges of the matrix, you will automatically be prompted to input a new feature name or phoneme representation depending on which dimension you 'stretch'. Return is enough to put you back where you 'departed' the matrix. Most editing features, like accented characters, are available.
If no matrix is currently loaded, then a 'seed' matrix is displayed.
r/matrix will remove a loaded matrix.
d/matrix shows a summary of the matrix which is easier to look at for some purposes than the whole thing.
Classes
There is a facility to search for the class of phonemes described by a set of common features and to discover the features common to a set of phonemes. Once again the help prompt contains this information with the designations Compare and Classify. Compare takes a list of phonemes in the matrix and shows what features they have in common and what features differ. This is useful for figuring out how to specify rules. Classify takes as input a sequence of specified features and shows what phonemes they determine. This is useful for determining if the specification you have settled on really works!
Arranging the Matrix
You may move rows and columns around. This is done by a kind of swapping, so the direction of motion will affect where the moved row or column arrives relative to the cursor position. All these are explained on screen in a prompt bar and should be transparent. TesPat.Max is supplied for you to move columns and rows around and get a feel for what happens.
Deletion and Insertion of Phonemes and Features
You can also delete existing columns and rows (i.e. phonemes and features) or insert a new feature or phoneme in the middle of the existing ones. This is prompted at the bottom of the screen every time you enter the feature or phoneme spaces.
Types of Matrix
The only sort of matrix currently available is one that is fully specified. Unmarked and marked are not allowed for. It is possible to work around this in some ways due to the laxness of matrix definitions in Fonol. No checks are made for duplicate phoneme feature definitions, although if a change has been made by a rule and a phoneme is being looked up, it will be determinate. Identical feature names will not compile differently nor will identical phoneme names: you get the first one on the sorted list (you'd need to play around with the matrix to be sure which one). This sort of laxness can be rooted out with the Classify and Compare commands. However, just as you can define allophones for printing purposes, you can also define 'underspecified' segments with printable forms which are filled in by rules, if the fact that all features are inherently - is not a problem. Scalar features are also not supported. In some cases, depending on the kind of rules you need to write, the same effect can be gotten by using two or more features together. [However I am thinking about how to handle underspecified and scalar segments in a correct way, and would welcome your comments.]
NOTE: After editing the matrix, the rules will be automatically recompiled with the new matrix, when you attempt to derive some form. See the note on Automatic Recompilation in 2.2.2
See d/matrix, r/matrix, e/matrix, and l/file.max.
2.2.3 Inserting and Moving Rules
i/ N
This allows new rule lines to be inserted above line N as the new line N.
An Ins: prompt appears. Pressing RETURN (or ESC or ^y) in response to the Ins: prompt ends the insertion mode. All editing keys are active. (Example: i/5 allows new rules to be inserted above rule 5 which becomes rule 6, rule 7, and so on as new rules are inserted.)
i/ N M
This moves rule N to the position just before rule M. If M is a value past the end of the current rules, then N becomes the last rule in the rule set. (Example: i/3 7 moves current rule 3 to the point in front of current rule 7, 3 becomes 6.) Any non-number may be used to separate the two numbers.
2.2.4 Removing Rules
r/
Removes all rules (but not the current matrix). A confirmation message is given:
Delete ALL rules (y/n)?
r/ N
r/ N M
These commands remove rule number N or the range of rules N through M including N and M.
(REMEMBER: Numbers are supplied by display (d/) and change with the removal or insertion of rules so be careful. r/N followed by r/M may remove rule M+1 if you forget that the numbers are relative and not absolute.)
r/matrix
This removes the current matrix without replacing it. Currently compiled rules become orphans and attempting to derive forms will not work as expected.
r/name
This command will remove file name from the disk in the current drive.
2.3 Applying Rules for Derivation
<< string
This applies the current rule set to string (the base form) to derive the surface form allowed by the rules. String including the '<<' is limited to the 255 character length of Pascal strings including blanks (Blanks are removed automatically as the string is translated to internal symbolic form). These characters represent up to 120 symbols (current limit). The symbols used in the base form are differentiated into two types: phonemes defined in the currently loaded matrix or non-phonemes. Feature bundles are not allowed: if you want partly specified forms, like N for any nasal, then define them as "arch-phonemes" in the matrix. (see 3.3.1 for further information)
Base Form Messages:
** Base Form Contains Too Many Syntactic Boundaries ([,]) **
Use a less complex form. Write me if this limit is too low.
* Word Buffer Overflow -- Part of Base Form Lost *
Semi-fatal: processing continues but you don't get what you
wanted. Let me know if this buffer is too small.
* Word Contains Illegal Character: X *
X is a reserved character. If it is {, perhaps a feature
bundle is being used instead of a phoneme.
Too Many Open: [[]
Too Many Close: []]
No Brackets in Form
These messages are given when the syntactic cycle
declaration is active and means that the syntactic boundary
markers are not paired -- or not present. This must be
fixed at least initially. See 3.1.2, 3.5.2.
Declared Cyclic Category Not Found in Base Form
No bracket [ is labeled according to the ][Cyc Cat
declaration in your rules. See 3.1.2.
2.3.1 Saving Derivation Results
t/
Transcribe derivation results. T toggles transcription on and off. When transcription is on, the results of << string are saved in a file on the logged disk (default: Trans.Txt). This file can be edited or printed with your usual word processor like any other file, outside of Fonol (It's a pure ASCII file). New derivation results are appended to former results so you may want to periodically edit out old bits or erase the file. Derivations are date and time stamped and identify the files used.
Transcription Messages
Transcribing...
Transcript Closed
Lets you know whether you toggled transcription on or off.
** Transcription Error **
Trans.TXT can't be created or added to.
2.3.2 Automating Derivation
l/name.FBF
This load command loads and runs the Fonol Batch File (.FBF) with name. Any commands which may be typed in at the Fnl: prompt may be put in a batch file. If anything goes wrong with one of these commands, the system will stop and wait for input from the user. x/ and /// are allowed for as well. Only loading of other .FBF files is forbidden. This is expected to be useful when rules are stable and files exist but the user wants to run large data sets under one or more sets of rules and matrices. Naturally this feature can also be used to set up the system with, say, color choices. The appropriate place for this is the Config.FBF file.
CONFIG.FBF
This is a special .FBF file which is automatically loaded and run on start-up, like autoexec.bat or config.sys in DOS.
Batch File Messages
Reading From Batch File...
Batch File Read
These two messages let you know what's going on so you have
some idea whether the system is working or hung.
2.4 On-line Help
?
Displays this information about on-line help. The help function allows you to read all the documentation for Fonol from within Fonol as described below.
?!
Explains the last three system messages in more detail if such information is available by bringing up the appropriate sections of this documentation. This is a way of supplying hints for problems, especially multiple problems, while avoiding too much verbosity in the standard error messages.
?/~
The tilde (~) is used to represent all special characters. This command will show how to enter special characters (see Edit).
?/string
String is explained. It may be a command letter, a word, a section number or some symbol that is used in Fonol. All current support may be found on-line: try typing something in, it will provide some kind of aid, even if it is only a list of the indexed terms most similar to string.
?/toc
This command will show the Table of Contents (TOC) of the Fonol documentation (Fonol.doc). Section numbers or words or symbols in section titles may be looked up with ?/string. Words or symbols may reference several sections, so section numbers will be less 'verbose'.
Help Messages:
** Help Table of Contents Overflow **
** Help Index Overflow **
The last edit of Fonol.doc blew out the limits. This should
never happen to you unless you decide to fix or customize
the documentation. Write me.
* Help Index Not Found *
Check Location of ..\fonhelp
Help was invoked, but the \fonhelp subdirectory was not
found on the current logged drive in the directory
containing Fonol.exe or no index file was in the
subdirectory.
* Missing Files in Help Subdirectory *
The subdirectory was found with an index file, but it is
incomplete. Better look it over and perhaps run Doc-help
again.
Search Failed In: X1..X5
Shows the five items in the midst of which the search failed. This provides some clues when you are hunting around
for information.
2.4.1 Printing Fonol Documentation
The documentation is currently being maintained in Sprint 1.0. Low ASCII (<32) are formatting codes which I use mostly for screen printing and for marking words to be used in the help index. You should find one line beginning with ^K which is the ruler line and various strings beginning with ^B, ^U, or ^D and ending with ^N which are the Bold, Underline, and inDexed strings. ^_ is the 'soft' carriage return symbol for line breaks in paragraphs. ^L is a page break. The IBM high ASCII set (>127) may cause problems to your printer -- on my Epson I have to set some dip switches to print them, for example.
I am trying to figure out how to maintain the documentation in a way that anyone can print and still not lose formatting.
2.4.2 Setting Up On-Line Help
Fonol.exe is distributed with FONOL.DOC and DOC-HELP.exe, the program that converts FONOL.DOC to the FH-xxxxx help files found in \FONHELP. To set up the on-line help, yo should put fonol.exe, doc-help.exe, fonol.doc into some convenient subdirectory or onto some disk. Log in to that subdirectory or disk drive. Now type mkdir fonhelp to put ..\fonhelp into your current directory. Then type doc-help and hit return. It will ask you if you have done the preceding steps. Just hit return again and ..\fonhelp will be filled with the files used by on-line help. This method is used so that consistency is maintained between the printed documentation and the on-line documentation.
If you want to edit FONOL.DOC and make changes which will appear when help is invoked you will have to run DOC-HELP with FONOL.DOC and the ..\FONHELP subdirectory again. Doc-Help tries to lemmatize a bit by removing suspected plural s from words read from boldface titles
2.5 Exiting Fonol
x/ is the graceful way to exit Fonol.
2.6 Fonol System Setup
///
This command reinitializes the Fonol system, restoring all original values and wiping rule and matrix memory clean. A desperation command to be used just before Control-Alt-Delete or the on/off switch.
//PP+
//PP-
These commands turn 'pretty printing' on and off. When 'pretty printing' is on, the base and intermediate forms are printed with blanks between symbols which are confoundable in sequences. Requires upper-case 'P's.
//C F B
This represents a set of commands for customizing the colors in which classes of text are displayed.
C is a lower-case character identifying a class of text as shown in the table below. F and B are lower-case characters representing the foreground and background colors. F is a letter from a to p selected from the color menu below and B is a letter from a to h. For example, //p o c sets prompts to a yellow foreground and a green background.
Text Class Identifiers:
p for prompts and very emphasized messages.
n for normal entries, rules, commands, etc. or 'bold' in help
text (primary emphasis).
d for de-emphasized entries, like comments and non-phonological
characters, or normal text in help text.
i for 'italic' entries in help text (secondary emphasis).
h for 'hidden' text (e.g. the part of a phonological base form
not being considered by rules when strict syntactic cyclicity
is in effect).
Available Colors: (background must be a dark color)
Dark: Light:
a Black i Dark Gray
b Blue j Light Blue
c Green k Light Green
d Cyan l Light Cyan
e Red m Light Red
f Magenta n Light Magenta
g Brown o Yellow
h Light Gray p White
On monochrome boards the 'colors' will appear as bright, dim, and underline. The color names are relative to your machine.
CONFIG.FBF
This special .FBF file is the place to put these commands if they are meant to be permanent. (See 2.3.2)
?/cor
This shows all the possible combinations of these colors for your screen. The present settings are also displayed. Just plug in the letter combination that you like best.
//c
This resets the original default colors.
3.0 Fonol Language
Fonol is a programming language based on phonological rules. As a programming language it is a 'declarative language', not 'imperative'. It should be natural enough to linguists. This section splits the language up into declarations (information for compiling and running the language), comments, rules (including filters), and 'control' related items.
3.1 Declarations
Declarations (][) provide information to Fonol about how to understand symbols and rules. These are meta-theoretic, in general, and cover notation and questions such as strict cyclicity, iteration, and so on. They are meant to allow a certain theoretical tailoring of rule sets.
3.1.1 Symbol Declarations and Abbreviations
These are the 'syntactic sugar' of Fonol. They improve readability. They help prevent confusion (in the compiler) about multiple uses of the same characters. They are also useful for keeping lines to a reasonable size. You should put all of these declarations at the start of your rule set, but they may be in any order -- just remember that they must be defined before they can be used.
][A=#
][ A .. Z=#
Declares A to be an atomic symbol. A must be longer than 1 and no longer than the maximum abbreviation size (currently 15). The characters in A no longer have an independent existence. These should normally be the first set of declarations, i.e. preceding equality declarations, but they only need to precede the point where they will be used. Atoms may be declared on as many lines as you wish. Multiple atoms may be declared on the same line by separating them with blanks (i.e. ][ Participle Passive Gerundive N3 Ablative =#). You might want to group atoms on different lines according to their use in your rules.
][A==B
Declarations of equality may be made for abbreviations and so on. The A part is the abbreviation and the B part is its expansion. The expansion may contain anything meaningful in the rules or matrix.
Abbreviations can be used to make rules look better and take up less space when printed. For example, C, as an abbreviation for consonant may be implemented with the declaration: ][ C == {+cons -voc}, i.e. 1 character instead of 11. However, the symbols used in the abbreviation cannot be recuperated for printing in a base form. (The original text of rules is saved and printed since they are static during a derivation.)
Besides shortening the length of strings, you can redefine other symbols of Fonol to make them look nicer: ][ X==... would allow you to write rules with X as the variable symbol, if you don't need X for anything else. ({|,|} may not be redefined however). And ][round==rnd lets you get around the limits on feature name length. The right hand side (i.e. B above) may be empty (i.e. ][0== to define 0 as an abbreviation for the null string). Duplicates are not checked for so you may have many-to-one mappings from abbreviations to expansions.
Atoms and other abbreviations may be used in the expansion, but please note that the substitutions expressed by these declarations will be made in rules and base forms in the same order that you write them. (Remember feeding and bleeding!) For example,
][C=={-syll+cons}
][C13==C(C(C))
will work all right, but
][C13==C(C(C))
][C=={-syll+cons}
will stick a bunch of capital Cs in your rules wherever you use C13.
Exotic errors can be introduced with == so be alert!
Note: Symbols of this sort are identified using the largest possible match from left to right, so just as with phonemes, use blanks to disambiguate. For instance, if N stands for any nasal segment, N1 is the first projection of the category N, and 1Plu stands for the 1st person plural morpheme, then ...N1Plu... will find N1 and orphan Plu, but ...N 1Plu... will be correctly recognized. When in doubt, isolate the form with blanks.
Symbol Declaration Messages:
Wrong Size Atom:
Wrong Size Abbreviation:
Shows the size error for symbol declarations
Wrong Size Expansion:
Shows a size error for the expansion
3.1.2 Rule Interpretation Declarations
These declarations identify conventions for understanding the patterns expressed by rules.
][skp+
][skp-
skp turns on or off the convention of skipping over non-phonological segments to apply phonological rules, that is, rules are understood to apply ignoring morpheme boundaries, brackets identifying morphological class, and other non-phonological segments which are not specifically mentioned in the rule. This is the skip non-phonological segments convention. It is implicit in generative phonological work, but must be made explicit in the world of computers. It may be turned on explicitly with ][skp+ or turned off with ][skp-. The skp option is on by default if a matrix is loaded, otherwise it is off by default.
][mcpi+
][mcpi-
mcpi means maximal categorial projection interpretation. Rules in the scope of this declaration will have brackets [,] on rule extremes interpreted as referring to the maximal projection of the current cyclic category. For example, in the scope of mcpi, the rules
a --> b / [Z...c__d...Z]
a --> b / [Z...c__d
a --> b / c__d...Z]
would apply to the outermost brackets of the current cycle only. They would not apply to any embedded brackets. For that, you would have to turn off mcpi (][mcpi-) or else use [...[ or ]...] descriptions (... is the variable). This is not quite the same as ][ssc+ or using ][CycCat: (described below), since only rules with expressly included brackets are affected. Rules with internal brackets or without brackets will apply wherever they can. Sound Pattern of English contains many rules written according to this convention.
This only has an effect in syntactic cycles currently.
3.1.3 Rule Reapplication Or Cycle Declarations
These declarations affect the way syntactic cycles are done. They make it possible to define a wide range of cycle types. They are further discussed in section 3.5.2.
][ssc+
][ssc-
][ssc turns strict syntactic cyclicity on and off in loops which represent syntactic cycles. What this means is that no change will be made in an embedded syntactic component during a higher cycle or, put another way, deeper bracketings can only contribute environment to cyclic rules. For example, in a syntactic cycle with ssc+, the rule
a --> b /c__d
and the base forms
[ca[dca]d] or [c[adc]ad]
only the a in the outermost brackets will change. (skp+ is assumed)
This is the strictest form of 'Strict Syntactic Cycle', but not the only kind allowed. In the discussion of Syntactic Cyclic Loops in 3.5.2, the variety of syntactic cycles is more thoroughly compared and contrasted. Syntactic cycles are marked in words by [,] pairs.
Off by default.
][ats+
][ats-
ats means apply to stems, where stem means the minimal bracketing, a bracketed string that does not contain other bracketed strings (i.e. [X] where X does NOT contain [,]). Obviously, in the scope of ats, ssc has no noticable effect. Off by default.
][atdf+
][atdf-
atdf means apply to derived forms, where derived form means a bracketed string which contains other brackets (i.e. [X] where X contains [,]). With ssc+ as well, nothing in the minimal bracketings would be affected. Off by default.
][rbi!
rbi! means recompute bracketing immediately, meaning that the brackets in the current state of the derived form are identified for use in a syntactic cycle. This is provided to allow the user to produce bracketings by rules and then apply some form of syntactic cycle to them. It is also useful if rules applied before a syntactic cycle change the size of the original bracketed string (e.g. morphological substitutions in a prior group of rules).
rbi! removes most of the limits on what you can do in syntactic cycles. It is safer to use this outside a loop, but it may be inserted in a loop. See the comparison in dbc below.
Envisioned use:
Replace the atom Past (length 1) with the string ed (length 2)
OR
[> Iterate until all the brackets are in place
rules... like zzz --> [zzz] or some such
<]
][rbi!
[> Syntactic cycle of some sort using the brackets
rules...
<]
][dbc+
][dbc-
dbc means dynamic bracketing convention. This provides for do-it-yourself cycles. The rules in a syntactic cycle in the scope of this declaration will apply to the minimal bracketing as in ats, then when these have all been applied to, the bracketing will be recomputed as in rbi! and the rules will be applied to whatever the minimal bracketings are at that point. It is up to the user to erase or insert the correct number of brackets by rule during each cycle. The rules will stop being applied when there are no more brackets, the derived form is a mess of mismatched brackets, or the loop has gone on for about 30 tries.
dbc, like ats, obviates any need for ssc and does not combine with atdf.
Don't forget to close off this declaration with ][dbc- if any rules are to be applied after the syntactic cycle in the scope of ][dbc+.
Note: The rbi! declaration may also be inserted in a syntactic cycle. It allows for a looser definition of loops that run until all brackets are erased. The new bracketing does not have to be computed after the rules apply to all minimal bracketings and other declarations may be mixed in. See 3.5.2.
][ Cyc Cat:[string
][CycCat:[
This is the minimum required to declare string as the label marking the only cyclic category in a syntactic cyclic loop. The absence of string means that the cycle reverts to anything in [,] brackets. By default there is no defined cyclic category, i.e. all categories are cyclic because cycles are defined on brackets alone. String may contain up to three phonemes, non-phonemes, atoms, or the _ non-phonemic segment variable (which, in this case only, will also match phonemes). The label string is expected following the open bracket '['. Labels inside close brackets ']' are not checked.
You may write this declaration in a more readable manner so long as the strings 'cyc', 'cat', ':', and '[' are present in that order, e.g.:
][ Cyclic Category: [N''' (assuming ][N'''=#)
][ Cyclic Category: [_## (i.e. any single label with two word
boundaries)
Cyclic Category Compilation Messages:
Invalid Cyclic Category Label
Somehow some symbol other than the legal ones is being used.
Cyclic Category Label Too Long
Consider making the label an atom, if possible, or using
numbers or -,=,≡ instead of ','',''' for bars of categories.
Three symbols should never be too short, but let me know if
it is.
3.2 System Declarations
These are declarations (/[) associated with rule sets that determine system related conveniences such as the number of backup files to be kept and how results are displayed. They have nothing to do with theory.
3.2.1 Backup File Declarations
/[genN
This declaration sets the number of generations of backup copies to be saved. N may be any number from 1 to 9. If no generation count is declared the default is one. Every time a file is saved all the backup copies are increased one generation (e.g. myfile.fon -> myfile.fn1 -> myfile.fn2 etc.) and any generation beyond the declared limit is lost. This is useful if you are working on something where you make many changes without being certain that the changes are correct. Up to nine previous versions can be available for starting again on a new tack.
3.2.2 Display Declarations
Used with t/ and batch files, these declarations help the user understand what his rules are doing, especially in large rule sets.
/[hide
This declaration shuts off the display of any rules in a derivation which follow it. It does not have a an effect on d/. It can be used to declutter your display if you only want to observe particular ranges of rules or just check the derived form. Turning off rule display speeds up derivations significantly.
/[show
This declaration undoes the effect of /[hide, restarting the display of following rules. It also prints out the current derived form as a reference, with an identifying label, either intermediate: or derived: (if /[show is the last line of the rule set). There can be show declarations without corresponding hides, so it can be used to print the final derived form or show a rule's input in step mode (see below).
/[step
This declaration pauses the derivation before the next rule or filter and gives the user the option of stepping (S) to the next rule/filter, hopping (H) to just before the next successful rule application, leaping (L) to the one after the next /[step declaration (or the end of the rule set), or quitting (Q) the derivation. The space bar can also be used for stepping. Tapping the H twice (= H S) is a convenient one handed way to see just the rules that apply.
3.3 Comments
[]
This marks whatever follows as a comment. You may also write comments after the disjunctive block markers or the iterative or syntactic cyclic block markers so as to give names to groups of rules.
Remember that rules can be temporarily disabled by commenting them out, i.e. putting [] in front of them.
3.4 Rules
These are what correspond to phonological rules plus other information which is left implicit in ordinary phonological rules (e.g. some meta-theoretic considerations). Rule messages are distributed under the type of rule, but related messages are also in the load (l) and edit (e) sections.
The word 'rule' is used in three ways in this text. Most often it refers to any line of Fonol, since Fonol is a line oriented programming language and compiling takes place in individual lines. As you might expect, 'rule' is used with the traditional meaning of one of those entities with an arrow in it which expresses a change to be applied to a form, including other lines holding the curly braces which belong to the rule, like
a --> b / c__d
or
a --> b / {| c |} __ d
{| e |}
'Rule' also refers to logical rules, which are what the interpretation machinery works with when a form is derived. A logical rule has a format which should be observed:
1. input conditions -- optional -i*, +i*
2. a disjunctive block of rules -- optional {[,]}
3. or a rule -- required -->
4. variable conditions -- optional +v*,-v*
5. output conditions -- optional -o*
The star (**) is completely independent.
A disjunctive block of rules is composed of the same sequences as above (except for otherdisjunctive blocks). Comments may be freely mixed in anywhere except between a rule line (with an arrow) and curly brace lines associated with it. No tests of syntactic coherence are made, so please be aware that bits of logical rules can be stranded with various odd results, if you put anything other than comments between the lines or if you put anything between the curly brace lines.
Ordering of rules is left up to the user. No attempt is made to provide a separate mechanism for ordering principles like the Proper Inclusion Precedence and the Elsewhere Condition. This is because it is very hard to compute proper inclusion and 'elsewhere'-ness. If there is a rule a --> b / c__d and another a --> e, all is well -- up to the time of application! Given a string #acazad#, should the second rule apply to 'ad', 'ca' or the last 'a'? Currently it would apply to the first 'a'. (For elsewhere conditions, the disjunctive block notation will yield the same effect and on converting your rules to paper you can beautify them with the appropriate notation.) Given two rules referring to features like {+cons} --> and {+high} --> y which may or may not have overlapping structural descriptions, it would be impossible to generate an order due to a lack of specificity in the principle. This does not mean that Fonol tries to force extrinsic ordering on the user, just that you should apply your theory of ordering manually (at least for now! Ideas are always welcome!).
Logical Rule Message:
Unexpected Interruption of Logical Rule
Since it is rare that the interpreter has any reason to
suppose that a logical rule is disorganized, there is only
one message, printed at run-time when the blocking of a rule
by an input condition is uncertain. (see also Rule Messages
in 3.4.2)
3.4.1 Symbols, Phonemes, and Feature Bundles
These are the basic units of which rules and base forms are composed. Matching and change in derivations operate over these units. Feature bundles and phonemes are obvious. Other symbols are non-phonemic material such as the labels used to identify categories, symbols for morphemes, symbols for boundaries, and symbols which identify theoretical constructs. Non-phonemic symbols may be reserved to the system or user defined. All these are described in detail in the following sections.
3.4.1.1 Phonemes and Non-Phonemic Symbols
Any Ascii code symbol from Ascii 32 through Ascii 254 may be used in a rule. Up to three characters may be used to represent a single phoneme (i.e. 'trigraphs' are allowed to compensate for the lack of a good way of using IPA symbols on the average PC). For a symbol to be used as a phoneme, it must be defined in a matrix. This requires use of the matrix editor, which is described later on. Non-phonemic symbols are symbols used in rules and base forms without being defined in a matrix, e.g. [N bbbb N] to show the limits of a syntactic category or # for word boundary. Such symbols will be treated differently depending on whether there is a phonemic matrix in use and whether the skp declaration is being used (see ][). Non-phonemic symbols may also be declared with the =# declaration (see ][). Blanks have a special use as formatting and delimiting or quoting characters. Reserved symbols as shown below cannot be redefined as phonemes without unpredictable problems.
3.4.1.2 Reserved and Special Symbols
Reserved and special symbols are used by the compiler and the run time system. The following are the reserved symbols or symbol series:
{, }, Feature Bundles
(, ), ..., {|, |}, Conflation of Rules
-->, /, __, ==> Rule Parts
**, -o*, +i*, -i*, +v*, -v*
Filter/Condition Types
[>, <], {[, ]}, Flow of Control (Iteration, Disjunction)
[], User Information
][ Run Time Controls
/[ System Controls
[, ] Syntactic Boundary Marker in Syntactic Cycles
see [> syn cyc
Symbols from ** to /[ are only reserved as the first non-blank symbols on a line. However, it is probably safer to always treat these symbols as reserved.
Transformation Special Symbols.
On the right hand side of the ==> transformation arrow, numbers and the comma have a special use.
Declaration and Loop Special Symbols.
In the sections on ][, /[, and [> other special sequences are defined.
Feature Bundle Special Symbols.
Within feature bundle boundaries ({, }), the symbols +, -, A..E, α..ε are reserved, but not outside (e.g. + can be used outside of a feature bundle as a symbol for morpheme boundary without being confused with the + feature sign: {+cons Avoc}+Ab is legitimate with two uses for + and A). The names of the features are also reserved symbols inside the feature bundle and are defined as such in the matrix (see matrix editor).
Blanks.
Blanks are normally meaningless in rules, but may be used for formatting and to distinguish ambiguous sequences (i.e. to distinguish the two vowel sequence 'a e' from the single vowel 'ae'=ash=æ). Feel free to use them as separators. Phonemes are matched left to right starting with the longest sequence. For example, if you have the phonemes t, s, ts, sh, h defined, then the sequence 'tsh' will be parsed as 'ts','h'; the sequence 't sh' will be 't','sh'; and 't s h' will be 't','s','h'. When in doubt, put blanks around phonemes. When a word entered with blanks is printed during a derivation, the blanks will not be shown, but it should be clear that the phonemes have been disambiguated.
3.4.1.3 Feature Bundles
A feature bundle is a sequence of signed features between single curly braces (regular square braces are impractical technically), e.g. {+cons -voc αstri} is a feature bundle specification. The features may be written in any order (i.e. These curly braces are from the notation for unordered sets). Features must be part of a previously loaded matrix. Features must be specified with a sign: either +, - or some 'Greek letter' variable. Within {, }, i.e. in feature bundles, the capital letters A, B, C, D, E can be used as variables replacing + and -. A, B, and C may also appear immediately preceded by a - as in: {A cons -A voc} for non-glides. On IBM compatibles using the IBM character set, the first five letters of the Greek alphabet α,ß,Γ,δ,ε may be used (remember that gamma is only given in its upper case form on the IBM). The Greek letters are translated into the capital letters A through E internally (The correspondences are {(α,A), (ß,B), (Γ,C), (δ,D), (ε,E)}).
The values of variable features bound by a rule application persist through the following output or variable conditions. (See variables and conditions)
Feature Compilation Messages:
Unidentified Feature: X
The following string was not a declared feature. Spelling
mistakes often cause this error, otherwise check that the
loaded matrix matches the loaded rules (use d/symbols).
Bad Feature Sign: X
The sign expected here was not in the set {+, -, A, .., E,
α, .., ε}. Most likely a spelling error or a misread feature
due to loading mismatched rule and matrix files.
3.4.2 Types of Rules
There are four types of rules provided for: insertion, deletion, replacement and movement or permutation rules. Rules have four potential parts, the target which appears before the arrow (-->), its replacement which appears after the arrow, and the left and right contexts or environments of the target which appear after the slash (/) and to the left or right of the environment bar (__). Remember that a context sensitive rule written A-->B/C__D in standard phonological notation is the same as the rule CAD-->CBD. (See 3.4 for rules as larger blocks). Rules of permutation are written using a transformational notation with the ==> arrow and numbers in the replacement part.
Rule Messages:
Slash (/) Required!
It is not possible to distinguish the replacement from the
context without a slash.
Ambiguous Without Bar (__)!
The left and right contexts cannot be identified
Overgeneration: Indeterminate Insertion Point
Insertion with no context at all!
Conflation Used Improperly Outside of Environment
Conflation is not allowed in the target or replacement parts
of the rules. (see 3.4.4)
3.4.2.1 Replacement Rules
A --> B / C __ D
A is changed into B or receives the features of B in an optionally specified environment, where __ marks the position of A and C is the preceding context and D the following context. (A is the target part and B is the replacement or change part of the rule.) Either C or D may be omitted. If both C and D are omitted then the slash / may be omitted. The following are correct rules:
sk --> sh OR sk --> sh /
p --> b / __ + {+nas +cons}
{+voc -cons +high} --> {-high} / p __
{-voice} --> {+voice} / {+voice} __ {+voice}
A replacement of features may produce a form with no current surface representation. This is not treated as a fatal error, but a message is printed.
Indirect Insertion or Deletion.
Coalescence and some types of indirect insertion are also supported (e.g. ey --> I or I --> ey where I, e, y are all phonemes). The replacement symbols are matched one-to-one to the target symbols from left to right and the leftovers are inserted or deleted. In the example, I and e affect each other but y is deleted or inserted as a phoneme. This only becomes important when a rule changes features, for example:
will delete the second +syll segment and impose its values for back and rnd on the first segment, so the other features of the first segment had better be the same as those of the second if true coalescence is being modeled (the values for high and low get changed vacuously, but it looks nicer to leave them in). The compiler prints a message about indirect insertion or deletion just in case it might be unexpected. See {},_ in variables.
If skp is on, the skipped elements will stay where they are and the left-over non-corresponding indirectly inserted elements will follow immediately after the last corresponding replacement. (If this is too fuzzy an explanation, load swa.max, put in the rule joy-->pride and type <<#j1o23y45#. You'll see what I mean.)
Replacement Rule Messages:
No Surface Form -- continuing ...
The symbol ░ takes the place of the unrepresentable bundle
of features. Taking what form was changed and what changed,
you can use the compare and classify functions of the matrix
editor to determine what phoneme is missing or predicted.
Implied Insertion of Last N
Implied Deletion of Last N
The last N symbols in the replacement will be simply
inserted or deleted. This is provided as information.
3.4.2.2 Deletion Rules
A --> / C __ D
If A is to be deleted, no replacement is required. Either C or D or both may be omitted, even though a rule of deletion without context is pretty radical (I mean, wildly abstract!).
r --> / {+stri} {-cont} __
Deletion may be implicit in rules like A --> B where B is a string of symbols shorter than A. A message is given to inform you, in case this is not desired. This will occur in replacement rules. (See 3.4.2.1)
3.4.2.3 Insertion Rules
--> B / C __ D
A may ONLY be omitted if either C or D IS present, e.g. -->t/{+voc}__{+voc}. Insertion rules without context (e.g. --> t) would overgenerate in an uninteresting way as would those where variables make the insertion point indeterminate.
Whatever is inserted in this way should not be a partial feature specification unless some form of recovery is planned by means of a later rule which will finish specifying the phoneme so that it will have a surface form in the current matrix. In the following rule no printable form might exist, but a later rule might provide voice and nasality information that would lead to printing t, d, or n:
Unprintable specifications of phonemes are printed as ░ (ASCII 176) and a warning is issued.
It should be noted that since the matrix currently is two-valued, the non-specified features are all set to -, so that it is sometimes hard to really underspecify elements, especially if you try to minimize the number of features. In the example above, you might get t if only voice and nasality distinguish the three. If you want to do so, sometimes it is useful to put the underspecified element in the matrix so it can be printed.
Insertions with variable features may be more useful as in:
which inserts y between i and u, o, a and w between u and i, e (using the supplied swa.max matrix). The -syll and -cons features could have been left out since all other features are - by default, but by including them the rule looks much more reasonable. If the all negative default is bad, try defining a seriously unreal element (like all pluses) in the matrix (use ASCII 177 ▒ for example) and starting from it. Don't use an all minus phoneme, because it is already used as a variable (namely {}) to match any phonemic element.
Insertions may sometimes be indirect as described in 3.4.2.1.
Insertion Rule Messages:
No Surface Form -- continuing ...
The symbol ░ takes the place of the unrepresentable bundle
of features. Taking what form was changed and what changed,
you can use the compare and classify functions of the matrix
editor to determine what phoneme is missing or predicted.
Unrepresentable Insertion!: X
What is to be inserted does not have a surface
representation in the current matrix, but the user may be
planning on finishing the specification in later rules, so
the rule is compiled.
Overgeneration: Indeterminate Insertion Point
This message is given when the environment for insertion is
undefined or bounded only by variables:
--> b / c ... __,
--> b / __ ... c,
--> b / c ... __ ... d
In such cases, the insertion point is considered to be
underdetermined and the rule is not compiled.
3.4.2.4 Permutation Rules
CABD ==> 1, 3, 2, 4
Permutation is supported with the transformational notation ==> and numbers set off by commas in the replacement (i.e. Structural Change) corresponding to each segment in the target (i.e. Structural Description). In a non-standard way, the mixing of transformational and context sensitive notation is permitted so that
AB ==> 2,1 / C __ D
is a valid rule in Fonol with the meaning CABD ==> 1,3,2,4. All this means is that you are dispensed from writing a list of numbers which includes all the non-moving context (merely a notational variant). The contents of the target are currently restricted in the same way as ordinary rules, meaning that, while the items which are moved do not have to be neighbors (i.e. ABCD ==> 4,2,3,1 is OK), parenthetical, variable and curly brace items are not currently permitted between the permuted elements. These conflations are permitted in the context parts of the hybrid notation. (See 3.4.4)
Index numbers start at 1 and are currently supported up to 10 (10 is purely arbitrary). [In a future version, 0 will be used for deleting segments in transformations.]
For those cases where the number of distinguishing features does not exceed the number of Greek letter variables, feature bundles may be used in an interesting way to achieve permutation by rules of the form: {αfeat}{ßfeat} --> {ßfeat}{αfeat} where ß could be -α. The same thing could be done with specified +,- features. Note that these rules work as replacement rules, the segments on the right hand side are actually in the same order as those on the left hand side.
][skp will work with these permutations, but the skipped parts will simply stay where they were.
Permutation Message:
Segment Miscount in Transformation -- SD: N SC: M
Segment to index mapping is one-to-one to avoid mix-ups. Try
to count segments beforehand. If things are still strange,
try putting blanks around all the segments you believe to be
present or do d/symbols and look for confusable sequences.
3.4.2.5 Transformational Rules
Transformational rules are not yet fully supported in Fonol 4.0.0, but the phonological rules discussed above are not as restrictive as is ordinarily the case for phonological context sensitive rules. The target portion may include some of the environment and some multiple 'simultaneous' operations may be performed as noted in the discussion of coalescence. The current system may be suitable for your purposes. Experiment.
3.4.3 Types of Filters and Conditions
Filters or conditions are specialized types of rules which constrain the operation of other rules. They are related to flow of control in that they affect whether the derivation continues, whether a rule is applied, and whether a successful application of a rule is valid. The types provided for are the usual star which blocks the derivation, negative and positive input conditions which determine if a following rule may be applied (blocks the rule), conditions on valid contents for a variable in the rule, and a negative output condition which undoes the result of the preceding rule (blocks the rule post factum). When several of these conditions precede or follow a rule they are automatically treated like a disjunctive block of rules (see {[, ]})
There are currently six types of condition: Positive Input Conditions, Negative Input Conditions, Negative Output Conditions, Positive Indexed Variable Conditions, Negative Indexed Variable Conditions, and the Star Condition. Star Conditions are totally independent of rules, naturally, since their scope is the derivation. Other conditions have a rule or disjunctive block of rules as their scope. Input Conditions may be mixed in any order and are placed above the rule. Indexed Variable Conditions may be mixed in any order and follow the rule. Output Conditions follow the rule and should follow all Indexed Variable Conditions present. This is because the Variable Conditions determine if the rule really applied, but the Output Condition determines if the rule should have applied. A full description of each type of condition follows.
Conditions are treated like the environment portion of rules and so may contain any sort of conflation. (See 3.4.4)
Note: The conditions allowed here only express one relationship: the subset relationship. Without constraints of some sort, conditions would totally destroy any restrictiveness built into the ordinary rules of a theory. Unfortunately, there is no source for determining what relations should be expressed by conditions (e.g. a set of stone tablets) and many conditions have been written quite innocently which would make hash of any notion of restrictiveness in grammars. Please think about this and give me your opinions.
3.4.3.1 Star Filter
** string
This symbol is placed before a description string to define a true filter. If string is found, then the derivation will stop immediately and the intermediate form will be starred.
** {αcons ßvoc} {αcons ßvoc}
means no clusters of consonants, vowels or glides!
** {+cons +nas} {| {+cons} |}
{| # |}
means a nasal consonant never either precedes another consonant or a word boundary.
3.4.3.2 Input Conditions on Rules
+i* string
This symbol is placed before a description string to mark a Positive Input Condition. If the condition is false, the next rule or disjunctive block of rules will be skipped over. All other conditions associated with the rule or disjunction of rules are automatically skipped and the derivation continues. For example,
+i* [N...+...]
means the next rule applies to nouns with internal morpheme boundaries only and
+i* {-cons -voc}+Past
would mean that the following rule applies only to forms with a stem ending in a glide before a past tense marker.
-i* string
This is placed before a description string to mark a Negative Input Condition. If the condition is true, the next rule or block of rules will be skipped over. Other conditions are skipped and the derivation continues. For example,
-i* +
means the next rule does not apply to forms containing morpheme boundaries and
-i* {+syll}({-syll}({-syll})){+syll}
would mean that the next rule does not apply to any form with two or more syllables (i.e. only to monosyllables).
All input conditions should be put in a group before the rule or disjunction of rules they apply to. They should not be put in a disjunctive block. They will be applied like a disjunctive block in that only one need apply to block the rule.
3.4.3.3 Output Conditions on Rules
-o* string
The Negative Output Condition is symbolized by placing -o* before a description string. If the pattern of the description string matches, the result of the previous rule is undone and the derivation continues. For example, -o* #(C)V(C)# means the previous rule cannot apply to produce monosyllables.
Sets of Output Conditions are applied disjunctively, that is, as soon as one applies, all other following conditions are skipped. Conditions should not be put in a explicit disjunctive block.
Negative Output Conditions inherit the bindings accomplished by any variable features in the rule itself. Values that are bound by an output condition are not passed on to subsequent conditions.
{-syl αvce} --> {-αvce} / __{αvce}
-o* {-syl αvce ßhigh} {-syl αvce ßhigh}
-o* {ßlow ßant +vce -syl}
In the fictitious sequence above, the α value will always be that resulting from the application of the rule, but the ß values are not shared by the conditions. This is, I think, correct, since (1) Output Conditions hold on rule results and (2) sequences of Output Conditions are treated as disjunctive blocks and as such should never accumulate values.
3.4.3.4 Conditions on Variables
+v*N string
-v*N string
Conditions may be placed on indexed variables in rules as to their contents. +v* N string means that the variable indexed with N in the preceding rule must contain string somewhere if the rule is to be validly applied. -v* N string means that string must not be found in the variable. If the variable condition does not hold, the change accomplished by the rule is undone and the rule is reapplied until it fails completely or all variable conditions are satisfied. Variable conditions are applied conjunctively: all must be satisfied (even if vacuously) for the derivation to continue. The ordering of variable conditions should not be crucial, but they should precede all output conditions.
Both positive and negative variable conditions inherit the feature variable bindings of the rule, but do not pass bindings on to subsequent conditions.
Negative Indexed Variable Conditions complement conflation by adding a logical not to the normal and applied to segments to be matched (including ordinary variables) and the varieties of or expressed by parentheses and curly braces. (See 3.4.4) It is hard to think of any equivalent to these sorts of condition. See below for an example in the alternate syntax.
Positive Indexed Variable Conditions are, however, often equivalent to putting the same string in the rule. For example,
a --> b / c ...2 d __
+v* 2 z
versus
a --> b / c ... z ... d __
However, this equivalence does not hold if there are several positive conditions with overlapping descriptions. There is also a difference in inheritance of variable feature bindings between a positive condition expressed in the rule and expressed as a condition (as noted above). All these factors should be considered and tested when deciding if a Positive Indexed Variable Condition is appropriate.
In the type of positive condition where the variable contains only certain sequences, a solution is to create an abbreviation for a large enough parenthesized expression to cover the expected cases. (This is not quite cheating. It is the same trick used by some theoreticians to remove recursion from syntax.) For example,
would create an element for use in rules which only contains nasal segments. Alternatively, the same effect is gotten by putting in a variable and applying a negative condition like:
-v* 7 {-nas}
Alternate Syntax
where N contains string
where N does not contain string
An alternative syntax for v* is allowed, using the strings 'where', 'not', and 'contain'. These strings must be in all lower-case, the first non-blank string must be 'where', a number is expected somewhere after 'where' and the pattern to be matched will be everything remaining in the line after the first blank following the string 'contain', so that 'where 7 is currently containing {+vce}' and 'where the variable X7 contains: {+vce}' are both equivalent to '+v*7 {+vce}'. Remember that blanks can be used to indent these conditions to increase readability. For example,
][X==...
[> Iterative Nasalization of Vowels
{+voc} --> {+nas} / {+cons +nas} X1 __
where X1 does not contain {+cons -vce -cont}
<]
means nasalize every vowel between a nasal consonant on the left and a voiceless stop on the right.
Variable Condition Messages:
Variable Condition Without Variable Index
No number was found.
Variable Index Out of Range (1-9)
If a number character follows the index, make sure a blank
separates it from the index number. Otherwise, zero is the
index of all unindexed variables and I hope 9 is enough!
Variables are described in 3.4.4.2.
3.4.4 Rule and Filter Conflation
Rule sets related by having the same target and replacement and similar environments may be conflated by the use of parentheses (,) for optionality, curly braces {|, |} for a list of choices, undistinguished variables ... over segments, and disjunctive block markers {[,]}. These may all be used together in the same rule naturally. Conflation also takes place by the use of feature bundles and variable signs, but those forms of conflation are treated in the section 3.3.1 above on feature bundles. The curly brace, variable (except the unit variables {} and _), and parenthesis conflations are not allowed in the target and replacement parts of the rules. The order of actual matching for curly brace, variable, and parenthesis conflations is generally like this: Parentheses shrink. Variables grow. Curly braces make choices from top to bottom and then from left to right. The order of match operations is designed not to overlook any of the possible patterns represented in the conflation, especially because of one pattern being a subset of another. The order of application should be what is normally expected. If the ordering between rule subparts is crucial for any reason and it appears that ordinary conflation is not applying in the right order, the disjunctive block should be used instead of the other conflations to test for a problem. Also note that disjunctive blocks are not equivalent to other forms of conflation since the rule writer determines the exact order of application of rule 'parts'.
Indexed angled braces <, > -- as used in SPE -- are not supported directly, partly due to compilation difficulty and partly due to readability on a character oriented display. The same effect can be had with disjunctive blocks, and on going to paper, you can 'fix' it up pretty. [Honestly, though, without constraints, what sort of naturalness can you expect from a notation like that? There, I said it!]
Conflation Messages:
Rule Too Conflated -- Too Many ...,(,),{|,|}
The stack for keeping track of conflation symbols has
overflowed. Reduce conflation in the current rule
(disjunctive blocks {[, ]} can be used) and let me know if
the limit is set too low. This is a run time error, not a
compile time error.
Meaningless Conflation -- Variable or Parenthesis on Rule Edge
This conflation will not be able to make any difference to
the applicability of the rule.
Conflation Used Improperly Outside of Environment
Some conflation has been used in target or replacement parts
of the rule, so that the operation of the rule is not
clearly defined.
Overgeneration: Indeterminate Insertion Point
This message is given when the environment for insertion is
bounded only by variables:
--> b / c ... __,
--> b / __ ... c,
--> b / c ... __ ... d
In such cases, the insertion point is considered to be
underdetermined.
Too Many Open: X
Too Many Close: X
There is a mismatch in the conflation symbols X.
3.4.4.1 Parenthesis
A --> B / (C)(D)E __ (F(G(H)))I
Parentheses may be used in the context part of the rule for optional parts. The form the rule may take is as above.
If parentheses are used in the target (i.e. A) or replacement (i.e. B) parts of the rule, they will be not be recognized and the rule will not work. This is to distinguish the contextual parts of the rule from the target sequence and the replacement or change that is to be performed on it. Note that the order of application starts with the widest environment (i.e. including the parenthesized portions) and then narrows by excluding parenthesized portions if they cannot be matched. All potential patterns created by parentheses are found.
Superscript/Subscript Notation
This notation is not directly supported, but assuming V for {+voc} and C to represent the feature bundle {+cons -voc}, the C superscript 3 subscript 1 notation would be (C(C))C or C(C(C)) as shown below:
V --> {αhigh ßlow} / __ C (C (C)) {+voc αhigh ßlow}
One way of making this neater (?) is to use abbreviations:
][C31==C(C(C))
3.4.4.2 Variables
...
A --> B / C ... D __ E ... F
The variable ... will match anything from the null string on up. It may only be used in the context part of the rule, just like parentheses. A rule with variables in the target or replacement parts is currently considered indeterminate. Variables may be used in iterative loops to achieve the effect of 'smearing', for example, to nasalize all vowels preceding a nasal consonant:
[>
{+voc -nas} --> {+nas} / __ ... {+cons -voc +nas}
<]
Variables on the extremities of the context are useless:
A --> B / ...C__D... is equivalent to A --> B / C__D
Note that the order of application with variables is first the smallest environment (... equal to the null string) and then wider environments with ... including more and more of the string. Since matching goes left to right, each new variable will begin with null and grow to the right.
The symbology for variables was chosen to leave the user in control of all characters which might be used to represent phonemes. It is a simple matter to use ][X==... to make a more conventional looking variable name.
...N
Indexed variables are used with conditions on variables. They function just like variables, but their contents are kept until another regular rule applies. A variable condition (e.g. +v*, -v*) following the rule can be applied to the contents of a variable by referring to its index. The index N must be a number from 1 to 9 immediately adjacent to the variable. (If a number character is being used in your rules next to a variable, but not as an index, then use a blank to separate it from the variable.) Once again an abbreviation can be used: ][X==... to make X1 work in your rules. See 3.4.3.5.
{}
{} is a variable which will match any one phoneme.
_
_ is a variable which will match any one non-phoneme.
Both _ and {} can be used in the target part of the rule. They are mainly provided as a replacement for the feature segment which has been used to integrate true phonemes with some relevant non-phonemes in a feature representation--this way you don't need to put everything in the matrix. Use with care! (Remember ][skp+)
skp
Speaking of ][skp+, remember that this convention is like having a variable containing any number of non-phonemes stuck between every item named in your rule.
α feature
Variables for signs of features hold their values within rules and conditions. Also, like indexed variables, when they are bound in a rule with --> or ==>, they hold their values through all the variable and output conditions which may follow that rule.
3.4.4.3 Curly Braces
A --> B / {| C |} __ {| D |}
{| E |} {| F {| G |} |}
{| H |}
Curly Brace notation for conflating rules is also supported ({|, |} for lack of a more attractive alternative). These are a disjunctive set, an or. Curly braces are only allowed in the context or environment portion of the rule. The braces {| and |} must line up visually to work. If some segment, like D above, is to be followed by other deeper curly brace options, it must be on one of the top corners, like a funnel.
A --> B / __ {| C |} K
{| D {| E |} F |}
{| G {| H |} I |}
{| J |}
This example conflates the patterns:
ACK
ADEFK
ADGHIFK
ADGJIFK
If you violate the 'funnel' or 'visual lineup' principles, your rules will not work right.
One last example,
A --> B / __ {| C {| D |} |}
{| {| E |} |}
{| F {| G |}|}
{| H |}
This example conflates:
ACD
ACE
AFG
AFH
Were you to line up the G and H pieces with the D and E pieces, you would add the patterns ACG and ACH producing unexpected results, but it might take a while to notice! Note also that the outer curly braces on line two could not be omitted if F is ever to be found. But the outer curly braces on line four may be omitted. Visual continuity or a funnel is the shape to look for.
Note that you can orphan a section of your total logical rule if you interrupt the line sequence in curly braces (e.g. with a comment line). For purposes of numbering, editing, etc., the two examples above would be four lines or four 'rules' each to Fonol, but for purposes of application, it is one rule, indivisible.
Note that the order of application of rules in curly brace notation is from top to bottom and left to right, as in the example above. This should normally yield the expected SPE order of subcases, but in case of doubt convert to the disjunctive block alternative and see if there is any difference. (But remember that sets in curly braces are multiplied!)
Note also that empty braces are ignored. If you want a true zero choice use parentheses, i.e. ({| a |}) not {| a |}
{| b |} {| b |}
{| |}.
The all braces notation will find either a or b or fail, the combined parenthesis/curly braces notation will find a or b or neither. There is no provision for absence!
3.4.4.4 Disjunctive Blocks of Rules
{[
]}
These symbols, placed on lines by themselves, mark the beginning and end of a set of disjunctively ordered rules. If one rule in the set applies, then all the remaining rules are skipped. (Normally all rules are applied one after another, conjunctively, to produce an acceptable derivation.)
The rules in the block behave as if they were one rule. Input conditions placed before the disjunctive block and variable and output conditions placed after the block will apply to the whole block (i.e. to whichever of the rules happens to apply). Rules inside a disjunctive block may have their own conditions and conflations, however disjunctive blocks may NOT be nested. Comment lines are allowed in the usual way. Comments may also be written after the block marker as a label for the overall logical rule (so long as the block marker is the first symbol on the line). Disjunctive blocks can be used when the other types of conflation do not work correctly due to order of application of subcases and when the rules to be disjunctively ordered do not have enough in common to be conflated. For example, here are the cases for Swahili Class 1 (human) subjects:
{[ Negative Prefix Insertion
NEG+1stSgCl1 --> si
NEG --> h / __ + {| 2ndSgCl1 |}
{| 3rdSgCl1 |}
NEG --> ha
]}
Note please however that disjunctive blocks are NOT automatically equivalent to conflations with variables, parentheses or curly braces.
{[
a --> b / c__d
a --> b / e__f
]}
lacks two of the cases (ead, caf) found in
a --> b / {| c |} __ {| d |}
{| e |} {| f |}
(I wouldn't mention this except it is one of my own careless errors!)
Note that conditions and filters are automatically treated as disjunctive blocks without requiring explicit block markers whenever they would result in the blocking or reversal of a rule. If you put explicit block markers around them, the interpreter may lose track of parts of your rule.
3.5 Loops: Cycles, Iteration
[> type
<]
These symbols, placed on a line by themselves, mark the beginning and end of a block of rules which are to be distributed over their potential contexts in the base form. With these it is possible to define a set of cyclic rules as well as pre- and post-cyclic rules and iterative rules. Type is one of the two main types of loop (iterative and cyclic) described below. Declarations are provided to produce subtypes of loop.
Nesting is permitted to a depth of 5, although it is hard to imagine any useful nesting beyond two. Any type of loop may be nested in another type, but again, it only seems reasonable to include iterative loops in (syntactic) cyclic loops (see explanation in following sections).
Sequential loops seem a reasonable way of handling the sort of modularity where groups of rules apply one after the other, iteratively or based on some sort of boundary (syntactic cycles).
Loop Messages:
** Loops Nested Too Deep **
There is no fix, but I would be surprised if you needed to
exceed this limit. Write me.
** More Loop Ends Than Starts **
The loop ends order a pop of a loop start stack. This is
detected at run time. Check for miscounts on loops by using
d/[> and d/<]. An imbalance in favor of starts is not
detected.
Loop halted. Limit exceeded between N and M
The loop has run past the limit (currently 30 iterations)
and the possibility is strong that it is infinite.
Use d/N M to see the affected part of your rules and look
for rules that undo one another's effects or create their
own context. Usually the problem will be obvious if you have
been watching the screen. (Turn off /[hide!) The program is
designed so that many vacuous rules in loops terminate
successfully, but this is the safety net.
Note on Rule Reapplication
The repeated application of rules can be thought of as looping or as the distribution of a rule over its contexts in an intermediate form. Some effort has been put into ensuring proper distribution of the rules over contexts. This is especially a problem in iterative or across-the-board blocks where rules are to be applied to exhaustion (note: across-the-board has been used with other meanings, so iterative is most often used here). Currently rules are allowed to apply only once to each context they describe. This may not always be correct -- for example, should an insertion rule like --> b / c...__d apply once or twice to the string /cacad/? Currently it applies once like non-insertion rules would. Some rules that create their own context simply overgenerate (i.e. -->b / b__ or __b), because I don't bother to trap them, since I don't think they will arise in the rule sets you actually write. Please write me if rules placed in loops seem to apply too much or too little.
3.5.1 Iterative Loops (Across-the-Board Rules)
[> iter
This is the minimum for declaring a loop to be iterative. ([> defaults to iter.) The loop end is always <]. Rules in an iterative loop apply in order until they cannot apply anymore. Any rule can be defined as iterative by placing it within these block markers. Any comments are allowed so long as [> begins the line and the sequence iter is found somewhere on the line, e.g.:
[> Nasalization is Iteratively Applied to the Left
{+syll} --> {+nas} / {+nas} (C(C)) __
<]
is valid.
3.5.2 Syntactic Cyclic Loops
[> syn cyc
This is the minimum for declaring a loop as a syntactic cycle. Each rule within a syntactic cyclic loop is applied in order one time for each pair of [,] in the base form. The [,] in the base form must be paired and, naturally, may be labeled on the inside (i.e. [N xxx ] can be used by rules referring to nouns, N[ xxx ]N would have the Ns excluded until the next higher cycle). The [,] are the limits of the base form examined on each cycle. Declarations like ][mcpi+, ][ssc+, ][ats+, ][atdf+, ][rbi!, ][dbc+, ][cyccat:[XXX may be used to modify the behavior of syntactic cycles so that rules are applied in widely varying ways (see following discussion).
Note that such cycles do not have to be actually syntactic, merely bounded by [,].
Any commentary may be placed after [> so long as the two sequences syn and cyc are included in this order, for example:
[> Main Syntactic Cycle for English
[> Stem Oriented Syntactic Precycle
[> Totally Other Type of Cycle [syncyc]
are all valid.
Types of Syntactic Cycles
By using the various rule application declarations (see 3.1.3) with syntactic cycle blocks, it is possible to create a fairly large variety of rule application schemes. One fixed point which must be remembered is that the brackets must be present in the underlying form if applications are to be made based on them. Syntactic cycles will apply once to material outside the highest brackets.
The brackets do not all have to be in the original base form: free-form syntactic cycles are possible through the ][rbi! and ][dbc declarations. In such cases, erasure of brackets by rule is the only criteria for moving through widening (or changing) stretches of the base form.
In the following paragraphs, I will try to describe the varieties of directly supported syntactic cycles systematically.
1. If you use syntactic cycle block markers by themselves with all declarations off, you get a system in which the rules in the block are applied once for every pair of brackets ([,]) to the part of the string which is bracketed. If you have skp on (][skp+) and mcpi on (][mcpi+), then the cycle will behave like that of SPE. Alternatively, if you have skp and mcpi off, then you must delete the brackets and other non-phonological stuff to get the same effect.
2. If you place ssc+ before the block, no rule will affect anything in an embedded bracketed area. It does not matter if you erase the brackets or not. skp and the presence or absence of brackets will only affect the potential environments of rules, not the potential targets. Naturally preceding or following rules outside of a strict cyclicity block (ssc+, ssc-) would apply to the whole string. Apart from syntactic cycle blocks, ssc has no effect. I recommend putting the declaration ssc before and after the syntactic cycle block markers to keep the scope clear.
3. If ats+ is placed before a syntactic cyclic block, then the rules will only apply in the minimal bracketing ([X] where X does not contain [,]). A reason for putting the syntactic cycle block markers around the rules is to guarantee that the rules will apply to all minimal bracketings (i.e. in [ab[cd][ef]gh] to cd and ef). Once again, I would suggest using the ats + and - around the syntactic cyclic block to make the scope clear.
4. If atdf+ is placed before a syntactic cyclic block, the rules in the block will apply only in bracket pairs which contain other bracket pairs ([X] where X contains some [Y] but not individual unpaired [ or ]).
5. If Cyclic Category:[ is used the cycle will be constrained to those bracketings labeled according to the declaration.
6. If dbc+ is placed before a syntactic cyclic block, the rules will be applied first just as in ats+ to all minimal bracketings, then the base form will be scanned for brackets, new minimal bracketings will be detected and the rules will be applied again. This will go on until (1) there are no more brackets or (2) the bracketing is extremely confused. The first halting case should be normal. The second may occur if your rules are capable of inserting or deleting brackets in an unpaired fashion.
If you insert brackets during a cycle, they will not be made effective until the rules have been distributed over all current minimal bracketings. This may look strange for a while on screen. And don't forget to turn it off after the cycle block (][dbc-).
7. The rbi! declaration has a safe use before a cycle block. That is a first set of rules (in a block or free standing) inserts or deletes brackets in the form being derived or changes the size of the original bracketed form. Then rbi! sets up the form for a following syntactic cycle block.
rbi! will work inside a cycle, but it is totally up to the user to manage the brackets. The loop will stop after about 30 tries if no rules apply to change the bracketing. Good luck!
Combinations:
Type 5 above may be mixed with any of the other types. Types 3 and 4 are mutually exclusive. Type 3 with type 2 is overkill. If type 2 is not mixed with type 4, rules may apply to stems (defined as minimal bracketings). If type 2 and type 4 are used together, no rules of that cycle will apply to stems.
If you put a type 3 cycle before a type 4+2, you have a model where there is a group of rules that apply only to stems followed by a group of rules that apply only to derived forms. Type 3 followed by type 4 means that there are some rules that apply only to stems and others that apply to derived forms in the SPE fashion. Naturally you can have other fantastic combinations where all the noun stem rules apply first in a block followed by all the verb stem rules, or whatever. The combination of declarations and sequencing of blocks allows for many different and complex models of rule application. Remember that iterative blocks may be included in syntactic cyclic blocks, where they will apply to whatever is the current bracketing. (As a matter of fact, some Lexical Phonological cycles I've seen look like they could be modeled in Fonol by putting iterative block markers immediately inside syntactic block markers so they include all the rules). Remember the scoping of declarations and block markers can modularize your rules in many ways. Rules outside of blocks will apply to the whole string once, so you can have postcyclic or precyclic rules, adjustment rules, and so on. Putting these declarations inside of blocks will work, but it is not altogether clear what the results would be. Let me know if the possible combinations (or their documentation) are inadequate. On the restrictive side, it is just a matter of not using what is provided.
