[developers] ICONS and generation

[Stephan Oepen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: index.pdf
Type: application/pdf
Size: 66103 bytes
Desc: not available
URL: <http://lists.delph-in.net/archives/developers/attachments/20160218/e07fc971/attachment-0001.pdf>