[developers] Re: pending/674: generator broken on everything except the ERG?

[Stephan Oepen]

ann,

>  with the latest LKB serialize-semantics-indices appears to
>  presuppose that the  files *predicates-temp-file* and
>  *semantics-temp-file* exist - otherwise I can't index the lexicon
>  without a lexdb present. 

before you made that patch, what exactly happens when you try indexing
with *predicates-temp-file* and *semantics-temp-file* bound to nil?  i
had checked in a fix on 5-oct (after putting in the code on 3-oct) that
should address your case.  did you happen to still have revision 1.2 of
`serialize.lisp' (i.e. one obtained between 3-oct and 5-oct)?  the plan
is for the handler-case() to catch the condition and return nil, i.e. i
fail to see the need for your patch, other than to prevent the warning
message from serialize-semantics-indices():

  (handler-case
   ...
   (error (condition)
     (format
      t
      "serialize-semantics-indices(): error: `~a'~%"
      condition)
     (when (and forward (probe-file forward)) (delete-file forward))
     (when (and backward (probe-file backward)) (delete-file backward))
     nil))

while this functionality remains undocumented, supressing the warning
message is still a good thing, though, in my view.

>  even with this fix, the generator does not now seem to work with the
>  ESSLLI derived grammar I'm using [...]

do these problems persist, or does your later message mean that a fresh
session then allowed you to generate happily?  if not, what happens?

i just tried `g7sem' and found two issues, one boring one interesting:

  - the replacement MRS comparison fails on handle-free MRSs; i have a
    simple fix which i can check in in a few minutes;

  - when using packing (on by default nowadays, it seems), i run into
    an inifite loop in unpacking when generating from `the dog barks';
    this is the problematic edge:

      (27 head-specifier-rule 0.0 -1 0
       (24 head-specifier-rule 0.0 -1 0 (18 the 0.0 -1 -1 ("the" -1 -1))
        (23 dog 0.0 -1 -1 ("dog" -1 -1)))
       (13 head-complement-rule-0 0.0 -1 0
        (11 past-v_irule 0.0 -1 -1 (11 bark 0.0 -1 -1 ("barked" -1 -1)))))

    looking at 18, in turn:

      (edge-packed (find-gen-edge-given-id 18))
      --> (#[Edge # 22: `the' <>] #[Edge # 20: `head-complement-rule-0' <18>])

    in other words, we pack something derived from 18 (viz. 20) into 18
    itself, which i believe we have found undesirable in the past.

regarding this second issue, i think packing should be off by default,
so that teaching grammars are more easily debugged (someone with a real
grammar needs to be instructed to explicitly ask for packing then); and 
we need to find a way of preventing incestuous packings like the above
(i know ACE does this, but the PET parser is likely vulnerable in this
respect too).  john, would you agree to this strategy?

> [...] perhaps you could tell me what it was tested on (besides the
> ERG), since this might help me track down the problem?

oh, it was tested thoroughly on many versions of the ERG plus a little
bit of JaCY.  i doubt you will find this helpful :-).  my apologies if
the failure comparing handle-free MRSs caused you difficulties!

                                                           best  -  oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (ILN); Boks 1102 Blindern; 0317 Oslo; (+47) 2285 7989
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at csli.stanford.edu; oe at hf.uio.no; stephan at oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++