Curbing multiple adjunct extraction (with append lists)

I need my extracted-adjunct phrase to allow SLASH-ed head daughters because I want multiple questions of the Who went where? type which in Russian seem to allow various orders, with Who where went? being perfectly acceptable (and not echo).

At the same time, actual multiple adjunct extraction seems really iffy: ??Where when did Kim go?, I really don’t think that’s a normal sentence at this point.

Right now I have an unrestricted adjunct extraction which, first of all, will license multiple adjunct extraction and second, you have to wait for the parser to run out of edges before it parses any sentence. That’s of course not desirable.

I remember @ebender (perhaps other people, too) had some ideas at the last DELPH-IN, something to have to do with a typed list.

Are we talking here about an append list of length 1 (something I don’t right now have in my grammar)? And that append list of length 1 would be… whose SLASH value?

I think the way to go about this is with a typed list, but not one whose length is constrained. Basically, you need to create or find a feature which is characteristic of adjunct gaps, and then create a parameterized list (like you did for canonical list recently) such that the SLASH of the daughter of the adjunct extraction rule is constrained to be a list (of unknown length, could be zero) of non-adjunct gaps.

Is it still going to help me demonstrate that I need append-lists vs. diff-lists? The way I “understand” it currently is, diff-lists were forcing us to posit a global 0-1-dlist constraint on nonlocal features. With append-lists, we can avoid it and only posit a restricted length constraint on, say, one lexical type. Does it sound like this is an entirely different issue?

There are quite a few separate topics here.

1. Diff-list vs. Append-list. Using append-lists does two things. It makes it easier to write code (this was my original motivation), and it lets you close a list and later append to it. Closing a list is necessary for checking the length of the list, including checking if it’s non-empty. The second point could be linguistically relevant, but I have to stress that it’s a fairly technical restriction. Closing a diff-list is possible, as long as you don’t need to append to it again.

2. List vs. 0-1-list. Diff-lists don’t force you to use 0-1-dlists. Multiple fronting isn’t possible in English, and my understanding is that @Dan decided to sacrifice rare constructions like the sonata-violin, in favour of a simpler and more efficient grammar.

3. Typed lists. These are possible with both diff-lists and append-lists. (Although one difference I can see is that a diff-list will continue to enforce the typing as new elements are appended, because it’s the same list. For an append-list, a new list is created with each append, and so the “default” behaviour would be for the new list to be a normal list. It would be straightforward to enforce the typing again for the new list, e.g. if it’s enforced on every SLASH list.)

4. Restricting adjunct extraction. From the example sentences given so far, it’s not obvious that this says anything about append-lists. I’m not quite clear on what the proposals are, though.

Hi @guyemerson, do you have any paper with a deeper presentation of all these aspects and differences between the list data type implementations in TDL language?

@arademaker To my knowledge, for now the best resources are these two:

  1. Guy’s DELPH-IN slides and sample grammar (if you want nonlocal features treatment, ask me for my Russian grammar).
  2. Gabriel Aguila-Multner and Berthold Crysmann. 2018. Feature resolution by lists: The case of French coordination.
1 Like

Right; and I thought the main takeaway from this discussion was that this is a win on the append list side? That we might want to append to it again? To specify that e.g. only one argument can be extracted from give but an adjunct can still also be extracted, something like that? Do I have it right?

Now, for dealing with recursive adjunct extraction, we want to try a new list type, something that’s a list of non-adjuncts, essentially. This list we put as a constraint on the extracted-adjunct daughter. But to that list we then want to append the adjunct (@ebender, do I have this right?) @guyemerson, does that sound possible to do with append-list (and not possible with diff-list)? Would it allow adjunct extraction to occur both lower and higher in the tree, wrt argument extraction?

@arademaker I don’t have a paper on this. Append-lists are still experimental. On diff-lists, see:

@olzama I agree that it’s a win, but it’s a win with clearly defined limits. What you’ve just described sounds possible with append-lists and not with diff-lists. I don’t know what you mean by extraction lower and higher in the tree – where exactly?

1 Like

Good, then it can be part of our abstract :).

What I meant by higher vs. lower is actually: will I be able to extract an adjunct both before and after I extract an argument? Not to produce two trees for the same sentence though (the ambiguity problem is separate here) but to license two different sentences in a language with a flexible word order. Who where goes and Where who goes, in Russian.

I think what Olga and I were discussing at the top of this thread about (effectively: list(non-adjunct-gap)) is an example of exactly this: We want to say that the daughter’s SLASH is list(non-adjunct-gap) in the adjunct extraction rule, but the mother’s will not meet that constraint.

However, if we can’t make the append-list approach to lexical threading compatible with coordination then either lexical threading has got to go, or the use of append lists for NON-LOCAL features does.

@ebender Great! I think the coordination problem can be solved, either with deleted-daughters, or with RELATIONAL.

@olzama That should be fine. The extraction rules can apply at any stage, but adjunct extraction is blocked from applying twice.

On second thought, though, it would be possible to do this with diff-lists if the extraction rules can add to the start of the list rather than the end. The adjunct gap can say that everything after it is not an adjunct, and then this constraint won’t apply to the adjunct gap itself. So using diff-lists is clearly fragile, but saying it’s impossible requires a careful argument about the order of the list…

Is MOD < X > such a feature?

Not necessarily a reliable one … things can be picked up as complements even though they are prepared to serve as modifiers.

Sound like a new feature, then? I can’t think of anything else for now…

I think I don’t want to be in a rush here. Perhaps for the abstract, I will just note that both problems ( 1) spurious ambiguity having to do with head-adjunct attaching both before and after subject extraction; 2) recursive adjunct extraction) can probably be solved by typed lists. In the abstract, I present one of the solutions.

(I could also note that some people have argued for a unified account of argument and adjunct extraction and that multiple adjunct extraction may be subject to processing constraints more than anything else, but perhaps that’s beside the point. The point being, if we want to restrict adjunct extraction to 1, we probably could by doing something similar to what we already did for ambiguity.)

How do typed lists help with spurious ambiguity?

@guyemerson If you want to look in the abstract draft, there is an example there. Basically the idea is to say that head-adjunct-phrase head daughter’s subject is a list of non-gappy things.

The phrase “spurious ambiguity” is used only in the second paragraph on page 4, without pointing to an example. (The abstract also isn’t available to everyone reading this forum.)

Could you give a sentence and explain what the ambiguity would be?

1 Like

I will do that as soon as I can but that might not happen before I come back from my conference+vacation trip! I had an example pair of trees somewhere but I am not sure where, need to look. Basically head-adjunct phrase can apply before and after subject-extraction in sentences like who where went, that’s the unwanted ambiguity.