Difference lists, Emerson lists and multiple wh-extraction
Present: Olga Zamaraeva (OZ), Woodley Packard (WP), Dan Flickinger (DF), Guy Emerson (GE), Berthold Crysmann (BC), John Carroll (JC), David Inman (DI), Emily Bender (EB)
Scribe: Emily Bender
OZ: For Slavic languages want to be able to do multiple extraction.
GE: What’s the order without wh words?
OZ: The neutral word order is SVO, here SVadjunct. You were there then.
WP: At least in English where is somewhere between complement and adjunct. Can you do when and how, both unambiguously adjuncts?
OZ: How and when did you do it? Judgments are the same: with over coordinator, it’s fine, but without it’s iffy.
DP: Okay, but the ones with the overt coordinators aren’t relevant for this discussion, because they’re single extraction, right?
OZ: Right. Just trying to get a sense of what we might need to handle.
DP: Need multiple extraction in English too: “That’s a problem that I don’t know how to solve.” Solve is missing both manner adverbial (how) and its complement (problem). Top of the LDDs is different, not two wh words in a row, but still need a SLASH list with two things on it.
BC: Be careful taking the presence of a coordinator at face value: “What and to whom has Bill written?” Also in Russian: “Always and to all this professor would like to help.” External relation of the coordinated elements is different, so maybe not ordinary coordination.
OZ: Yesterday, Sanghoun said he would like to analyze these cases as some kind of fake coordination, but I didn’t get a detailed sense.
DI: Pseudo-coordination is the term, not sure if it applies here. Canonical examples: “go and see if”, not really go and then see. Other examples?
EB: try and
GE: come and
DI: Clearest example is “try and” where the other verb is obviously subordinate to try, but there’s an and. Main point: coordination is funny sometimes, seeing an ‘and’ doesn’t make it necessarily real coordination.
BC/OZ: Can put in ands in each of the spots in (2).
BC: “Where who and when gave?”
OZ: Also okay, in fact the best.
BC: So that’s a “coordination” of adjunct, argument, adjunct, so clearly not really coordination.
EB: And Adam P isn’t here so we can keep assuming a clear argument/adjunct distinction.
BC: Adam should be here, he would type raise everything to argument, and then even (3b) is a big problem.
OZ: Displays basic-filler-phrase…. what is the problem? Here the SLASH is constrained to be of length one. What’s the technical problem that I will have with this data?
WP: Is it the case that the ERG doesn’t do multiple slashes just to keep the chart from exploding?
BC: Cannot limit the length easily with diff-lists, though with 0-1 it works.
WP: Can’t stop at 2?
GE: You could, but Dan once said it’s hard to justify max 3 or something like that.
DI: But we know that one isn’t a enough…
DF: We typically try to choose our problems when building an engineering platform, and making the counterfactual assumption that SLASH lists are max one.
EB: How did that help?
DF: Readily understandable to constrain diff-list of max one.
EB: And why do you need a known max length?
WP: Recursive adjunct extraction.
EB: We can block that another way though.
EB: typed list, can ensure exactly one adjunct extraction
DP: Let’s say I never want to extract both arguments of give, I don’t want the edge in the chart that pretends that I can.
BC: Hausa resumption can easily have several long distance dependencies, but only one can be a gap, so I could keep with the one adjunct constraint. That is implemented in the Hausa Matrix-based grammar, so that’s a good place to look. GF paper in 2015. Uses lists to restrict gap-type SLASH elements to one.
EB: Will be interesting to look at b/c the version of these constraints from the ERG in 2001 impressionistically uses these 0-1-dlist to keep things together in various ways that I don’t understand. And when I try to loosen them, things get to underconstrained. This is why I thought Emerson lists might help.
DP: In those days, I felt like I was keeping a monster under control, with tweaks like one order of the append arguments working when the other didn’t. The base from which the Matrix was launched wasn’t such solid engineering in this respect. Share the intuition that the Emerson lists might help.
DP: If I take off the global 0-1-dlist constraint, how could I say at most complement of give can be extracted, if I wanted to?
EB: Because of lexical threading, couldn’t you say that the SLASH of give itself is 0-1-dlist?
WP: But doesn’t that block adjunct extraction?
EB: No because adjuncts aren’t subject to lexical threading.
WP/GE: But yes, because the 1-dlist case can’t be integrated into a long diff-list above.
EB: So this sounds like the point where the Emerson lists might help.
GE: Biking in, I thought there wouldn’t be anything you could do with diff-lists that you can do with Emerson lists, but it seems like this is one.
DP: Also need to be able to ask: “are you empty?”. 0-1-dlist typing helps with requiring subtype 0-dlist. So even if we go for a bigger max length, still need types, but a bigger subhierarchy.
DI: With Emerson lists, could check for empty, right?
GE: Yes. And can still append afterwards unlike with diff-lists, once asserted to be empty, always empty.
BC: Also lose constraints like olist on a list. So you’re free to impose those constraints anew, right?
GE: The list and the container are both new, but the elements are unified with the lower ones.
EB: To summarize: the big win with the Emerson lists here is that at any point you can look at the length, know what it is, and still do further append with them up the tree.
DP: Can I still check for e.g. olist?
GE: Could make yet another subtype cons-of-alists-that-are-olists…
EB: If you’re just checking for a property on a list, then you can just use the type on the checking and don’t have to keep transmitting that property up.
DP: Right—if the things like olist are only used for checking for something and not for publishing properties, then it’s easy. Otherwise, I need to make new varieties of Emerson lists, and I think I see how to play that game.
WP: How much info gets carried up?
GE: It will all be inside the APPEND feature, quite deep at the top of the tree. Eventually get down to the ones defined directly in the grammar…
WP: So would be tempting to add these to “deleted daughters” in processing, but what happens with implicit computation, e.g. with lexical threading, where the value of SLASH on a head depends on its arguments, several levels up in the tree. Would trimming that stuff off lose information?
GE: If you were trying append underspecified lists that would happen…
EB: That’s exactly what lexical threading does.
DP: The mother’s SLASH is always only the head’s, but that’s built up from the arguments.
GE: I can see how that might be a problem then.
DP: So we might not be able to prune it.
WP: If you were going to use it for RELS then that could get inefficient….
EB: But with RELS we’re already ignoring RELS, so we don’t have to ignore APPEND in general to not get the RELS appends.
DP: It would be luxurious if the only problem was an efficiency one.
GE: Might need to add mutual subtypes for olist (and other parameterized lists) and the append types so that they unify, in case you are checking for olist and then trying to append that. (Otherwise will get unification failure.)
All: Admire example from Guy’s modified 567-English grammar with all diff-lists replaced with Emerson lists. Reentrancy numbers get high!
EB: Is this where we were going to talk about syntactic sugar?
GE: Aside: You have to choose one or the other — diff-list appends or my appends; can’t mix.
GE: If this is used widely, then special syntax would be nice.
EB: Could we also do sugary display in LUI?
WP: Would you like something like FEAT < value, value, value > = [nn] (+) [mm]?
EB: That would be nice
WP: Somebody could do that….
EB: We have a lot of somebodies floating around the CLMS program. Would you be okay with them digging in the LUI code?
GE: Why didn’t we do just .L instead of .LIST for diff-lists?
WP: The bang operator also has to do computation of the reentrancy.
DP: I hate searching for .L.
GE: So maybe we don’t need anything?
DP: Let’s work with it for a while and then see if we want syntactic sugar.
GE: Can also look — this grammar doesn’t use the bool or wrapper types, but I had a couple of types I used to make sure I was doing things correctly. Look at my-and, which is calculating various test cases. LKB Top | View expanded type | my-and. You can collapse the value of OR/AND inside each test and then just see the result.
EB: Pay no attention to the man behind the curtain…
GE: Look at my-nums for a test of the numerical operations. Result of addition of 0 + 1 + 2 + 0 is a list with three things on it. Doesn’t display “three”, but if these ever became widely used, we might want syntactic sugar for this. But it’s not clear what they would be used for.
BC: Can’t do all integers because we have finite memory.
GE: You can do as many integers as you have memory for. There’s no hard coded limit.
JC: If you knew the set of sums you needed to do, you could hard code them.
WP: If we knew the set of sentences we wanted to parse…
GE: The boolean stuff is more efficient…
BC: Without this level of generalization, I’ve been using a similar idea for direct-inverse / person hierarchy and for polar tones (tone is opposite of preceding tone), like your boolean.
BC: The append types will help simplify my Hausa multiple SLASH grammar.
EB: Will also be useful for Chris’s valence changing lexical rules library (& similar) because it allows append of things to the *end* of a COMPS list without knowing the length of the list.
WP: I’d like to go see the computation. Looking through SLASH value of S “A cat chased me” and VP “chased me”, where the SLASH should be SLASH of subject (as yet unknown) appended to null.
[ Ultimate conclusion: We didn't find the underspecification we were looking for, and hypothesized it's because the grammar itself doesn't fully or correctly implement lexical threading, as it doesn't actually model any long-distance dependencies.]
DI: Would be nice to have LUI sugar that hides all of that…
DP: .luirc file lets you minimize features by default.
WP: Very easy to do, might even be documented…
EB: We should have this come out of the customization system.
WP: It’s a user-level setting, not a grammar-level setting. Could be sent to the LKB…
JC: LKB has a notion of shrinking and expanding.
WP: Is there a global for that—for which features are expanded by default?
WP: The Matrix could set that then.
EB: Where is that documented or what’s the parameter called?
JC: *shrunk-types*. “Output display settings” dumps that value. Options | Display settings.
WP: Might not be hooked up to the LUI actually.
EB: But if it’s not sent from the LKB, could still set it in a user-level luirc file.
WP: Would be presumably be easy to improve the LKB (and ACE) in that way.