which report appears to be simultaneously the object of both file and read, a problem for a simple wh-movement account. The parse obtained by PAPPI has the reading:
for which x, x a report, you filed x without you reading x
[We can deduce this by reading the indices determined by
PAPPI off the tree shown above.
which report has index
[1].
you has index [2].
The objects of both file
and reading are empty NPs with index [1].
The subject of reading, PRO, has index [2].]
The history of movement can also be read directly off the tree in this case.
The empty object NP following reading is shown as NP-A-P[1] (a variable -A-P, but not a trace). Compare this gap with the coindexed empty object following file, which is shown as NPt-A-P[1]. This is also a variable; however, crucially the t indicates it's a trace formed through movement (its antecedent being the fronted wh-NP which report).
(An alternative formulation would be to have without select for a CP with an empty operator heading the chain ending at the object position of read. An exercise left for the reader.)
If you run the sentence using the default parser j5parser.pl,
you will see it processes a total of 47 different candidate parses
through a gauntlet of constraints and only one manages to emerge
unscathed (the one shown above in which which report
originates from the object position of file). The implemented
constraints engage in a delicate conspiracy to eliminate all other
movement chains possibilities.
[The admitted parse is tree number 37. You can see this by clicking on Trace Theory and checking the "Print After" option. All trees emitted by Trace Theory will subsequently be enumerated and printed in the main window in numbered order. Running the sentence again, you can see the parse obtained is output after "Exit Trace Theory: (37)" and before "Exit Trace Theory: (38)".] |
![]() |
You may wonder about whether the parser considered the possibility that:
PAPPI's user interface allows us to drill down and see what happened
to each of these possibilities.
Let's take the 2nd case first.
How is this derivation ruled out by PAPPI?
[The history of movement can be read off the tree by
inspecting the chain feature as follows:
The empty object of reading has feature
chain(NPt[1],last,[[vp,i1,i2,pp].[vp,vp]]).
In turn, the empty object of file has feature
chain(NP[1],medial,[[vp,vp,vp,i1,i2,c1],[]]).
NP[1] has feature chain([],head,[]) signalling that it is the head of
the chain.]
This means it is the last element of a movement chain: its immediate
antecedent is another trace NPt[1].
The antecedent can be reached by passing through the nodes on the path
[vp,i1,i2,pp] up until the matrix VP node; then down through [vp,vp]
to reach the empty NP that is the object of file.
This means it is an intermediate trace with an antecedent reached by
passing through the nodes [vp,vp,vp,i1,i2,c1] up until we reach the
top of the tree where the head of the chain NP[1] which
report appears.
To see what happens to tree number 8, select Trace Theory and check
"Restrict Structures", type in 8 and hit Apply. This restricts Trace
Theory to block all output except for tree number 8.
If we run the sentence again, it may come as a surprise to see that tree 8 is blocked at parser operation "Case Condition on ECs", which states that NP-traces must not receive Case. (This violation is reported at the bottom of the parse tree shown earlier.) Looking at the case feature for the empty object of reading, we can see that it has accusative Case (acc) assigned by the verb. Since the object in question is a trace participating in A-movement, it is blocked. |
![]() |
Note: the exact tree reported above was produced by enabling "Print
Before" for "Case Condition on ECs". This additional step is necessary
in order to see the case(acc) feature since the tree output by Trace
Theory is just a snapshot of the tree before Case has been assigned.
[We can also see by the numbers reported next to the parser operation that the computation stops at "Case Condition on ECs". There is exactly one tree going in (tree number 8) and zero trees coming out.] |
![]() |
Actually, it turns out tree 8 is also ruled out by the "Theta
Criterion", which states that argument chains must receive exactly one
theta role. To verify this, we can deactivate "Case Condition on ECs"
by clicking on the filter and unchecking "Active". Then we can simply
run the sentence again. The result is shown below.
Inspecting the theta feature for the which report movement chain, we can see that two out of the three elements in the chain have been assigned theta roles, and therefore it is excluded. [To show the incoming tree with theta roles already assigned, "Print Before" has been enabled for the "Theta Criterion" parser operation.] |
![]() |
How is this derivation ruled out by PAPPI?
To do this, we have to load in a different parser. All of the parsers
supplied in the PAPPI distribution compute the same final answers. In
other words, their input/output behavior is invariant with respect to
admissible parses. However, the parsers have important differences
with respect to internal control structure, affecting their
computational performance in obtaining the same parses.
The parser we've been using so far, namely j5parser.pl, integrates Subjacency into Trace Theory, the parser operation responsible for chain formation, for computational efficiency. Despite the fact the parser considers a total of 47 trees, none of them contain cases of movement involving long chain paths containing two or more bounding nodes. This is the constraint imposed by Subjacency. (In English, the nodes NP and I2 count as bounding nodes.) Let us proceed by loading i5parser.pl, which is identical to the default j5parser.pl, except that Subjacency is an independent operation. [To load a new parser, use the Parsers menu. A dialog box will pop up. Command-click on the drop-down menu labeled "Go To" and select PAPPI_HOME. Then select i5parser.pl.] |
![]() |
Freed from the bounding node restriction imposed by Subjacency, Trace
Theory produces a total of 73 candidate trees for our parasitic gap
sentence.
It turns out that tree number 17 (shown below) is the one we're interested in. It's the only one where the empty object of reading, namely NPt[1], is coindexed with NP[1] which report, and the object of file is an empty NP that's not a trace. By restricting Trace Theory to output tree 17 only, we can see it's blocked by Subjacency. |
![]() |
We can go further and determine whether Subjacency is solely
responsible for keeping this derivation out in the implemented
theory.
To do this, we simply switch Subjacency off and re-run the
sentence. The parse tree produced below indicates that no other
principle in the system blocks the parse from going through with the
correct reading, repeated here:
for which x, x a report, you filed x without you reading x
In this case, the empty object of file, namely NP-A-P[1], is a non-trace and is licensed as a variable by being A-bar-bound by the c-commanding wh-NP which report.