<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Hi Mike (and parser developers),</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Of the two choices that you suggest, Mike, I would favor the second, which if I understand you right would minimize disruption and enable us to adopt consistent conventions about where docstrings go even if the implementation
 would allow more flexibility.&nbsp; I am content with having one docstring per definition.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">We would all be grateful if the following four parallel actions by developers would happen soon:</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">(1) Bernd checks to see if any changes are needed in PET to satisfy the emerging proposal.&nbsp; I suspect that some adjustments may be needed in order to support docstrings on type addendum definitions, including concatenation
 if there was already a docstring provided in the original type definition.<br>
</p>
<div><br>
</div>
<div>(2) John, who has already had a look at the LKB patch for triple quote docstrings that I added a while ago to the trunk erg/lkb/patches.lsp, improves on that code as needed to support concatenation and type addenda.</div>
<div><br>
</div>
<div>(3) Woodley adapts ACE to accommodate triple quotes for docstrings (in addition to or in place of the current one (double) quote strings), and to support concatenation and type addenda.</div>
<div><br>
</div>
<div>(4) Glenn enables support for docstrings in agree.<br>
</div>
<div><br>
</div>
<div>I will be happy to convert the trunk ERG's existing docstrings to fit the emergent specification as soon as the parsers are all suitably improved, and selfishly hope it will happen quickly so this won't hold up getting the 2018 ERG version out.</div>
<div><br>
</div>
<div>&nbsp;Dan</div>
<div><br>
</div>
<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> developers-bounces@emmtee.net &lt;developers-bounces@emmtee.net&gt; on behalf of Michael Wayne Goodman &lt;goodmami@uw.edu&gt;<br>
<b>Sent:</b> Saturday, August 4, 2018 11:52 AM<br>
<b>To:</b> Francis Bond<br>
<b>Cc:</b> developers<br>
<b>Subject:</b> Re: [developers] doc-strings in TDL for DELPH-IN</font>
<div>&nbsp;</div>
</div>
<meta content="text/html; charset=utf-8">
<div>
<div dir="ltr">Hi Francis, thanks for keeping the conversation alive.
<div><br>
</div>
<div>We're in agreement about the triple-quoted docstrings, and that a docstring in a type addendum should be concatenated to any docstrings from previous type definitions/addenda.</div>
<div><br>
</div>
<div>The remaining issue is placement, and what you advocate (basically Option 3 on the wiki) brings up a disconnect between the conventional way of describing types (supertypes before features) and what's formally allowed by (our current implementations of)
 TDL (rearrangeable terms). Also, type addenda do not require supertypes at all. I'll try to avoid getting into this quagmire again lest it stall the conversation, and instead offer two simpler choices (ignoring other alternatives), either of which would allow
 you to do what you want:</div>
<div><br>
</div>
<div>(1) we change our TDL-parsers to ensure that top-level supertypes, if any, appear before other terms</div>
<div><br>
</div>
<div>(2) we allow a docstring to appear before any top-level term (Option 2 on the wiki) or before the final . character, but only one per (type/addendum/instance) definition</div>
<div><br>
</div>
<div>Above, (1) is the heavier solution that may break backward compatibility with some grammars, while (2) would allow you to put docstrings where you don't necessarily want them (but you can always follow your own convention). I'm happy to support either.</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr">On Fri, Aug 3, 2018 at 8:59 PM Francis Bond &lt;<a href="mailto:bond@ieee.org" id="LPlnk594133" class="OWAAutoLink" previewremoved="true">bond@ieee.org</a>&gt; wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
G'day,<br>
<br>
I am starting a new thread as the other one was getting quite long:<br>
thanks Michael for starting the original discussion.<br>
<br>
We need doc-strings working to move forward with the new linguistic<br>
type documentation.&nbsp; &nbsp;It is a great pity that Stephan,Woodley, Michael<br>
Glenn and Ann were not there on that day, but we reached a broad<br>
consensus at Paris that triple double quotes ' &quot;&quot;&quot;&nbsp; ' was a good<br>
delimiter, with them basically allowed after the types.&nbsp; We have (if I<br>
understand correctly) code for PET from Rebecca, and code for the LKB<br>
(from Dan, although it may need to be extended to the instances).<br>
<br>
Woodley currently has a working implementation with just ' &quot; ' (but<br>
only after := , not for example, :&#43;) which allows for escaped quotes '<br>
\&quot; ' which currently the LKB does not allow.<br>
<br>
Could we move forward with the &quot;&quot;&quot; option, nicely documented by Michael here:<br>
<br>
<a href="http://moin.delph-in.net/TdlRfc" rel="noreferrer" target="_blank" id="LPlnk216644" class="OWAAutoLink" previewremoved="true">http://moin.delph-in.net/TdlRfc</a><br>
<br>
&nbsp;DocString&nbsp; &nbsp; := /&quot;&quot;&quot;([^&quot;\\]|\\.|&quot;[^&quot;]|&quot;&quot;[^&quot;])*&quot;&quot;&quot;/ Spacing<br>
<br>
I would go for one doc-string per type and doc strings in addendums<br>
concatenating with the origins.<br>
<br>
Could we try to reach consensus as soon as possible?&nbsp; &nbsp;I do not want<br>
it to drift away again, as it has so many times in the past, ...<br>
<br>
<br>
-- <br>
Francis Bond &lt;<a href="http://www3.ntu.edu.sg/home/fcbond/" rel="noreferrer" target="_blank" id="LPlnk798875" class="OWAAutoLink" previewremoved="true">http://www3.ntu.edu.sg/home/fcbond/</a>&gt;<br>
Division of Linguistics and Multilingual Studies<br>
Nanyang Technological University<br>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>