<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> </head> <body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""> Hi, <div class=""><br class=""> </div> <div class="">Thanks for trying to fix the LKB.</div> <div class=""><br class=""> </div> <div class="">I think your TDL clean-ups are a very good idea. The new version of read-tdl-type-comment in patches.lsp will indeed eventually make it into the LKB proper. But I was concerned about not being able to patch existing LKB binaries effectively. When I referred to backward compatibility, I was thinking about LKB binaries in distributions that may never get updated, e.g. <a href="http://www.cs.upc.edu/~padro/docker-logon.tgz" class="">http://www.cs.upc.edu/~padro/docker-logon.tgz</a> and Knoppix+LKB . This might not be too much of a problem  in practice except that some LKB error messages are poor or misleading.</div> <div class=""><br class=""> </div> <div class="">I'll have a go at making a minimal set of changes that could be put in a patch file, and add a more considered reimplementation of TDL reading to my todo list.</div> <div class=""><br class=""> </div> <div class="">John</div> <div class=""><br class=""> <div> <blockquote type="cite" class=""> <div class="">On 8 Sep 2018, at 00:09, <a href="mailto:goodman.m.w@gmail.com" class=""> goodman.m.w@gmail.com</a> wrote:</div> <br class="Apple-interchange-newline"> <div class=""> <div dir="ltr" class=""> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hi again,</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I spent an hour or two editing patches.lsp to try and make it work, but my lisp writing and debugging knowledge is too limited to figure it out right now. Here's what I tried to do:</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* read-tdl-top-conjunction:</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  - a copy of read-tdl-conjunction, except for the following...<br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  - call read-tdl-type-comment if peek-with-comments returns " before calling read-tdl-defterm</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  - append the pair (docstring . term) to the "constraint" variable instead of just term<br class=""> </div> * read-tdl-avm-def:</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  - remove the part about reading parents<br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  - expect a pair (docstring . term) from read-tdl-top-conjunction</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  - append the docstring to the "comment" variable</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  - extract the term as "unif" and proceeds as before</div> * read-tdl-type-comment: <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  - if it doesn't encounter """, it calls unread-char to put those quotes back on the stream, because it may be a regular "string" or empty "" string</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  - don't print an error if the string doesn't start with """<br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I only created read-tdl-top-conjunction so that I didn't have to redefine all the other places where read-tdl-conjunction was used. Trying to load the ERG with these changes gives me an "Unexpected unif" error when it tries to load fundamentals.tdl.<br class=""> </div> </div> <br class=""> <div class="gmail_quote"> <div dir="ltr" class="">On Fri, Sep 7, 2018 at 11:59 AM <a href="mailto:goodman.m.w@gmail.com" class=""> goodman.m.w@gmail.com</a> <<a href="mailto:goodman.m.w@gmail.com" class="">goodman.m.w@gmail.com</a>> wrote:<br class=""> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr" class=""> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks for the feedback, John,</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">While I appreciate your arguments and code, I am reluctant to agree with any changes now. The LKB has been a pioneer in allowing docstrings, but I don't think we should revert the work other developers have put into their processors in the last month, not to mention the hard-earned consensus over the color of this bike shed. Here are my reasons:</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">1. The agreed-upon syntax does not break backward compatibility (except regarding the number of quote characters), it only opens up new places where docstrings may occur (see (3))<br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">2. The lack of support for docstrings outside of the LKB hindered their adoption, so backward compatibility isn't much of an issue given that grammar developers avoided using them (given this, maybe I should have pushed harder for docstrings immediately after := or :+... oh well).<br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">3. The LKB's implementation that parses supertypes (or "parents" as used in the lisp code) before other terms is only half-baked. It first reads some type names, then looks for a docstring, then reads other terms, which may include more type names. I proposed making a change to the syntax so that type names must appear before other terms in a top-level conjunction, but the only replies I got addressing this point (from Stephan and Dan) opposed such a change. Thus, we agreed that type names have no special position in conjunctions. Because of this, saying that the docstring must occur before the AVM means little, because (a) the AVM may appear before a type name, and (b) there may be more than one AVM. For instance, the LKB (with the ERG's triple-quoted patch) currently accepts these:</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">    a := b & c """doc""".</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">    a := b & """doc""" c.</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">    a := b & c & """doc""" [ Q r ].</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">    a := b & """doc""" c & [ Q r ].</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">    a := b & """doc""" [ Q r ] & c.</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">but not these:</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""> </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">    a := """doc""" b & c.</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">    a := """doc""" b & c & [ Q r ].</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">    a := b & c & [ Q r ] """doc""".<br class=""> </div> <div class=""><br class=""> </div> <div class=""> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Furthermore, it accepts:</div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br class=""> </div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    a := b & c & [ Q r ].</div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    a := b & [ Q r ] & c.</div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br class=""> </div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default">but not:</div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br class=""> </div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    a := [ Q r ] & b & c.</div> <br class=""> </div> <div class=""> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I imagine a grammar developer (who doesn't browse the lisp code) would not find these facts consistent. It should either enforce that all supertypes appear before other terms, or allow them to mix freely.</div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br class=""> </div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default">So, on the one hand, I think that the LKB is currently deficient WRT the above patterns (which are all allowed, according to current consensus). I may take a look at fixing the Lisp code, but it would take me a while. On the other hand, the LKB merely enforces the conventional layout of TDL definitions, so it is unlikely to cause problems for now.</div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br class=""> </div> <div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Finally, docstrings are desired for more than just the ERG, so the temporary solution in patches.lsp should eventually make it into the LKB proper. For instance, the read-tdl-avm-def and read-tdl-conjunction functions would need some changes and the read-tdl-type-parents function should probably just be removed.<br class=""> </div> <br class=""> </div> <div class="gmail_quote"> <div dir="ltr" class="">On Fri, Sep 7, 2018 at 4:58 AM John Carroll <<a href="mailto:J.A.Carroll@sussex.ac.uk" target="_blank" class="">J.A.Carroll@sussex.ac.uk</a>> wrote:<br class=""> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=""> <div style="word-wrap:break-word;line-break:after-white-space" class="">Hi, <div class=""><br class=""> </div> <div class="">I've been looking at TDL reading in the LKB, and (partly for pragmatic reasons) I suggest restricting docstrings to occur only in the position immediately preceding the AVM - or just before the final . terminator if there is no AVM. Here are my reasons:</div> <div class=""><br class=""> </div> <div class="">1. The LKB currently only allows docstrings in that position, and changing this while retaining backward compatibility would require an unreasonable amount of patching in a grammar lkb/patches.lsp file</div> <div class="">2. This position is analogous to where docstrings are allowed in programming languages / docstring packages</div> <div class=""><br class=""> </div> <div class="">In the hope that this is acceptable, at least for the time being, I've sent Dan a new version of his patch to change docstrings from double-quoted to triple double-quoted in the LKB. The patch is attached in case other grammar developers want to pick it up.</div> <div class=""><br class=""> </div> <div class="">John</div> <div class=""><br class=""> <div class=""> <blockquote type="cite" class=""> <div class="">On 7 Sep 2018, at 00:29, <a href="mailto:goodman.m.w@gmail.com" target="_blank" class=""> goodman.m.w@gmail.com</a> wrote:</div> <br class="m_-5771748778099409336m_333016454702567529x_Apple-interchange-newline"> <div class=""> <div dir="ltr" class=""> <div dir="ltr" class=""> <div dir="ltr" class=""> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> Hi all,</div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> <br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> There are some remaining issues with TDL that I'd like to clean up. First I will summarize some decisions made (or at least not rejected) in previous email threads:<br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> <br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> 1. Supertypes appear before other terms in a conjunction only by convention (not enforced in the syntax)<br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> 2. Docstrings are triple-quoted and may appear before any top-level term or before the final . terminator</div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> 3. Comments may appear in definitions anywhere that spaces can, except within strings/regexes/affixing-patterns</div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> <br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> The following changes are things I think people agree with, so I'd like to consider them as decided:<br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> <br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> 4. Removal of the :< operator (if accepted as a variant of :=, throw a warning)</div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> 5. Removal of 'single-quoted-symbols</div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> 6. Removal of double-quoted "docstrings"<br class=""> </div> <div class=""> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> 7. Removal of non-regex uses of ^ (otherwise any BNF of TDL is necessarily incomplete because the "extended-syntax" use of ^ is open-ended)<br class=""> </div> </div> <div class=""><br class=""> </div> <div class=""> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> And there's at least one point I don't think we reached a decision on:</div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> <br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> 8. Instances must have exactly 1 "supertype" (which is really just a type and not a supertype, i.e., it doesn't change the type hierarchy)<br class=""> </div> </div> <div class=""><br class=""> </div> <div class=""> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> Also:</div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> <br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> 9. Does anyone know how wild-cards differ from letter-sets? I see HaG has a wild-card and suffix pattern like these:</div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> <br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif">     %(wild-card (?g ui))</div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif">     ...<br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif">     %suffix (!c!v !c!vn) (!v?g !vn)<br class=""> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> </div> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> My guess is that wild-cards match but are not used in the replacement, which I can imagine is useful if you want the replacement to use the second of two matches but not the first. It makes me wonder why we don't just use regex substitutions for these things.<br class=""> </div> </div> <div class=""><br class=""> </div> <div class=""> <div class="m_-5771748778099409336m_333016454702567529x_" style="font-family:arial,helvetica,sans-serif"> If nobody responds about (1)--(7), I'll make sure the syntax description on the TdlRfc wiki reflects those decisions.</div> <br class=""> </div> -- <br class=""> <div dir="ltr" class="m_-5771748778099409336m_333016454702567529x_gmail_signature"> -Michael Wayne Goodman</div> </div> </div> </div> </div> </blockquote> </div> <br class=""> </div> <div class=""></div> </div> <div style="word-wrap:break-word;line-break:after-white-space" class=""> <div class=""></div> <div class=""><br class=""> </div> </div> </div> </blockquote> </div> <br clear="all" class=""> <br class=""> -- <br class=""> <div dir="ltr" class="m_-5771748778099409336gmail_signature" data-smartmail="gmail_signature"> -Michael Wayne Goodman</div> </div> </blockquote> </div> <br clear="all" class=""> <br class=""> -- <br class=""> <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">-Michael Wayne Goodman</div> </div> </blockquote> </div> <br class=""> </div> </body> </html>