Just a couple more notes about the previous homework. Some of you might have the word “linearization” written on your homework. If you see that, it means that one or more of your trees were drawn in such a way that the words wouldn’t be in the right order if you pronounce the structure as it was drawn. Remember, whenever a node has two daughter nodes, you draw the one that is pronounced first to the left of the one that is pronounced second.
A trickier point, that was brought to my attention earlier today, concerns the interaction of case and the “floating quantifier” all. Let me say at the outset here, there is—to my knowledge—no fully satisfying account of floating quantifiers. Some things you get for free, some things you have to stipulate. (Also, I’ll call all a D, rather than an N, since that’s what we’re considering it to be now).
The analysis that the book/handouts promotes is one in which all is a D that is unusual in that it takes a DP complement. So, it has the features [D] (because it is a D) and [uD*] (because it takes a DP complement). Here’s the sticky point: We also believe now that each and every D has a [ucase: ] feature that must be valued and checked. So, since they all is a DP with a DP inside, two different things need case checked. At this point, there are two routes we could take. One is to assume that the [ucase:nom] feature of T can check them both (given that neither of they all and all is closer to T than the other). The other is to assume that all (and both) is special not only in that it is a D with a [uD*] feature, but that it is a D without a [ucase: ] feature. It’s a tough call which is better. Out in the wider world of syntax, it is standardly assumed that there is a one-to-one relationship between case checkers and DPs (that is, the case checkers—T, v, P, etc.—each only ever value and check case on a single DP), which might sway us toward Route 2. At this point, we don’t derive this directly, although it will almost always turn out be one-to-one anyway. On the other hand, it is not clear that any harm will come to us if we take Route 1. In our system, already-checked features can check still-to-be-checked features (see recent blog note about this), and Route 1 allows us to keep the generalization that all Ds need case (that is, have a [ucase: ] feature) without exceptions.
I think I’ll leave it without a definitive resolution, but with maybe a hint of a preference for Route 1 in the context of this class. Until/unless there is a stated policy about which is the approach to use in this class, either one is fine. If you can at least see the issues involved here, that’s probably the important thing.