<div dir="ltr">Thanks for your input, Stephan,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 12, 2018 at 2:31 PM, Stephan Oepen <span dir="ltr"><<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">dear all,<br>
<br>
i dimply recall there have been multiple previous discussions of<br>
documentation strings, but so far i could only turn up one such thread<br>
(which appears somewhat inconclusive, but provides some useful<br>
reminders also related to other questions originally raised by mike);<br>
<br>
<a href="http://lists.delph-in.net/archives/developers/2007/000868.html" rel="noreferrer" target="_blank">http://lists.delph-in.net/arch<wbr>ives/developers/2007/000868.ht<wbr>ml</a><br>
<br></blockquote><div><div><br></div><div>Thanks for linking this. This is the thread I referenced in my first
message, but I should have linked it then and saved you the trouble
of searching. I've added it to my list of discussions at the bottom of
the TdlRfc wiki.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
personally, i would think that there is complete freedom in how to<br>
order the various types of statements in TDL conjunctions, including<br>
repetition, e.g.<br>
<br>
foo := [ FOO + ] & bar & [ BAR - ] & baz.<br></blockquote><div><br></div><div>This is a different takeaway than I had from Ann's 2004 email on that thread, where she argued that supertypes have special status on types, unlike entries/instances, where they are not in fact supertypes (as Guy brought up in an earlier post). From p106 of Copestake 2002, discussing an example `a := b & c.`:</div><div><br></div><div>> Elsewhere in the TDL description language, `&` can be taken as equivalent to unification, but here it is understood as defining part of the type hierarchy. It follows from this type definition that the constraint on `a` will be the unification of the constraints on type `b` and type `c`, but [...] we need to know what the type hierarchy is before we can talk about unification, so the statement about the hierarchy is logically prior.</div><div><br></div><div>Thus, allowing supertypes and constraints to mix freely obfuscates the distinct role in hierarchy creation that the list of supertypes has. That is, it's a human-comprehensibility issue, not a technical one. But maybe her perspective has shifted in the last 14 years?<br></div><div><br></div><div>In any case, I think the current implementations allow for your definition of `foo`, and it's only convention that the supertypes appear first.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ann in that historic thread points out that it can be sensible to have<br>
instance definitions without explicit mention of the type; and i<br>
imagine the same could in principle also apply to type definitions<br>
(given strict appropriateness and type inference).<br></blockquote><div><br></div><div>Hmm.. I'll pretend I didn't read this. :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
so i am tempted to assume there is nothing special about the position<br>
of ‘parent’ types.<br>
<br>
i can see how the triple-double-quote syntax (""" ... """) would be<br>
position-independent, but it would seem to make lexical analysis more<br>
complex: currently, i believe, all TDL operators are single<br>
characters.<br></blockquote><div><br></div><div>Let's not forget :=, :+, <!, !>, ..., #|, |#, letter-set, wild-card, prefix, and suffix (ok, they aren't all "operators", but they are all TDL literals that need to be parsed).</div><div><br></div><div>Also it now occurs to me that the triple-double-quote option is essentially Ann's (vi): "invent yet another reserved character", which, to her, was an acceptable option.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i am wondering: could a simple string ever be part of the top-level<br>
conjunction in a type or instance definition? if so, how? if not,<br>
what would speak against treating all top-level TDL strings as<br>
documentation associated with the type or instance definition,<br>
independent of their position relative to other elements of a<br>
top-level conjunction, e.g. any of the following variants<br>
<br>
foo :=<br>
"a silly example" &<br>
bar & [ FOO + ].<br>
<br>
foo := bar &<br>
"a silly example" &<br>
[ FOO + ].<br>
<br>
foo := bar &<br>
[ FOO + ] &<br>
"a silly example".<br>
<br>
for full generality, one could then either allow a list of<br>
documentation strings associated with each type or instance definition<br>
(and have the addendum operator add to the tail of the list), or<br>
simply concatenate all such strings into one (presumably adding at<br>
least one newline between each pair of strings).<br></blockquote><div><br></div><div>Isn't this Ann's option (iii), which was rejected straight away? String literals, I think, are implicitly subtypes of *string-type*, and even if they never unify with, say, *avm*, I don't think that means it's uncharted territory yet to be defined, but that they should, simply, always fail to unify. Otherwise people may be confused why this won't work:</div><div><br></div><div>foo := bar &</div><div>[ FOO "inner-docstring" & + ].</div><div><br></div><div>(note: I'm not proposing we start allowing docstrings inside structures)<br></div><div><br></div><div>However, I can imagine defining """...""" as a syntax for something like [ DOC ... ] ( just as < stands for [ FIRST ..., REST *list* ]) which then can unify with the & operator, if we don't mind documentation being included in the feature structures (will this take a toll on memory usage during parsing?).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
—mike, many thanks for your work towards an up-to-date and<br>
consolidated definition of TDL syntax!<br>
<br>
oe<br>
<div class="m_2601664728461544901m_-7431151817236439039HOEnZb"><div class="m_2601664728461544901m_-7431151817236439039h5"><br>
<br>
On Thu, Jul 12, 2018 at 7:15 AM, Michael Wayne Goodman <<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>> wrote:<br>
> On Wed, Jul 11, 2018 at 7:59 PM, Francis Bond <<a href="mailto:bond@ieee.org" target="_blank">bond@ieee.org</a>> wrote:<br>
>><br>
>> On my phone so forgive the brevity, but in Paris we agreed that the<br>
>> docstring will start and end with three ". I think this is what pet now<br>
>> supports, Dan has a patch for the lkb, and I suspect I was meant to ask<br>
>> Woodley to add out to ACE.<br>
><br>
><br>
> Sorry I missed out on all the fun this year :(<br>
><br>
> I see what you describe mentioned in the LTDB presentation:<br>
> <a href="http://users.sussex.ac.uk/~johnca/summit-2018/ltdb-update.pdf" rel="noreferrer" target="_blank">http://users.sussex.ac.uk/~joh<wbr>nca/summit-2018/ltdb-update.pd<wbr>f</a><br>
><br>
> It seems the changes to PET are not yet merged in. Also I think Glenn would<br>
> also like to know about the agreement.<br>
><br>
>><br>
>> Comments anywhere would be great.<br>
>><br>
>> Thanks for pushing this forward Michael.<br>
>><br>
>> On Thu, 12 Jul 2018, 12:34 Michael Wayne Goodman, <<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>> wrote:<br>
>>><br>
>>><br>
>>> On Wed, Jul 11, 2018, 19:24 Woodley Packard <<a href="mailto:sweaglesw@sweaglesw.org" target="_blank">sweaglesw@sweaglesw.org</a>><br>
>>> wrote:<br>
>>>><br>
>>>> 2 cents worth...<br>
>>>><br>
>>>> 1. I think the logical behavior for an addendum with a doc string is<br>
>>>> concatenation, not replacement. The doc string on the addendum should<br>
>>>> document what the addendum adds to the type, not the whole type.<br>
>>><br>
>>><br>
>>> Hmm, good point. I guess the addendum can only add constraints, so the<br>
>>> old docstring wouldn't necessarily become invalid. I was comparing to method<br>
>>> overrides in Python classes, but that's not a useful comparison.<br>
>>><br>
>>>><br>
>>>> 2. ACE (I believe) allows comments just about anywhere in TDL. I find<br>
>>>> this very useful when editing TDL, e.g. annotating changes on a fine grained<br>
>>>> level or disabling certain constraints temporarily without deleting them.<br>
>>><br>
>>><br>
>>> Yes, it's definitely more useful to allow comments almost anywhere, and<br>
>>> not really hard to parse, either.<br>
>>><br>
>>>> Regards,<br>
>>>> Woodley<br>
>>>><br>
>>>> On Jul 11, 2018, at 5:00 PM, Michael Wayne Goodman <<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>><br>
>>>> wrote:<br>
>>>><br>
>>>> Thank you, Bernd, for the feedback. But I'm not having success parsing<br>
>>>> types with docstrings using PET. E.g., I changed sign-min in the ERG like<br>
>>>> this:<br>
>>>><br>
>>>> sign_min := *avm* &<br>
>>>> "doc"<br>
>>>> [ SYNSEM synsem_min,<br>
>>>> KEY-ARG bool ].<br>
>>>><br>
>>>> But flop doesn't like it:<br>
>>>><br>
>>>> goodmami@tpy:~/grammars/erg$ flop english.tdl<br>
>>>> reading `Version.lsp'...<br>
>>>> converting `english.tdl' (ERG (1214)) into `english.grm' ...<br>
>>>> loading `english.tdl'... including `fundamentals.tdl'...<br>
>>>> fundamentals.tdl:21:3: error: (syntax) - got ` [',<br>
>>>> expecting `.' at end of type definition<br>
>>>> [...]<br>
>>>><br>
>>>> I get similar errors no matter where I put it (before :=, directly after<br>
>>>> :=, after ]). It's syntactically valid if I have ... *avm* & "doc" & ...,<br>
>>>> but then it has trouble unifying (as expected).<br>
>>>><br>
>>>> It does, however, seem to be happy having a comment there (both ; and #|<br>
>>>> styles) instead of a doc string.<br>
>>>><br>
>>>> I'm using flop version 0.99.14svn_cm from the LOGON distribution.<br>
>>>><br>
>>>> On Wed, Jul 11, 2018 at 7:00 AM, Bernd Kiefer <<a href="mailto:Bernd.Kiefer@dfki.de" target="_blank">Bernd.Kiefer@dfki.de</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Concerning question 3, at least in TDL and PET there was no such<br>
>>>>> restriction,<br>
>>>>> but that could make the definition of docstrings easier.<br>
>>>>><br>
>>>>> Best,<br>
>>>>><br>
>>>>> Bernd<br>
>>>>><br>
>>>>> On 11.07.2018 03:01, Michael Wayne Goodman wrote:<br>
>>>>><br>
>>>>> I attempted to define a BNF-like description of TDL syntax on the wiki:<br>
>>>>> <a href="http://moin.delph-in.net/TdlRfc" rel="noreferrer" target="_blank">http://moin.delph-in.net/TdlRf<wbr>c</a><br>
>>>>> I tried to follow the partial BNF in the LKB source and often referred<br>
>>>>> to the lisp code itself in order to fill out the rest of the description.<br>
>>>>><br>
>>>>> My 3 questions above are concisely repeated at the bottom of the wiki<br>
>>>>> along with some others.<br>
>>>>><br>
>>>>> I welcome corrections and discussion (here or on the wiki) from any TDL<br>
>>>>> nerds or authorities (especially if you've written a TDL parser).<br>
>>>>><br>
>>>>> On Mon, Jul 9, 2018 at 12:49 PM, Michael Wayne Goodman<br>
>>>>> <<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>> wrote:<br>
>>>>>><br>
>>>>>> Hi developers,<br>
>>>>>><br>
>>>>>> I'm taking a closer look at the syntax of TDL files and the situation<br>
>>>>>> is a bit of a mess. Can anyone help me clarify some things? (I'll restrict<br>
>>>>>> myself to 3 questions for now)<br>
>>>>>><br>
>>>>>> The Copestake 2002 reference (Implementing TFS Grammars) has a BNF for<br>
>>>>>> TDL, but it's a bit out of date and, according to comments in the LKB source<br>
>>>>>> code, incorrect in parts. The LKB source comments are scattered, incomplete,<br>
>>>>>> inconsistent, and also a bit outdated. There is not much on the wiki. There<br>
>>>>>> is some discussion in the mailing list archives (much from before my time in<br>
>>>>>> DELPH-IN), but it's not clear how current those descriptions are.<br>
>>>>>><br>
>>>>>> Q1: Are supertypes special in a definition?<br>
>>>>>><br>
>>>>>> The BNF (in the LKB source) says this:<br>
>>>>>><br>
>>>>>> Type-def -> Type { Avm-def | Subtype-def} . |<br>
>>>>>> Type { Avm-def | Subtype-def}.<br>
>>>>>> Avm-def -> := Conjunction | Comment Conjunction<br>
>>>>>> Conjunction -> Term { & Term } *<br>
>>>>>> Term -> Type | Feature-term | Diff-list | List | Coreference<br>
>>>>>><br>
>>>>>> That makes it sound like I could do this:<br>
>>>>>><br>
>>>>>> mytype := [ FEAT val ] & supertype.<br>
>>>>>><br>
>>>>>> or even:<br>
>>>>>><br>
>>>>>> mytype := <! diff list.. !> & #coref & supertype.<br>
>>>>>><br>
>>>>>> But elsewhere it seems like a list of parents is special and appears<br>
>>>>>> before the rest of the conjunction. E.g., at read-tdl-avm-def of<br>
>>>>>> lingo/lkb/src/io-tdl/tdltypein<wbr>put.lsp I see this alternate definition of<br>
>>>>>> Avm-def:<br>
>>>>>><br>
>>>>>> ;;; Avm-def -> := Parents Conjunction | Parents Comment Conjunction<br>
>>>>>> |<br>
>>>>>> ;;; Parents | Parents Comment<br>
>>>>>><br>
>>>>>> It seems that both ACE and PET are fine with putting supertypes after<br>
>>>>>> the feature list (and some other variations). I'm fine with this, but I<br>
>>>>>> wonder what it means for docstrings (see Q3 below), which (I think) are<br>
>>>>>> supposed to appear after the list of parents and before the feature list.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Q2: Subtype-def is now just a variant of Avm-def, yes?<br>
>>>>>><br>
>>>>>> The BNF still describes subtyping (with the :< operator) as only<br>
>>>>>> taking a single parent:<br>
>>>>>><br>
>>>>>> Subtype-def -> :< type<br>
>>>>>><br>
>>>>>> But I believe the consensus is that this is unnecessary (it's<br>
>>>>>> equivalent to using := with only a supertype), so :< is treated as<br>
>>>>>> equivalent to := (to avoid breaking backward compatibility). Is this<br>
>>>>>> interpretation used by all processors?<br>
>>>>>><br>
>>>>>><br>
>>>>>> Q3: What's the final word with type comments / docstrings?<br>
>>>>>><br>
>>>>>> I find evidence of 3 proposed variants: (1) a block of ";" comments<br>
>>>>>> before a typename (LTDB-style); (2) a block of ";" comments within a type<br>
>>>>>> description; and (3) a "doc string" within a type description. Furthermore,<br>
>>>>>> there is a question as to whether comments or strings within a type go after<br>
>>>>>> the ":=" or after the list of supertypes. I think #| ... |# comments were<br>
>>>>>> not considered for this purpose.<br>
>>>>>><br>
>>>>>> My guess is this:<br>
>>>>>><br>
>>>>>> * LTDB-style comments (before the type identifier) are processed<br>
>>>>>> separately from TDL-parsing<br>
>>>>>> * type-internal comments can go anywhere but are discarded<br>
>>>>>> * type-internal doc strings must appear after the list of supertypes<br>
>>>>>> and are later available for inspection (they are included as a<br>
>>>>>> non-functional part of a type)<br>
>>>>>><br>
>>>>>> ACE seems happy with my assumptions, although PET doesn't seem to like<br>
>>>>>> doc strings at all.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Thanks!<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Michael Wayne Goodman<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Michael Wayne Goodman<br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> ------------------------------<wbr>------------------------------<wbr>----------<br>
>>>>> Bernd Kiefer DFKI GmbH, Stuhlsatzenhausweg, D-66123 Saarbruecken<br>
>>>>> <a href="mailto:kiefer@dfki.de" target="_blank">kiefer@dfki.de</a> +49-681/85775-5301 (phone) +49-681/85775-5338 (fax)<br>
>>>>> ------------------------------<wbr>------------------------------<wbr>----------<br>
>>>>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH<br>
>>>>> Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany<br>
>>>>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vor-<br>
>>>>> sitzender), Dr. Walter Olthoff<br>
>>>>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes<br>
>>>>> Amtsgericht Kaiserslautern, HRB 2313<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Michael Wayne Goodman<br>
><br>
><br>
><br>
><br>
> --<br>
> Michael Wayne Goodman<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="m_2601664728461544901m_-7431151817236439039gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Michael Wayne Goodman</div></div></div></div></div></div>
</div></div></div>