Possible segment types -
some hints for an alternative approach
This page assumes that you have experimented with using
negative conditions to
express feature co-occurrence restrictions within segments and goes on to provide
some suggestions for developing an alternative system based on positive
For the sake of comparison, the procedures on this occasion are aimed at
directly building possible bundles rather than filtering out illegitimate ones
derived from a random bundle generator. An advantage of this technique is that the same system can be used to build either partially specified feature bundles representing phonemes or fully specified bundles representing (allo)phones. The filter based approach, by contrast, needs a radical modification (see below) to cope with this distinction.
Expressing the conditions
Let us suppose - to start you off - that co-occurrence conditions can be expressed in English in the following ways -the particular conditions are simply illustrative:
Condition 1 - or some equivalent 'first' condition based on the presence of an empty bundle - is needed if we are to build feature bundles from scratch. If you like, you can interpret this 'first' condition as saying: Segments may be either vowels or consonants.
- If the bundle contains no features then choose and add in either [+syll] or [-syll]
- If the bundle contains [-cont -nasal] then choose and add in either [+voice] or [-voice]
- If the bundle already contains [+syll] then add in [+son +voice -str]
Conditions 1 and 2 differ from condition 3 in their treatment of the features to be added. The first two conditions allow a choice in the values associated with the additional feature(s), whereas condition 3 strictly determines the selection. This difference in condition type directly reflects the difference in the status of the features involved. Where a choice in feature value is possible, the distinction between values can be used to carry a meaning difference - i.e. the difference is distinctive. Where no choice is possible - in other words, where the feature value is predictable - we would say that the feature is non-distinctive. It follows that a control regime restricted to conditions of type 1 and 2 will build feature
bundles containing only distinctive features which hence represent phonemes. On the other hand, conditions of type 3 - typically called redundancy rules when used to extend the phonemic representation with additional predictable features - create bundles which represent phones or allophones.
Implementing the conditions
In Logo, both condition types can be handled in the same general fashion by
implementing each as a two-element list. The first element identifies a
structural description which is to be matched against the bundle currently
being constructed. The second element lists the choices of additional features
which are to be inserted if the current bundle matches the structural
description. Where the second sub-list contains a single element, there is, of
course, no real choice.
Using SPE based features with @ and ! as values, Condition 1, above, would thus look like
[ [ ] [ [@syll] [!syll] ] ]
Condition 2 would look like
[ [ !cont !nasal ] [ [@voice] [!voice] ] ]
and Condition 3 like this:
[ [@syll] [ [@son @voice !str] ] ]
Developing an interpreter
Making an initial stab at a procedure to interpret such conditions, you might consider
Pickrandom will do its job well enough, though as anticipated, in the case of Condition 2, it
will pointlessly pick an element from a one element list.
- subset? to check the
first element of each condition against the current bundle
- pickrandom to select
one of the constituent bundles of the second element of the condition
to insert when necessary.
On the other hand, subset?, as normally
defined, will face a problem with the first condition because the empty list is a subset of
every list. Subset?
cannot therefore be relied on to identify only those bundles which are completely empty.
Since you will no doubt hold all of the conditions in one
super-list (called, for example, :conditions), you might get around the problem by putting
Condition 1 in position 1 and by arranging things so that the only time it can be used is
at the very start of the bundle-building process. But you might usefully think about whether the set
of conditions should be ordered anyway. If you decide against, could you perhaps
instead define a new predicate match? in order to circumvent the problem?
(This predicate might, of course, itself use subset? to do some of its
As we noted, the
segment filter based on negative conditions outputs only fully specified
segments. As it stands, in other words, it cannot generate partially specified
phoneme bundles. What is interesting to see now is that the conditions are of
course neutral with respect to their use either in filling in or removing predictable
features. With a different interpreter (and only a minor change in the rule
format) they can also be used as the control structures for eliminating redundant
features from pre-existing fully specified matrices. Look here for a 'phonemicizer' which implements this
And finally . . .
Now is a good time consider whether a segment building mechanism based on positive conditions is more appropriate for the treatment of segment internal feature co-occurrence restrictions than a filter system based on negative conditions? If you prefer a more specific question, then ask yourself in which of the two ways it is easiest (or maybe even possible) to write a description of the segment types of some language of your choice? There is, naturally, always the option to argue that these questions are simply misplaced.