[developers] Questions on the syntax of TDL
Michael Wayne Goodman
goodmami at uw.edu
Thu Jul 12 20:03:15 CEST 2018
Putting Bernd's reply back on the list.
Also, I updated the TdlRfc wiki to include several proposals for the
placement of docstrings (http://moin.delph-in.net/TdlRfc#Docstring_Revision).
I find the simplicity of Option 4 appealing, but I know others used to find
it ugly. (I'm happy if people interested in the discussion want to edit the
wiki with comments or other proposals.)
On Thu, Jul 12, 2018 at 1:59 AM, Bernd Kiefer <Bernd.Kiefer at dfki.de> wrote:
> Hi Wayne, Woodley
>
> Yes, that's correct. The parser of pet was not adapted to the docstrings.
> Maybe that could be done when you concluded the effort of creating a
> "definitive" syntax description. I think that even the addition operator
> is still not (fully?) functional in pet.
>
> Best,
>
> Bernd
>
>
>
> On 12.07.2018 02:00, Michael Wayne Goodman wrote:
>
> Thank you, Bernd, for the feedback. But I'm not having success parsing
> types with docstrings using PET. E.g., I changed sign-min in the ERG like
> this:
>
> sign_min := *avm* &
> "doc"
> [ SYNSEM synsem_min,
> KEY-ARG bool ].
>
> But flop doesn't like it:
>
> goodmami at tpy:~/grammars/erg$ flop english.tdl
> reading `Version.lsp'...
> converting `english.tdl' (ERG (1214)) into `english.grm' ...
> loading `english.tdl'... including `fundamentals.tdl'...
> fundamentals.tdl:21:3: error: (syntax) - got ` [',
> expecting `.' at end of type definition
> [...]
>
> I get similar errors no matter where I put it (before :=, directly after
> :=, after ]). It's syntactically valid if I have ... *avm* & "doc" & ...,
> but then it has trouble unifying (as expected).
>
> It does, however, seem to be happy having a comment there (both ; and #|
> styles) instead of a doc string.
>
> I'm using flop version 0.99.14svn_cm from the LOGON distribution.
>
> On Wed, Jul 11, 2018 at 7:00 AM, Bernd Kiefer <Bernd.Kiefer at dfki.de>
> wrote:
>
>> Concerning question 3, at least in TDL and PET there was no such
>> restriction,
>> but that could make the definition of docstrings easier.
>>
>> Best,
>>
>> Bernd
>>
>> On 11.07.2018 03:01, Michael Wayne Goodman wrote:
>>
>> 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
>>
>>
>> --
>> ----------------------------------------------------------------------
>> Bernd Kiefer DFKI GmbH, Stuhlsatzenhausweg, D-66123 Saarbrueckenkiefer at dfki.de +49-681/85775-5301 (phone) +49-681/85775-5338 (fax)
>> ----------------------------------------------------------------------
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbHTrippstadter Strasse 122, D-67663 Kaiserslautern, Germany <https://maps.google.com/?q=Trippstadter+Strasse+122,+D-67663+Kaiserslautern,+Germany&entry=gmail&source=g>
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vor-
>> sitzender), Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern, HRB 2313
>>
>>
>
>
> --
> Michael Wayne Goodman
>
>
> --
> ----------------------------------------------------------------------
> Bernd Kiefer DFKI GmbH, Stuhlsatzenhausweg, D-66123 Saarbrueckenkiefer at dfki.de +49-681/85775-5301 (phone) +49-681/85775-5338 (fax)
> ----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbHTrippstadter Strasse 122, D-67663 Kaiserslautern, Germany <https://maps.google.com/?q=Trippstadter+Strasse+122,+D-67663+Kaiserslautern,+Germany&entry=gmail&source=g>
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vor-
> sitzender), Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
>
>
--
Michael Wayne Goodman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20180712/e3b0deb9/attachment-0001.html>
More information about the developers
mailing list