[developers] ICONS and generation

[Ann Copestake]

I'm happy to add the augmented notation.  I think I can also make the 
generator code behave correctly - I'd already added a check when I 
realised the issue so it's a matter of making the check work with the 
... notation as well - but I'd leave it up to you to think about 
efficiency.  I am concerned that when we mix different types of 
constraints in ICONS, things may not work out smoothly, but I'll get 
this working first and worry about the other types of constraint later.

Ann


On 18/02/2016 21:36, Stephan Oepen wrote:
> sorry for the late follow-up in this thread!
>
>> [...] whether simply enriching ICONS (and possibly HCONS) with a ... notation
>> would be enough to give us what's needed in terms of behaviour [...]
> i believe introducing the distinction between {} and {...} will in any
> way be a necessary and useful addition.  as far as i understand things
> currently, this should be enough to address the desiderata i had put
> forth.  the parsing result for a ‘plain’ input would presumably by
> default be interpreted as {...} and would support realization of
> marked variants (e.g. a passive).  removing the dots could be viewed
> as a specialization, and would constrain realization to just the plain
> variant.
>
> i have started to think about how to implement this.  i could imagine
> the ‘...’ to just be something like a kleene wildcard in the ICONS
> set, i.e. a fully underspecified constraint (in terms of its relation
> type, LEFT, and RIGHT) that can be used n times, for n >= 0.  ICONS
> construction from parsing TFSs would have to insert the wildcard, and
> the post-realization semantic compatibility test would have to treat
> it appropriately.  as for the latter, i will be happy to look into
> adapting that code, but i am under the impression you would first like
> to provide the addition of ICONS to the basic MRS structures,
> construction from TFSs, and serializations, right?
>
> which leaves open the question as to whether to try and consider ICONS
> when initializing the chart for realization.  i cannot think that
> through properly tonight; i suspect one may not have to (for
> correctness, leaving ICONS comparison wholly to after realization),
> but there might well be effiency gains to be had there.  however, from
> my point of view, the current LKB chart initialization code is not
> fully optimized in that respect anyway (i.e. not always putting the
> minimal required set of intial edges into the chart), thus i would be
> inclined to first try and put everything together, before we worry too
> much about efficiency.
>
> woodley and i once devised an improved indexing scheme (in part during
> a longer tram ride though oslo, i seem to recall :-), which is
> implemented in ACE.  for the record, i attach a draft summary written
> by woodley (for a manuscript that did not quite come together in the
> end).
>
> best wishes, oe