Problems in generation.
-----------------------

In a flat rule you don't know how many daughters there are, unless you
know the subcat list of the head. However, the subcat list of a head
may be underspecified. For example in the case of partial vp
topicalization:

[[slapen] wil jan

the generator selects `wil' as the head-corner. In order to complete
the verb phrase it has to generate the arguments not selected by
`slapen' (or any other verb). It does not know yet the semantics of
these arguments, nor the NUMBER of the arguments. The first problem is
solved by delaying generation of phrases with uninstantiated
semantics. If we were to delay the generation of an unknown sequence
of categories, then we will not be able to get an instantiated
slash-value and hence we cannot properly generate the topic! This is so
because the foot feature principle can only be applied after the list
of arguments has been generated.

Note that this problem is not specific for semantic-head-driven
generation but also occurs in Shiebers chart-based bottom-up approach,
or in Wedekind's top-down approach.

In bug_c.pl the problem is `solved' by associating a size to each
semantic structure. In order to generate a semantic structure with
size s we can never (sub-) generate more than s categories.  This is
potentially problematic --- but no actual problems have been
encountered yet. Note that such a size function could be added to
any of the other strategies.

In bug_dd.pl the problem is solved by associating each lexical entry
with a list of arguments that it is going to select at some point --
either directly via the subcat list or indirectly via topicalisation or 
extraposition. This list is generated first. As the elements of the list
are (at least partially) reentrant with the elements on all kinds of
selection lists we only have to make sure that this list is properly
ordered.

Note that a history mechanism is used in order not to generate the
same thing twice (in fact, we do generate it twice, but the second
time is deterministically). 

Finally note that bug_dd is MUCH faster than bug_c.




