Domain of MergeIn an attempt to keep things intuitive and focused on examples, I reduced the definition of Merge and Move to, literally, your old buddies Merge and Move. Succinct, but not particularly insightful (also, it's kind of presumptuous on my part to assume that you're on good footing with Merge and Move). For Move it seems to have worked just fine, but there was some confusion about when, where and how Merge is allowed to apply. So let's be a wee bit more precise this time, ideally using some kind of fancy-schmancy mathematical notation.
First, we write t[x] to denote a tree t whose head has x as its first unchecked feature, e.g. t[D+] for likes::D+ D+ V- or the beautiful fellow below:
- Merge takes two trees as arguments.
- The heads of these two trees have matching features of opposite polarity.
- Merge combines these two trees into one big tree.
- The root node of the new tree receives some suitably defined label that picks out the head of t as the head of the whole new tree.
- If the selecting head (which carries the positive polarity feature) has not selected anything else yet, it is linearized to the left of the selectee. Otherwise it appears to the right. This expresses the ordering difference between specifiers and complements.
Consider this example by Avery, where likes::D+ D+ V- is merged with Mary::D- top-.
Can we then continue to merge this tree with, say, Fred::top+? The answer is no, because the head of the tree isn't Mary but likes, whose first unchecked feature is D+ rather than top-.
Are All Features the Same?Another thing I wasn't crystal clear about is the nature of features. You might have noticed in my examples that all the features checked by Merge have uppercase names (D,V,T,C), while those triggering Move are lowercase (top, nom). So is this just a happy accident, or is there actually a difference between Merge and Move features? Well, in the summary I explicitly claim that each feature is either a Merge feature or a Move feature. But the truth of the matter is, it doesn't matter. At all.
The standard definition of Minimalist grammars indeed posits a bifurcation between Merge and Move features. So every feature has two binary parameters: i) the type of operation it can trigger, and ii) its polarity. The standard feature notation in the literature succinctly represents these parameter values:
These features also have specific names: f is a category feature, =f a selector feature, +f a licensor feature, and -f a licensee feature. While the notation is fairly simple, it is yet another hurdle for MG newbies, so I decided to go with the simpler + and - notation instead.
There's also a theoretical reason for doing away with the split between Merge and Move features: no such thing is entertained in the syntactic literature. The EPP, for example, is commonly analyzed as a D feature on the T-head that needs to be checked.2 If some DP has already moved to Spec,TP to get its case feature checked, then it can also check the D feature to avoid troubles with the EPP police. If T has no case feature that could attract a DP, then an expletive is merged instead. Therefore a single feature can be checked by either Merge or Move.
Abandoning the Merge/Move dichotomy does not affect the expressive power of MGs, and here's why. It should be clear that MGs without this distinction are at most as powerful as standard MGs, since the latter have more fine-grained control over the structure-building process. But they aren't weaker either. Suppose that you have a lexical item with the feature specification f+ g+ h+ i- j- k-.3
- The first feature, f+, can only be checked by Merge because Merge is the only way to enter the derivation and you cannot attract a mover until you have entered the derivation.
- The features g+ and h+ we're less sure about; maybe something will be merged, maybe there is a licit mover somewhere else in the tree that can be attracted.
- However, i- is definitely a Merge feature. If it were a Move feature, it could only be checked by moving to some higher position. But until the lexical item has been selected, there is no such higher position that could be targeted. Being selected involves the checking of a negative feature, and i- is the first such feature. Hence it must be a Merge feature.
- Since i- is a negative Merge feature, it will not be the head of the tree created by Merge. Consequently, all features following it can only be checked by Move. This means that both j- and k- must be Move features.
What Lies AheadHopefully you've all got a decent grasp of the basic MG machinery now; or at the very least, things aren't less clear now. As the semester is winding up again, I've got a busy week ahead of me, but I'll try to crank out at least one post about a topic that is particularly dear to my heart: derivation trees.
Many recent findings suggest that syntax isn't about phrase structure trees but rather derivation trees. Derivation trees satisfy a number of desirable properties such as Chomsky's extension condition, they address issues like the labeling algorithm and the symmetry of Merge, they are linearly unordered, offer an intuitive definition of c-command, provide a novel perspective on the T-model, establish a close connection between Minimalism and Aspects-style Transformational grammar, and are easier to parse. Oh, and whatever phrase structure trees do, derivation trees can do too. What's not to like?
- Countercyclic Merge aka Late Merge can be added to MGs, of course, but how this is done and how it affects the formalism is a fairly technical topic.↩
- Btw, what is the current thinking about the EPP? This used to be a fairly big topic in the literature, but I haven't heard much about it since Epstein & Seely (2006) Derivations in Minimalism.↩
- Here's an easy exercise for the theoretically inclined among you: explain why a lexical item cannot occur in a well-formed tree unless all its positive polarity features precede all its negative polarity features.↩