Possible segment types - first approach

A phonological filter

The purpose of the system presented on this page is to output at random a list (aka bundle) of ±valued phonetic features which meets a set of well-formedness conditions (WFCs). In other words, with theWFCs appropriately set up for a particular language, the system will generate - when run repeatedly - a series of representations of acceptable phonological segments within that language. It is assumed on this page that the WFCs can be expressed as a set of negative conditions, of the type NOT [+syll -voice], which can be directly implemented as a filter.

Tactics

Variables

There are two global variables. The first of these identifies the feature set - i.e. the names of the features used. While any such set of features is assumed to be universally applicable, there is so far only limited agreement on the collection of features best suited to handle the phonological capabilities of human beings. The set arbitrarily adopted here (feel free to change it) uses 17 binary features based on proposals in The Sound Pattern of English:

make "features [cons syll son ant cor dist high low back 
                                                     round nasal  cont lat del tense voice str]
The second global variable called "filters represents the gauntlet which any claimant to segmenthood must run. It is set up as a list of lists. Each sublist contains a combination of specified features which is deemed not to occur within a single segment in the language being accounted for. In the binary feature framework adopted here, features are normally specified by assigning them either a + or a - value. Since, however, some versions of Logo present difficulties in dealing with such special characters as parts of words, we will, in fact, use two less awkward characters as substitutes, @ (instead of +) and ! (instead of -). (See here for a work-around in Logo PLUS.) "Filters is, thus, set up according to the following pattern:
make "filters [[@syll !voice] [@high @low] [@str !cons]]
Taken together, the two variables, "features and "filters, constitute the linguistic facts:
  1. a universal feature system
  2. a set of language-specific co-occurence restrictions

Procedures

The toplevel procedure possible.bundle calls on get.bundle to create a randomly formed feature bundle using :features. It outputs the bundle if it passes the filters otherwise tries again . . . and again . . . (recursively) . . . until successful.

to possible.bundle
make "bundle get.bundle :features 
if passes? :bundle :filters [op :bundle] [op possible.bundle]
end
Get.bundle outputs a bundle containing every feature of :features marked (i.e. prefixed by) either @ or !. Plus.or.minus does no more than output the necessary @ or ! randomly. (You will find the procedure pickrandom here.)
to get.bundle :feats
if empty? :feats [op []] 
op fput word plus.or.minus first :feats get.bundle bf :feats 
end

to plus.or.minus
op  pickrandom [@ !]
end

Passes? is a predicate which recurses through the list of filters to see if any of the illegal combinations in the list occurs in :bundle. (The general purpose tool subset?, which is used in the check, can be loaded from here.) Notice that although it is the full set of filters - known globally as :filters - which is initially handed to passes? by possible.bundle, the (gradually reducing) list is known within passes? (i.e. locally) as :filter.list.

to passes? :bundle :filter.list
if empty? :filter.list [op "true] 
if subset? first :filter.list :bundle [op "false] 
op passes? :bundle bf :filter.list 
end
Download a Logo ready version of the procedures and variables from here.

On the other hand, if your Logo implementation provides some way of using + and - as characters, then you might want to try using representations which follow the conventions of the phonological literature more closely.

Look here for an alternative version of these procedures which uses strings.

Changing the conditions

You can obviously experiment with changing the conditions implemented in :filters. Why not attempt to develop a complete set of conditions for some language of your choice which would filter out all non-segments (or,if you like, allow through all and only the possible segments)?

While perhaps most of the conditions which you set up such exercise will necessarily be language-specific, others may be universal, i.e. absolute. Which conditions would you include as universal and can you say why are they universal?

Universal conditions should obviously be permanently present in the system. This means that if there are indeed universal conditions, then :filters should never be an empty list. When it is necesary to define the feature co-occurrence restrictions obtaining in a particular language, :filters should be added to rather than set up from scratch. If you prefer to separate out the universal and language specific condition, you could, however, work with two separate lists, one called "universal.conds, the other "lang.specific.conds and at start-up concatenate these with se under the name "filters:

make "universal.conds [[     ] [      ] . . .] 
make "lang.specific.conds [[     ] [      ] . . .]  
make "filters se :universal.conds :lang.specific.conds 
The linguistic facts are now dealt with in what is arguably a more appropriate modular fashion:
  1. a universal feature system (set up once only)
  2. a set of universal feature co-occurence restrictions (set up once only)
  3. a set of language-specific co-occurence restrictions (set up for each language)
Now look here for some ideas for a comparable system based on positive conditions.



Ron Brasington
Department of Linguistic Science
The University of Reading
Reading
UK

E-mail: ron.brasington@rdg.ac.uk