[developers] Questions on the syntax of TDL

Michael Wayne Goodman goodmami at uw.edu
Wed Jul 11 03:01:06 CEST 2018


I attempted to define a BNF-like description of TDL syntax on the wiki:
http://moin.delph-in.net/TdlRfc
I tried to follow the partial BNF in the LKB source and often referred to
the lisp code itself in order to fill out the rest of the description.

My 3 questions above are concisely repeated at the bottom of the wiki along
with some others.

I welcome corrections and discussion (here or on the wiki) from any TDL
nerds or authorities (especially if you've written a TDL parser).

On Mon, Jul 9, 2018 at 12:49 PM, Michael Wayne Goodman <goodmami at uw.edu>
wrote:

> Hi developers,
>
> I'm taking a closer look at the syntax of TDL files and the situation is a
> bit of a mess. Can anyone help me clarify some things? (I'll restrict
> myself to 3 questions for now)
>
> The Copestake 2002 reference (Implementing TFS Grammars) has a BNF for
> TDL, but it's a bit out of date and, according to comments in the LKB
> source code, incorrect in parts. The LKB source comments are scattered,
> incomplete, inconsistent, and also a bit outdated. There is not much on the
> wiki. There is some discussion in the mailing list archives (much from
> before my time in DELPH-IN), but it's not clear how current those
> descriptions are.
>
> Q1: Are supertypes special in a definition?
>
> The BNF (in the LKB source) says this:
>
>     Type-def -> Type { Avm-def | Subtype-def} . |
>                          Type { Avm-def | Subtype-def}.
>     Avm-def -> := Conjunction | Comment Conjunction
>     Conjunction -> Term { & Term } *
>     Term -> Type | Feature-term | Diff-list | List | Coreference
>
> That makes it sound like I could do this:
>
>     mytype := [ FEAT val ] & supertype.
>
> or even:
>
>     mytype := <! diff list.. !> & #coref & supertype.
>
> But elsewhere it seems like a list of parents is special and appears
> before the rest of the conjunction. E.g., at read-tdl-avm-def of
> lingo/lkb/src/io-tdl/tdltypeinput.lsp I see this alternate definition of
> Avm-def:
>
>   ;;; Avm-def -> := Parents Conjunction | Parents Comment Conjunction |
>   ;;;               Parents | Parents Comment
>
> It seems that both ACE and PET are fine with putting supertypes after the
> feature list (and some other variations). I'm fine with this, but I wonder
> what it means for docstrings (see Q3 below), which (I think) are supposed
> to appear after the list of parents and before the feature list.
>
>
> Q2: Subtype-def is now just a variant of Avm-def, yes?
>
> The BNF still describes subtyping (with the :< operator) as only taking a
> single parent:
>
>     Subtype-def ->  :< type
>
> But I believe the consensus is that this is unnecessary (it's equivalent
> to using := with only a supertype), so :< is treated as equivalent to :=
> (to avoid breaking backward compatibility). Is this interpretation used by
> all processors?
>
>
> Q3: What's the final word with type comments / docstrings?
>
> I find evidence of 3 proposed variants: (1) a block of ";" comments before
> a typename (LTDB-style); (2) a block of ";" comments within a type
> description; and (3) a "doc string" within a type description. Furthermore,
> there is a question as to whether comments or strings within a type go
> after the ":=" or after the list of supertypes. I think #| ... |# comments
> were not considered for this purpose.
>
> My guess is this:
>
> * LTDB-style comments (before the type identifier) are processed
> separately from TDL-parsing
> * type-internal comments can go anywhere but are discarded
> * type-internal doc strings must appear after the list of supertypes and
> are later available for inspection (they are included as a non-functional
> part of a type)
>
> ACE seems happy with my assumptions, although PET doesn't seem to like doc
> strings at all.
>
>
> Thanks!
>
> --
> Michael Wayne Goodman
>



-- 
Michael Wayne Goodman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20180710/6ef0cc7a/attachment.html>


More information about the developers mailing list