[developers] type addenda and :< in TDL

Stephan Oepen oe at ifi.uio.no
Thu Nov 27 22:47:10 CET 2008


hi again,

> from my perspective, it's there for backward compatability, but I'm
> not keen to get rid of it since it'll cause hassle for no good reason.

i just had a quick look at the relevant code in the LKB and PET.  if we
agree the `:=' vs `:<' distinction has no formal status in the DELPH-IN
formalism, we can just treat `:<' as a syntactic variant.  this will be
trivial to implement and not show any effect on existing grammars.  we
could optionally issue a deprecation warning when `:<' is used, or just
internally suggest to DELPH-IN grammarians that they avoid `:<'.

> Presumably you will be changing some :< cases to :=, but I don't want
> to force everyone to change all of them.  You might be able to produce
> a patch to tdltypeinput.lsp so it doesn't complain if you try and
> augment a :< type, but that shouldn't be checked in, I feel.

in fact, the current LKB allows type addenda on types defined by `:<',
so there is a mild inconsistency here.  PET enforces what i believe was
the original TDL intention of `:<', viz. a sub-type definition without
a local constraint (it can still inherit features and constraints).  i
would like the two systems to behave alike, but to decide what is right
we would have to ascribe a formal interpretation to `:<', which i think
we all agree is undesirable.

i would be happy making the change reading `:<' as `:=' in both worlds.
i would prefer seing `:<' deprecated.  in my teaching experience, it is
a potential source of confusion.  would anyone object to that move?

                                                        cheers  -  oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at ifi.uio.no; oe at csli.stanford.edu; stephan at oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



More information about the developers mailing list