[developers] LKB vs. PET divergences

[Ann Copestake]

I don't have PET here, but what seems to be going on is a discrepancy in the 
way that the glb is being computed or a discrepancy in the way that
the rule is being treated.  

vstem-vstem-rule is defined as 


vstem-vstem-rule := head-final-type & 
		    orth-princ &

the LKB gives glbtype71 as the glb of those two.  This is a subtype of 
argument-binding-princ which brings in the coindexation between the HOOK of 
the mother and the HOOK of the HEAD-DTR.  head-final-type sets the HEAD-DTR to 
the second DTR.  So the coindexation is as expected if glbtype71 is the type.

Should glbtype71 inherit from argument-binding-princ?  Well, I'd say it's 
plausible, given that the glbtypes are supposed to minimize the hierarchy.  
head-final-type has four immediate subtypes: head-specifier-rule-type, 
head-complement-hf-type and head-subject-rule.  These are all subtypes of 
orth-princ, but they are also all subtypes of argument-binding-princ.

Possibly, PET is creating a new `pure' glbtype at the point when the 
definition of vstem-vstem-rule is read in.  This would be incorrect - as 
stated in the previous message, the formalism says that this is just a 
description of a feature structure.  We don't allow the calculation of new 
glbs during unification in general and it shouldn't be allowed here.

Alternatively, we have a discrepancy in the glb calculation algorithm, which 
would also be possible, though horrible to fix.  If there's a formal 
definition of glbtype introduction which says whether it is or is not supposed 
to introduce pure types in this situation, then we can decide which behaviour 
is correct.

Ann