University:
Boston University
Course:
CAS LX 110 | Say What? Accents, Dialects, and Society
Academic year:

2020
Views:

271

Pages:

10
Author:

kwikhadidj7b

Recap: features Syntax • • • The lexicon contains bundles of features. These feature bundles are assembled by a computational process into syntactic structures for interpretation by the conceptualintensional an articulatory-perceptual systems. • Among these features, we have: • Interpretable features (such as the category feature that determines the category of the lexical item) • Uninterpretable features (such as the selectional feature [uN*] on a transitive verb). Uninterpretable features are intolerable at the interfaces, and must be removed (by checking the derivation crashes. Uninterpretable features Matching and Checking Uninterpretable features vary along two dimensions: Privative/unvalued; strong/weak. • Privative (uninterpretable) features (such as [uN*]) which are checked by matching features (such as [N] or [uN*]). • Unvalued (uninterpretable) features (such as [uInfl:]) which are checked by features that can provide a value (such as [tense:past]). • Strong (uninterpretable) features can only be checked if they are local (sister) to the feature that checks them. • Weak (uninterpretable) features can be “checked at a distance.” • Checking relates an uninterpretable feature and a matching feature, allowing the uninterpretable feature to be ignored at the interface. • If the uninterpretable feature is strong, the matching feature must be local (e.g., a feature of the sister) in order for the uninterpretable feature to be checked. Strong features can force movement, but because the system is economical (lazy), no movement is allowed just to check a weak feature. • • Agree If: • • • • • X has feature [F1], Y has feature [F2] [F1] matches [F2] • • If [F1] or [F2] is strong, X and Y share the same mother node Then: • • Any unvalued feature ([F1] or [F2]) is valued. The uninterpretable feature(s) is/are checked. • For [uInfl:] on an auxiliary, the [tense:past] feature (above it) matches it and values it as strong (in English), then the auxiliary must move up to T for the feature to be checked. • Merge: create a new syntactic object from two existing syntactic objects, with the label (features) projecting from one. Merge happens for one of the following two reasons: • To check an uninterpretable feature: the label of the one with the uninterpretable feature projects. X and Y are close enough, meaning: There is no closer matching feature between X and Y. For [uV*] on v, it matches the [V] feature of the verb below it, then the verb must move up to v to check [uV*]. Merge X c-commands Y or Y c-commands X [F1] and/or [F2] are/is uninterpretable. • • • Example: c-selection features, such as the [uN*] feature of P. To satisfy the Hierarchy of Projections: the label of the higher one in the hierarchy projects and no features are checked. • This only happens once all of the strong uninterpretable features in the non-projecting object have been checked (and any adjunctions to be done have been done) Adjoin, Agree, HoP • Move • • Adjoin (of an XP) is like Merge, but it does not result in the checking of a feature. • Merge always takes priority over Adjoin, so Adjoin only happens once the (strong) uninterpretable features of the object being adjoined to are checked. • Adjoining YP to XP results in another XP (the maximal projection is extended), so YP becomes in essence both a daughter and a sister to XP. • Agree is the operation that checks (and values where appropriate) features under c-command. • Hierarchy of Projections: T > (Neg) > (M) > (Perf ) > (Prog) > v > V • • Pat might have been eating lunch Agent (vAgent) NP daughter of vP:!! Experiencer (vExperiencer) NP daughter of VP: ! Theme PP daughter of V":! ! Goal NP daughter of V":!! Possessee (possessum) TP sister of V:! ! Proposition Examples: V moves to v, Perf moves to T The other is XP-movement, where a maximal projection moves up to a specifier of a higher phrase. • Example: The subject moving to SpecTP. Both happen because a strong uninterpretable feature needs to be checked. • NP daughter of vP:!! ! • • The Uniformity of Theta-assignment Hypothesis determines the !-role of an argument based on its position in the structure. • • • • • • One is head-movement, where a head moves up to join with another head. What has [uInfl:], what can value [uInfl:] UTAH • There are two basic kinds of movement. Things of these categories have [uInfl: ] features: • v, M, Perf, Prog [uInfl: ] features can be valued (via Agree) by: • • • • Tense features (past, present) of T. -s or -ed. Perf feature of Perf. -en. Prog feature of Prog. -ing. M feature of M. -Ø (silent) 1) Pat [past] ha-d be-en eat-ing lunch. TP NP Pat v! T V+v=? ! T+M MP might < might > PerfP Perf have V eat ProgP Prog vP be < Pat > v! A completed tree. v v +V VP eat < eat > NP lunch v [uV*, . . . ] VP NP • When V moves to v, they combine in a way that we have been writing just as V+v. Let’s be more precise. • In fact, we assume that V head-adjoins (adjoins, head-to-head) to v. This is the same sort of structure that Adjoin creates between maximal projections. • • The v head is replaced by the v head with V adjoined. Adjunction does not change projection levels—v is still a minimal projection, still the head of vP. But it is a complex head (it’s a v with a V adjoined to it). v! V+v=? v V eat • • • v! V+v=? VP v [uV*, . . . ] v NP What happens to the VP from which the V moved? It is still a VP, it must still have a head. The features of the VP are the features of the head (recall for example, that checking the uninterpretable feature on the head is the same as checking the uninterpretable feature on the projection of the head). The VP is still a VP, its head is still a verb (with category feature [V]), and presumably all the rest of the features as well. We notate the original location of the V by writing (standing for the “trace” left behind by the original V). But since must still be a bundle of features, the same one that was there before movement, is really just another copy (or, well, the original) of the verb. V eat • • v [uV*, . . . ] v V eat v [uV*, . . . ] NP Make a copy of V. Replace the original v is replaced by the syntactic object formed by Adjoining the copy of V to v. • If v has a [uV*] feature, this puts V close enough to v to check that feature. This is why we move V. • Note: This appears to make a change inside the object. Merge always happens at the root. However: Think about the root. It has the features of v, its head. It is a projection of v. There is a sense in which this is still affecting only the root node, it’s adjunction to its head. v! V+v=? VP v NP • • We always move V to v. • But why wasn’t this checked when we Merged v and VP? (Like the [uN*] feature of P is checked when we Merge P and NP…) • The Hierarchy of Projections says that v > VP: When you finish VP, you Merge it with v. Only then do you Move and Merge with other things. The HoP takes priority. • When you Merge two nodes in order to satisfy the HoP, you don’t get to Agree. You have to move to the next step (Merge or Move). Reason: v always has a [uV*] feature. V eat • • • node is labeled as a maximal projection (XP) if • Athere are no more strong features left to check. that v has [uInfl:] even when we’re • Notice finished with it and Merge it with the next head up (M, Perf, Prog, Neg, or T). But we still want there to be a vP. features (like the [uN*] feature(s) • C-selection of V, or the [uN*] feature of P) are always v [uV*, . . . ] VP NP That’s craziness, isn’t it? Now instead of one V, we have two identical copies. Why don’t we get Pat Pat ate ate lunch? We need both copies (the higher one to check the feature, the lower one to head the original projection of V). But on the other hand, the verb was picked from the lexicon just once. A-P interface: Only the highest copy is pronounced. Spelling out the idea that you “move it but leave a trace.” Highest copy = the one that is not c-commanded by another copy. A head V adjoined to another head v ccommands the same nodes that v did. This is a stipulation, but if we define ccommand in a more complicated way, it comes to this. A general property of adjuncts is that they are “just as high” in the tree as the thing they adjoined to, so they “see” (c-command) the same stuff as the thing they adjoined to. T has [uN*] (“EPP”) A note on node labeling strong. Moral: “Head-movement” can be viewed as Copy+Adjoin. v! V+v=? VP • • V moves to v: • v has a [uV*] feature (always). Moving the subject from SpecvP to SpecTP: • • T has a [uN*] feature (always). Moving the subject (making a copy and Merging it with T) put the N feature of the subject close enough to T for the [uN*] feature to be checked. As for why you don’t satisfy the [uV*] feature of v the same way, by moving VP into SpecvP, we could speculate, but there’s no particularly satisfying answer. We’ll set that aside. Only auxiliaries move to T 1) I do not eat green eggs and ham. 2) I have not eaten green eggs and ham. Auxiliaries moving to T auxiliaries and main verbs behave differently, • Since they must be differentiated. Suppose auxiliaries have the feature [Aux] (“the property of being auxiliaries”). 3) I have not been eating green eggs and ham. 4) I would not have been eating green eggs and ham. • There is a set of things that move to T—the auxiliaries (have, be, modals). Main verbs do not move to T. Only the top auxiliary moves to T. • Movement is driven by strong features. move. Movement is driven by a strong • Auxiliaries feature. But what strong feature? • [uAux*] on T? • No. That does not work. • [uT*] on Aux? • No. That would not be promising. Auxiliaries moving to T • Auxiliaries have a [uInfl:] feature, valued by the next thing up. • The topmost auxiliary has its [uInfl:] feature valued by T. • The topmost auxiliary is the only auxiliary that moves to T. • An auxiliary whose [uInfl:] feature is valued by T will move to T. • Movement is driven by strong features. • • • • It appears that we need to say this: • If a head has the feature [Aux], and • If that head’s [uInfl:] feature is valued by T, • Then the feature is valued as strong. • The auxiliary must move to T to be checked. • • 3) Jean mange souvent des pommes. 4) *Jean souvent mange des pommes. • If we suppose that the basic structures are the same, why might that be? V raises to T in French • What it looks like is that both V and auxiliaries raise to T in French. • This is a parametric difference between English and French. • A kid’s task is to determine whether V moves to T and whether auxiliaries move to T. John does not love Mary. John has not eaten apples. …all verbs seem to show up before negation (pas) in French: • In French it’s the other way around. Jean eats often of.the apples ‘Jean often eats apples.’ French vs. English • • In English, adverbs cannot come between the verb and the object. 1) *Pat eats often apples. 2) Pat often eats apples. T[tense:pres] … be[Aux, uInfl:] T[tense:pres] … be[Aux, uInfl:pres*] T[tense:pres]+be[Aux, uInfl:pres*] … Similarly, while only auxiliaries in English show up before negation (not)… French vs. English Jean (n’)aime pas Marie. Jean (ne) loves not Marie ‘Jean doesn’t love Marie.’ Jean (n’)a pas mangé des pommes. Jean (ne)has not eaten of.the apples ‘Jean didn’t eat apples.’ T values [uInfl:] on Aux T values [uInfl:] on v English Strong Weak French Strong Strong Zinédine (n’) aime pas Marco Zinédine (n’) aime pas Marco • • First, build the vP just as in English. • Merge aime and Marco to form the VP, Merge v and VP to satisfy the HoP, move V to Adjoin to v to check v’s [uV*] feature, Merge Zinédine and v!. Merge Neg with vP to form NegP (following the HoP). NegP vP NP Zinédine Neg pas v! v V aime NP Zinédine VP v [uInfl:] v! v NP Marco Zinédine (n’) aime pas Marco • • vP Merge T with NegP to form T! (again, following the HoP). Now T with its [tense:pres] feature c-commands v and its [uInfl:] feature. They Match. But in French, when [uInfl:] on v is valued by T it is strong. So… V aime VP v [uInfl:] • v has to move to T. Notice that at this point v has V adjoined to it. You can’t take them apart.The whole complex head moves to T. T![tense:pres, T, uN*, . . . ] T NegP Neg pas v vP NP Zinédine v ! v v T [tense:pres, T, uN*, . . . ] ! NegP T V v aime [uInfl:pres] Neg vP pas < NP > v! So, French is just like English, except that even v moves to T. VP NP Marco vP NP v! Zinédine VP NP Marco Swedish • TP T Neg pas And then, we move the subject up to SpecTP to check the final uninterpretable (strong) feature of T, [uN*]. NP Zinédine T NP Marco Zinédine (n’) aime pas Marco • NegP V v aime [uInfl:pres*] VP V v aime [uInfl:pres*] NP Marco Zinédine (n’) aime pas Marco T![tense:pres, T, uN*, . . . ] T • Looking at Swedish, we can see that not only do languages vary on whether they raise main verbs to T, languages also vary on whether they raise auxiliaries to T: • …om hon inte köpte boken whether she not bought book-the ‘…whether she didn’t buy the book.’ • …om hon inte har köpt boken whether she not has bought book-the ‘…whether she hasn’t bought the book.’ So both parameters can vary. • Remember the light box: By saying these were parameters, we predicted that we would find these languages. • • Typology of verb/aux raising Irish • Interestingly, there don’t seem to be languages that raise main verbs but not auxiliaries. • This double-binary distinction predicts there would be. • It overgenerates a smidge. This is a pattern that we would like to explain someday, another mystery about Aux to file away. • Sorry, we won’t have any satisfying explanation for this gap this semester. T values [uInfl:] on Aux T values [uInfl:] on v English Strong Weak French Strong Strong Swedish Weak Weak Unattested Weak Strong In Irish, the basic word order is VSO (other languages have this property too, e.g., Arabic) 1) Phóg Máire an lucharachán. kissed Mary the leprechaun ‘Mary kissed the leprechaun.’ • We distinguish SVO from SOV by supposing that the headcomplement order can vary from language to language (heads precede complements in English, heads follow complements in Japanese). • We may also be able to distinguish other languages (OVS, VOS) by a parameter of specifier order. • But no combination of these two parameters can give us VSO. Irish • SVO to VSO But look at auxiliary verbs in Irish: 1) Tá Máire ag-pógáil an lucharachán. is Mary ing-kiss the leprechaun ‘Mary is kissing the leprechaun.’ • We find that if an auxiliary occupies the verb slot at the beginning of the sentence, the main verb appears between the subject and verb: Aux S V O. • What does this suggest about • • The head-parameter setting in Irish? • Irish appears to be essentially an SVO language, like French. • • Verbs and auxiliaries raise past the subject to yield VSO. • V and Aux both raise to T (when tense values the [uInfl:] feature of either one, [uInfl:] is strong) in Irish, just as in French. How VSO order arises? We can analyze the Irish pattern as being minimally different from our existing analysis of French— just one difference, which we hypothesize is another parametric difference between languages. French vs. Irish • Remember this step in the French derivation before? (I’ve omitted negation to make it simpler.) • What if we stopped here? • • • Parametric differences • In French it would crash (why?). • But what if it didn’t crash in Irish? T![tense:pres, T, uN*, . . . ] What would have to be different? T v We could analyze Irish as being just like French except without the strong [uN*] feature on T. vP T V v aime [uInfl:pres*] NP v! Zinédine VP NP Marco • Without that feature, the subject doesn’t need to move to SpecTP. The order would be VSO, or AuxSVO. So, languages can vary in, at least: • • • • • Head-complement order (Head-specifier order) Whether [uInfl:] on Aux is strong or weak when valued by T Whether [uInfl:] on v is strong or weak when valued by T Whether T has a [uN*] feature or not. (Later, when we look at German, we’ll suggest a different analysis of Irish, but this will work for now.) do-support • In French, verbs move to T. In English, they don’t move to T. • • That’s because in French, when [tense:past] values [uInfl:] on v, it is strong, and in English, it is weak. What this doesn’t explain is why do appears sometimes in English, seemingly doing nothing but carrying the tense (and subject agreement). • • The environments are complicated: 1) Tom did not commit the crime. 2) Tom did not commit the crime, but someone did. 3) Zoe and Danny vowed to prove Tom innocent, and prove Tom innocent they did. 4) Tom (has) never committed that crime. • do-support The environments are complicated: 1) Tom did not commit the crime. 2) Tom did not commit the crime, but someone did. 3) Zoe and Danny vowed to prove Tom innocent, and prove Tom innocent they did. 4) Tom (has) never committed that crime. • When not separates T and v, do appears in T to carry the tense morphology. • When T is stranded due to VP ellipsis or VP fronting, do appears in T to carry the tense morphology. • When never (or any adverb) separates T and v, tense morphology appears on the verb (v). • So, do appears when T is separated from the verb, but adverbs like never aren’t “visible”, they aren’t in the way. Technical difficulties Technical difficulties How do we generally know to pronounce V+v as a past tense verb? • T values the [uInfl:] feature of v. The presumption is that eat +v[uInfl:past] sounds like “ate.” And T doesn’t sound like anything. • But this happens whether or not v is right next to T. v still has a [uInfl:] feature that has to be checked. • So, the questions are, how do we: • • Keep from pronouncing the verb based on v’s [uInfl:] feature if T isn’t right next to it? • Keep from pronouncing do at T if v is right next to it? • The connection between T and v is that (when there are no auxiliaries), T values the [uInfl:] feature of v. • This sets up a relationship between the two heads. • • Adger calls this relationship a chain. We want to ensure that tense features are pronounced in exactly one place in this chain. • If the ends of the chain are not close enough together, tense is pronounced on T (as do). If they are close enough together, tense is pronounced on v+V. We need to connect T and v somehow. PTR Technical difficulties • Let’s be creative: Suppose that the tense features on v (the value of the [uInfl:] feature) “refer back” to the tense features on T. • Agree can see relatively far (so T can value the [uInfl:] feature of v, even if it has to look past negation). • But “referring back” is more limited, basically only available to features that are sisters. Negation will get in the way for this. • So if you try to pronounce tense on v but T is too far away, the back-reference fails, and v is pronounced as a bare verb. But the tense features have to be pronounced somewhere, so they’re pronounced on T (as do). • Adger’s proposal: • Pronouncing Tense Rule (PTR) In a chain (T[tense], v[uInfl:tense]), pronounce the tense features on v only if v is the head of T’s sister. • NegP, if there, will be the sister of T (HoP), but Neg has no [uInfl:] feature. do will be inserted. • Adverbs adjoin to vP, resulting in a vP. v has a [uInfl:] valued by T and adverbs don’t get in the way of vP being the sister of T. Tense is pronounced on the verb (v). • If vP is gone altogether, do is inserted. • Pat did not call Chris • So, here, T and v form a chain because [tense:past] valued [uInfl:past]. But v is not the head of T’s sister. Pat did not call Chris Do-support comes to the rescue. What this means is just that T is pronounced as do with the tense specifications on T. According to PTR, we don’t pronounce them on v. The tree doesn’t change. TP TP NP Pat T NP Pat ! T [tense:past] T! NegP T [tense:past] did Neg vP not < Pat > v! v v NP Chris T vP AdvP vP never < Pat > v! v VP V v call [uInfl:past] Now that we’ve gotten some idea of how the system works, let’s back up a bit to remind ourselves a bit about why we’re doing what we’re doing. • People have (unconscious) knowledge of the grammar of their native language (at least). They can judge whether sentences are good examples of the language or not. • Two questions: Phrase Structure Rules S # NP (Aux) VP NP # (Det) (Adj+) N Aux # (Tns) (Modal) (Perf) (Prog) N # Pat, lunch, … Tns # Past, Present Perf # have -en • • What is it that we know? How is it that we came to know what we know? NP Chris History • • ! T [tense:past] NP Chris The Big Picture If there is an adverb like never, PTR still allows tense to be pronounced on v (so T doesn’t have any pronunciation of its own at all). TP VP V v call [uInfl:past] Pat never called Chris NP Pat Neg vP not < Pat > v! VP V v call [uInfl:past] • NegP VP # V (NP) (PP) PP # P NP P # at, in, to, … Modal # can, should, … Prog # be -ing In trying to model what we know (since it isn’t conscious knowledge) some of the first attempts looked like the phrase structure rules above (Chomsky 1957). • An S can be rewritten as an NP, optionally an Aux, and a VP. An NP can be rewritten as, optionally a determiner, optionally one or more adjectives, and a noun. … • What we know is that an S has an NP, a VP, and sometimes an Aux between them, and that NPs can have a determiner, some number of adjectives, and a noun. Phrase Structure Rules S # NP (Aux) VP NP # (Det) (Adj+) N Aux # (Tns) (Modal) (Perf) (Prog) N # Pat, lunch, … Tns # Past, Present Perf # have -en VP # V (NP) (PP) PP # P NP P # at, in, to, … Modal # can, should, … Prog # be -ing S NP Aux VP N Modal V NP Pat might eat N lunch History In this way, many sentences can be derived, starting from S. ! The tree-style structure is a way to record the history of the derivation from S to the words in the sentence. ! We model our knowledge of English as a machine that (ideally, when it’s finished) will generate all of the sentences of English and no others. ! Affix Hopping Phrase Structure Rules S # NP (Aux) VP NP # (Det) (Adj+) N Aux # (Tns) (Modal) (Perf) (Prog) N # Pat, lunch, … Tns # Past, Present Perf # have -en VP # V (NP) (PP) PP # P NP P # at, in, to, … Modal # can, should, … Prog # be -ing ! S Aux NP N Tns Perf VP Prog V ! NP Past If you build a sentence this way, things aren’t in the right order, but there’s a simple transformation that can be done to the structure to get it right. Empirically, tense, perfect have, and progressive be each control the form of the verbal element to their right. Aux NP N Tns Perf • • Through the 60s there were good people working hard, figuring out what kinds of phrase structure rules and transformations are needed for a comprehensive description on English. As things developed, two things became clear: • A lot of the PSRs look pretty similar. • There’s no way a kid acquiring language can be learning these rules. GB Around 1981, the view shifted from thinking of the system as constructing all and only structures with PSRs and transformations to a view in which structures and transformations could apply freely, but the grammatical structures were those that satisfied constraints on (various stages of) the representation. ! ! Chomsky (1970) proposed that there actually is only a limited set of phrase structure rule types. ! For any categories X, Y, Z, W, there are only rules like: XP " YP X# X# " X# WP X# " X ZP Pat • First, a “deep structure” (DS) tree is built, however you like but Things more or less like Affix Hopping, or moving V to v, or moving the subject to SpecTP. ! Further constraints are verified here: Is there a subject in SpecTP? Etc. Finally, the result is assigned a pronunciation (PF), and, possibly after some further adjustments, an interpretation (LF). Why is this better? Most of the construction-specific rules were made to follow from more general principles interacting. AND again, it caused us to look for predictions, which were better met. NP N have+edbe+eneat+inglunch Why is this better? The types of rules are much more constrained. AND it also makes predictions about structure and constituency that turn out to be more accurate. If drawn out as a tree, you may recognize the kind of structures this proposal entails. These are structures based on the “X-bar schema”. • XP " YP X# X# " X# WP X# " X ZP • YP being the “specifier”, WP being an “adjunct”, ZP being the “complement”. Adjuncts were considered to have a slightly different configuration then. • The most recent change in viewpoint was to the system we’re working with now (arising from the Minimalist Program for Linguistic Theory). • The constraints that applied to the structures in GB were getting to be rather esoteric and numerous, to the extent that it seemed we were missing generalizations. ! ! Prog V XP YP X" WP X" X ZP Which brings us to 1993 Selectional restrictions must be satisfied $-roles must be assigned ! Etc. ! Then, adjustments are made to get the “surface structure” (SS) ! VP Affix Hopping SD: afx verb SC: verb+afx The affixes all “hop to the right” and attach to the following word. An ancestor to the kinds of movement rules and of course the Agree operation we’ve been talking about. X-bar theory ! ! ! Past History continues • ! S N Pat -ed have -enbe -ing eat lunch Affix Hopping Phrase Structure Rules S # NP (Aux) VP NP # (Det) (Adj+) N Aux # (Tns) (Modal) (Perf) (Prog) N # Pat, lunch, … Tns # Past, Present Perf # have -en VP # V (NP) (PP) PP # P NP P # at, in, to, … Modal # can, should, … Prog # be -ing ! The goal of MPLT was to “start over” in a sense, to try to make the constraints follow from some more natural assumptions that we would need to make anyway. ! This new view has the computational system working at a very basic level, forcing structures to obey the constraints of GB by enforcing them locally as we assemble the structure from the bottom up. Why is this better? It’s a further reduction to even more general principles. The idea is that you need a few things to construct a language-like system—and there’s nothing else. Features and technology • • The use of features to drive the system (uninterpretable features force Merge, because if they are not checked, the resulting structure will be itself uninterpretable) is a way to encode the notion that lexical items need other lexical items. What the system is designed to do is assemble grammatical structures where possible, given a set of lexical items to start with. ! ! Features and the moon • A comment about the technology here: The operations of Merge, Adjoin, Agree, and feature checking, the idea that features can be interpretable or not (or, strong or weak) are all formalizations of an underlying system, used so that we can describe the system precisely enough to understand its predictions about our language knowledge. f =G • ! The “Minimalist Program” • • The analogy with the gravitational force equation isn’t quite accurate, given the underlying philosophy of the MP. ! Suppose that we have a cognitive system for language, which has to interact with at least two other cognitive systems, the conceptual-intensional and the articulatory-perceptual. ! Whatever it produces needs to be interpretable (in the vernacular of) each of these cognitive systems for the representation to be of any use. ! Suppose that the properties of these external systems are your boundary conditions, your specifications. The Minimalist Program in fact is trying to do this: ! The hypothesis of the MPLT is that the computational system underlying language is an optimal solution to those design specifications. So everything is thought of in terms of the creation of interpretable representations. We can think of this initially as the same kind of model as this: m1m2 r2 The Earth and the Moon don’t compute this. But if we write it this way, we can predict where the Moon will be. ! Saying lexical items have uninterpretable features that need to be checked, and hypothesizing mechanisms (matching, valuing) by which they might be checked is similarly a way to formalize the behavior of the computational system underlying language in a way that allows us deeper understanding of the system and what it predicts about language.