[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