CAS LX 522Syntax IWeek 5b.Agree, head movement, and the strength of features(5.4)More about Pat and lunch•Returning now to the question of how the verb comes to look the way it does.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.sAffix hopping•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 Pat (T) have eatensPat (T) be eatingsis Pat (T) have be eatens ingmight have been eatingNow, look at how these appear in the tree.Basically, certain things (T, M, Perf, Prog) assign a verbal form to the next thing (M, Perf, Prog, v) down.This is a little bit like the assignment of reference through binding.TPNPPatT!T+MmightMP< might > PerfPPerfhaveProgPProgbevP< Pat > v!v+VeatVP< eat > NPlunchmight have been eatingThe 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].TPNPPatT!T+MmightMP< might > PerfPPerfhaveProgPProgbevP< Pat > v!v+VeatVP< eat > NPlunchmight have been eatingThe 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.TPNPPatT!T+MmightMP< might > PerfPPerfhaveProgPProgbevP< Pat > v!v+VeatVP< eat > NPlunchmight have been eatingSo, at the point where, say, Prog is first Merged into the structure, its Inflectional feature is unvalued.It will be valued by the next thing Merged.We will also assume that an unvalued inflectional feature is uninterpretable. It must be fixed.[uInfl: ]TPNPPatT!T+MmightMP< might > PerfPPerfhaveProgPProgbevP< Pat > v!v+VeatVP< eat > NPluncheat_?So, v has a [uInfl: ] feature.v Pv[v, uN, uInfl: ]VPVeatNPlunchpast + 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.So, T values the [uInfl: ] feature of v. As [past], or [pres].T[T, past, . . . ]v PNPPatv!v +Veat[v, uInfl:,uN, . . . ]VP< eat > NPlunchateNow, Infl is valued (and is no longer uninterpretable).Let’s suppose that everything that has an inflectional ending of this sort has a [uInfl:] feature, then.That is: Prog, Pres, M, and v all have a [uInfl:] feature.And T, M, Prog, and Pres can value that feature.TPT[T, past, . . . ]v PNPPatv!v +Veat[v,uInfl:past, uN, . . . ]VP< eat > NPlunchPronunciation:T is not pronounced,v+V is pronounced as ate (past form of eat)have_? + eatenAgree:Perf values the [uInfl:] feature of v.PerfPPerfhave[Perf, u Infl: ]v PNPPatv!v +Veat[v,uInfl:perf, u N, . . . ]VP< eat > NPlunchhad + eatenAgree: T values the [uInfl:] feature of Perf.TPT[T, past]PerfPPerfhave[Perf,uInfl:past ]v PNPPatv!v +Veat[v,uInfl:perf, u N, . . . ]VP< eat > NPlunchAgree & unvalued features•The idea is that a lexical itemmight have an unvalued feature,which is uninterpretable as itstands and needs to be givena value in order to beinterpretable.•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].AgreeIn the configuration X[F: val] … Y[uF: ]F checks and values uF, resulting inX[F: val] … Y[uF: val].What has [uInfl:], what can value [uInfl:]•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.The basic operations•Take some lexical items (a “numeration” or “lexical array”)•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).•Adjoin does not check features.•Move stuff around.•What can you do? What can’t you do? Does it check features? Why do you do it? What’s really happening?Move•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.•Examples: V moves to v, {Perf/Prog/M} moves to T•The other is XP-movement, where a maximal projection (an XP) moves up to a specifier of a higher phrase.•Example: The subject moving to SpecTP.Solving a problem via movement•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.•We have two ways to check features so far. One of them is under sisterhood (Merge). The other is “at a distance” (Agree).•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.”Two existing means of checking features•P has a [uN] feature. Merge it with an N(P), and the [uN] feature of P is checked.•T has a [tense:past] feature.•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-selectionIf X[F] and Y[uF] are sisters, the uF feature of Y is checked:Y[uF].inflectionIf 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.Strong features•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
View Full Document
![Nom from finite T no case from nonfinite T (T [inf], M to)](https://media.gradebuddy.com/documents/386389/7a3e15e0-7507-4825-a32d-f3e6fb67d2eb.png)
Unlocking...