<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 18, 2014 at 8:54 PM, Paul Tarvydas <span dir="ltr"><<a href="mailto:paultarvydas@gmail.com" target="_blank">paultarvydas@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">@All, thanks for the interesting discussion.  Certainly gives me something to chew on.<br>
<br>
Re-reading the responses, I see that, while I did sort-of say it, I didn't emphasize the point of this:<br>
<br>
I have a PEG-syntax parser written in esrap.<br>
<br>
I am binding at least two such parsers as reader-macros (not the normal kind of macro).<br></blockquote><div><br></div><div>I always thought that reader macros should be called a different name, because they are not macros. Yes, they produce code; but that's the only point they have in common with macros. The two should not be confused.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The first parser parses PEG syntax and creates an esrap program.<br>
<br>
That esrap program, bound as a reader-macro, reads Prolog syntax and returns a bunch of lisp forms to the reader.<br>
<br>
I have a file of code that contains both, lisp and Prolog syntax (cl-heredoc to switch between the syntaxes), e.g.<br>
<br>
<a href="https://github.com/guitarvydas/paraphrase/blob/master/prolog.lisp" target="_blank">https://github.com/<u></u>guitarvydas/paraphrase/blob/<u></u>master/prolog.lisp</a><br>
<br>
The parsers read characters, not forms.<br>
<br>
(lisp)<br>
#{ prolog(A,B,c) :- p1(A), p2(B,c). }<br>
(morelisp)<br>
<br>
I am making at least 2 assumptions:<br>
<br>
1. That using different name spaces for the various parsers will help me preserve my sanity, (regression testing the PEG parser using itself brings me to the limits of my comprehension :-),<br>
<br>
2. That a reader macro must return a single form.  I actually want to return a separate 'defun' for every prolog rule in the file. (Writing this, just now, makes me ask myself why I don't just put #{ ... } around every separate rule...)<br>


<br>
(I even started fooling around with a Python syntax).<br>
<br>
This line of thinking was inspired by the Gambit Scheme talk at ILC2010, where they showed inline infix mathematical expressions.<br>
<br>
Thanks for your suggestions.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Your assumptions are sane. You only have to understand in which phase - read-time, compile-time, run-time - each piece of your code happens to run. Your reader macros generate Lisp code (defun forms), right? Where do the symbols that constitute those forms come from? Let me guess... I bet some come from the source code of the reader macro itself - e.g., the symbol CL:DEFUN. I bet others come from calls you make to the function intern or find-symbol. Am I right? If so, ask yourself: which package is effective at the time you call intern/find-symbol? Can you change it to another one? What happens if you do so?<br>

</div></div></div></div>