@All, thanks for the interesting discussion. Certainly gives me something to chew on.
Re-reading the responses, I see that, while I did sort-of say it, I didn't emphasize the point of this:
I have a PEG-syntax parser written in esrap.
I am binding at least two such parsers as reader-macros (not the normal kind of macro).
The first parser parses PEG syntax and creates an esrap program.
That esrap program, bound as a reader-macro, reads Prolog syntax and returns a bunch of lisp forms to the reader.
I have a file of code that contains both, lisp and Prolog syntax (cl-heredoc to switch between the syntaxes), e.g.
https://github.com/guitarvydas/paraphrase/blob/master/prolog.lisp
The parsers read characters, not forms.
(lisp) #{ prolog(A,B,c) :- p1(A), p2(B,c). } (morelisp)
I am making at least 2 assumptions:
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 :-),
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...)
(I even started fooling around with a Python syntax).
This line of thinking was inspired by the Gambit Scheme talk at ILC2010, where they showed inline infix mathematical expressions.
Thanks for your suggestions.
pt
On Tue, Mar 18, 2014 at 8:54 PM, Paul Tarvydas paultarvydas@gmail.comwrote:
@All, thanks for the interesting discussion. Certainly gives me something to chew on.
Re-reading the responses, I see that, while I did sort-of say it, I didn't emphasize the point of this:
I have a PEG-syntax parser written in esrap.
I am binding at least two such parsers as reader-macros (not the normal kind of macro).
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.
The first parser parses PEG syntax and creates an esrap program.
That esrap program, bound as a reader-macro, reads Prolog syntax and returns a bunch of lisp forms to the reader.
I have a file of code that contains both, lisp and Prolog syntax (cl-heredoc to switch between the syntaxes), e.g.
https://github.com/guitarvydas/paraphrase/blob/master/prolog.lisp
The parsers read characters, not forms.
(lisp) #{ prolog(A,B,c) :- p1(A), p2(B,c). } (morelisp)
I am making at least 2 assumptions:
- 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 :-),
- 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...)
(I even started fooling around with a Python syntax).
This line of thinking was inspired by the Gambit Scheme talk at ILC2010, where they showed inline infix mathematical expressions.
Thanks for your suggestions.
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?
On Tue, Mar 18, 2014 at 4:50 PM, Alessio Stalla alessiostalla@gmail.comwrote:
On Tue, Mar 18, 2014 at 8:54 PM, Paul Tarvydas paultarvydas@gmail.comwrote:
@All, thanks for the interesting discussion. Certainly gives me something to chew on.
Re-reading the responses, I see that, while I did sort-of say it, I didn't emphasize the point of this:
I have a PEG-syntax parser written in esrap.
I am binding at least two such parsers as reader-macros (not the normal kind of macro).
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.
Given that that is all that macros do, methinks that a rather comprehensive commonality.
Even a keyboard macro has no job other than to take a key chord and produce key strokes,
-hp
Kenneth Tilton ken@tiltontec.com writes:
On Tue, Mar 18, 2014 at 4:50 PM, Alessio Stalla < alessiostalla@gmail.com> wrote:
On Tue, Mar 18, 2014 at 8:54 PM, Paul Tarvydas < paultarvydas@gmail.com> wrote: @All, thanks for the interesting discussion. Certainly gives me something to chew on. Re-reading the responses, I see that, while I did sort-of say it, I didn't emphasize the point of this: I have a PEG-syntax parser written in esrap. I am binding at least two such parsers as reader-macros (not the normal kind of macro). 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.
Given that that is all that macros do, methinks that a rather comprehensive commonality.
Even a keyboard macro has no job other than to take a key chord and produce key strokes,
Indeed, MACRO comes from greek meaning BIG, and refers to the fact that a single item is used to represent a (possibly) BIG group of items.
A macro operator is a single operator that gets expanded into a big form (check it out, most lisp macros expand to big forms!).
A macro character, is a single character that gets read into a big sexp.
A keyboard macro, is a single key that gets read as a big sequence of keys.
A compiler macro, is a single function call that gets substituted by a big, inlined and optimized, function call.
It's not the code generation that's the common part in all those macros, it's the small to big expansion that usually occurs.