Syntax I - Agree, Head Movement, and the Strength of Features

More about Pat and lunch • Returning now to the question of how the Syntax I verb comes to look the way it does. Agree, head movement, and the strength of features 1) Pat ate lunch. 2) Pat eats lunch. 3) Pat has eaten lunch. 4) Pat was eating lunch. 5) Pat might have been eating lunch. might have been eating Affix hopping TP • Each auxiliary seems to control the form of the form that follows it. We can include T in this generalization as well. Pat (T) eat s Pat (T) have eat s en Pat (T) be is eat s ing Pat (T) have be eat s en ing might have been eating TP The way we’ll model this is by supposing that certain forms take endings. Inflectional endings. Like en, ing, s, etc. Specifically, suppose that the inflectional ending is represented by an inflectional feature, like [Infl: Perf], or [Infl: Prog], or [Infl: Past]. NP Pat T ! T+M MP might < might > PerfP Perf have ProgP Prog vP be < Pat > v! v +V VP eat < eat > NP lunch Now, look at how these appear in the tree. NP Pat T! T+M MP might < might > PerfP Basically, certain things (T, M, Perf, Prog) assign a verbal form to the next thing (M, Perf, Prog, v) down. Perf have ProgP Prog vP be < Pat > v! This is a little bit like the assignment of reference through binding. v +V VP eat < eat > NP lunch might have been eating The form comes out of the lexicon without a specific ending, though— what ending it gets is determined after it is Merged into the tree, by the next thing up. That is: whether eat comes out as eats or eaten or eating depends on whether the next thing Merged is T, Perf, or Prog. TP NP Pat T! T+M MP might < might > PerfP Perf have ProgP Prog vP be < Pat > v! v +V VP eat < eat > NP lunch might have been eating eat_? TP So, at the point where, say, Prog is first Merged into the structure, its Inflectional feature is unvalued. NP Pat T! T+M MP might < might > PerfP It will be valued by the next thing Merged. Perf have ProgP Prog vP be < Pat > v! We will also assume that an unvalued inflectional feature is uninterpretable. It must be fixed. vP So, v has a [uInfl: ] feature. v [v, uN, uInfl: ] V eat v +V VP eat < eat > NP lunch [uInfl: ] past + eat_? If T is Merged next, it will determine the inflection that will go on the verb. If T is [past], then the verb will become ate. v! v +V eat [v, uInfl:, uN, . . . ] So, T values the [uInfl: ] feature of v. As [past], or [pres]. Let’s suppose that TP everything that has an inflectional ending T vP of this sort has a [T, past, . . . ] [uInfl:] feature, then. NP Pat That is: Prog, Pres, v +V M, and v all have a eat [uInfl:] feature. vP NP Pat VP < eat > NP lunch PerfP VP < eat > NP lunch Agree: T values the [uInfl:] feature of Perf. TP T [T, past] PerfP Perf have [Perf, uInfl:past ] vP v! v +V eat [v, uInfl:perf, uN, . . . ] v! had + eaten Agree: Perf values the [uInfl:] feature of v. NP Pat Pronunciation: T is not pronounced, v+V is pronounced as ate (past form of eat) [v, uInfl:past, uN, . . . ] And T, M, Prog, and Pres can value that feature. have_? + eaten Perf have [Perf, uInfl: ] NP lunch ate Now, Infl is valued (and is no longer uninterpretable). T [T, past, . . . ] VP VP < eat > NP lunch vP NP Pat v! v +V eat [v, uInfl:perf, uN, . . . ] VP < eat > NP lunch Agree & unvalued features • • The idea is that a lexical item might have an unvalued feature, which is uninterpretable as it stands and needs to be given a value in order to be interpretable. What has [uInfl:], what can value [uInfl:] Agree In the configuration X[F: val] … Y[uF: ] F checks and values uF, resulting in X[F: val] … Y[uF: val]. • • This gives us two kinds of uninterpretable features (unvalued and regular-old uninterpretable features), and two ways to check them (valuing for unvalued features, checking under sisterhood for the other kind). • Unvalued [uF: ]. Regular-old [uF]. • • Combine any two of them (Merge) to make a new item. Lexical items can have uninterpretable features. Merge can check these features. All of the uninterpretable features must be checked by the end of the derivation. Attach one to another (Adjoin). • [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) • There are two basic kinds of movement. We’ve seen examples of each. • One is head-movement, where a head moves up to join with another head. • Adjoin does not check features. Move stuff around. • v, M, Perf, Prog Move Take some lexical items (a “numeration” or “lexical array”) • • 1) Pat [past] ha-d be-en eat-ing lunch. The basic operations • • Things of these categories have [uInfl: ] features: • The other is XP-movement, where a maximal projection (an XP) moves up to a specifier of a higher phrase. • What can you do? What can’t you do? Does it check features? Why do you do it? What’s really happening? Solving a problem via movement Examples: V moves to v, {Perf/Prog/M} moves to T Example: The subject moving to SpecTP. Two existing means of checking features • We will assume that, like with Merge, Move occurs to “solve a problem.” And the main problem our system has is unchecked uninterpretable features. So, Move must check features. • P has a [uN] feature. Merge it with an N(P), and the [uN] feature of P is checked. • We have two ways to check features so far. One of them is under sisterhood (Merge). The other is “at a distance” (Agree). • • T has a [tense:past] feature. • What kind of problem could Move solve? Well, for one thing, it must not be able to solve the problem in place, without moving. Seems to need “closeness.” Strictly speaking [tense:past] doesn’t look like it’s a valued [Infl] feature. We need to stipulate in addition a list of things that can value [Infl] features. c-selection If X[F] and Y[uF] are sisters, the uF feature of Y is checked: Y[uF]. inflection If X[F] c-commands Y[uF:] the uF feature of Y is valued and checked: Y[uF:val]. Generalizing Agree • • Agree requires: • An uninterpretable or unvalued feature • • A matching feature • Line of sight (c-command) And results in: • • Valuing of unvalued features. • Checking of the uninterpretable features. Our first version of checking (sisterhood) is a special case of this more general conception of Agree. Except that we do want the [uN] feature of P to be checked by directly Merging P and an NP—not “at a distance” like agreement. Generalizing Agree • • • • Matching: • • Identical features match. [N] matches [uN]. • What if there are two options? We’ll see later that only the closest one participates in Agree. Some features match several things. [uInfl:] can match values of the [tense] feature ([tense:pres], [tense:past]), as well as the category features [Perf], [Prog], [M]. Valuing/Checking: • • • An unvalued feature is always uninterpretable. Valuing a feature will check it. A privative feature is simply checked when it matches. In order to check the [uN] feature of P only through Merge (sisterhood), we will define a special kind of uninterpretable feature: the strong feature. • A strong feature can only be checked when the matching feature is on an element that shares the same mother node. • We will write strong features with a *: • • P [P, uN*] C-selection features are strong. Other properties of Agree (mainly relevant later) Strong features Agree first. • Where a single head has more than one feature that must Agree, the strong ones go first. • Agree always goes with the closest option it can find in order to check an uninterpretable feature. • If Agree locates a matching feature on X for one uninterpretable feature, and X has a different feature that also matches, both features will be checked. • Examples are coming up later, but for cross-referencing: these properties are important for subject agreement. The system is lazy. Comments on Agree X has feature [F1], Y has feature [F2] X c-commands Y or Y c-commands X [F1] and/or [F2] are/is uninterpretable. • X and Y are close enough, meaning: • • There is no closer matching feature between X and Y. If [F1] or [F2] is strong, X and Y share the same mother node Any unvalued feature ([F1] or [F2]) is valued. The uninterpretable feature(s) is/are checked. This statement of Agree allows for several different configurations: • [F1] matches [F2] Then: • • • Agree If: • • • • • Strong features • [uF]…[F]! ! c-selection! ! ! ! [F]…[uF]!! Inflection!! ! ! [uF]…[uF] Case Strong features must be checked very locally. • • Merge can provide this locality. Move can also provide this locality. • Strong features are what motivates movement. v! V+v=? v V eat v! V+v=? VP v [uV*, . . . ] 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 eat v [uV*, . . . ] v V eat NP What happens to the VP from which the V moved? • 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. 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. v! V+v=? VP v [uV*, . . . ] • • v! V+v=? VP NP Moral: “Head-movement” can be viewed as Copy+Adjoin. v V eat • • We always move V to v. v [uV*, . . . ] VP NP Reason: v always has a [uV*] feature. • 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. 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…) • • 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. 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). v! V+v=? v V eat v [uV*, . . . ] A note on node labeling 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. 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 strong. T has [uN*] (“EPP”) • • 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. Only auxiliaries move to T 1) I do not eat green eggs and ham. 2) I have not eaten green eggs and ham. 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. Auxiliaries moving to T 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. Auxiliaries moving to T • Auxiliaries have a [uInfl:] feature, valued by the next thing up. the feature [Aux] (“the property of being auxiliaries”). • The topmost auxiliary has its [uInfl:] feature valued by T. Auxiliaries move. Movement is driven by a strong feature. But what strong feature? • The topmost auxiliary is the only auxiliary that moves to T. auxiliaries and main verbs behave differently, • Since they must be differentiated. Suppose auxiliaries have • 3) I have not been eating green eggs and ham. • [uAux*] on T? • No. That does not work. • [uT*] on Aux? • No. That would not be promising. • French vs. English In English, adverbs cannot come between the verb and the object. • An auxiliary whose [uInfl:] feature is valued by T will move to T. • Movement is driven by strong features. • 1) *Pat eats often apples. 2) Pat often eats apples. • In French it’s the other way around. 3) Jean mange souvent des pommes. Jean eats often of.the apples ‘Jean often eats apples.’ 4) *Jean souvent mange des pommes. • If we suppose that the basic structures are the same, why might that be? • • 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. T[tense:pres] … be[Aux, uInfl:] T[tense:pres] … be[Aux, uInfl:pres*] T[tense:pres]+be[Aux, uInfl:pres*] … French vs. English Similarly, while only auxiliaries in English show up before negation (not)… • • John does not love Mary. John has not eaten apples. …all verbs seem to show up before negation (pas) in French: • 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.’ V raises 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. • • • What it looks like is that both V and auxiliaries raise to T in French. • T values [uInfl:] on Aux T values [uInfl:] on v English Strong Weak French Strong Strong Typology of verb/aux raising 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. Swedish T values [uInfl:] on Aux T values [uInfl:] on v English Strong Weak French Strong Strong Swedish Weak Weak Unattested Weak Strong • 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.