[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: macros and macroexpand
From: |
Philip Kaludercic |
Subject: |
Re: macros and macroexpand |
Date: |
Mon, 07 Aug 2023 20:08:29 +0000 |
Heime <heimeborgia@protonmail.com> writes:
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Tuesday, August 8th, 2023 at 2:22 AM, Philip Kaludercic
> <philipk@posteo.net> wrote:
>
>
>> Heime heimeborgia@protonmail.com writes:
>>
>> > Sent with Proton Mail secure email.
>> >
>> > ------- Original Message -------
>> > On Monday, August 7th, 2023 at 11:46 PM, Yuri Khan yuri.v.khan@gmail.com
>> > wrote:
>> >
>> > > On Mon, 7 Aug 2023 at 18:04, Heime heimeborgia@protonmail.com wrote:
>> > >
>> > > > I have made a macro and know that they are supposed to return
>> > > > expanded code for use. Still I cannot understand the need to
>> > > > call "macroexpand". Should't the macro already perform the
>> > > > expansion ?
>> > >
>> > > You should be posting small examples of code that you’re trying,
>> > > otherwise, there is high chance people will either misunderstand you
>> > > or just disregard your questions as ill-posed.
>> > >
>> > > ----
>> > >
>> > > When you define a macro, you indeed write the definition similarly to
>> > > a function that returns expanded code.
>> > >
>> > > (defmacro foo (&rest body)
>> > > `(bar ,@body)) When you evaluate a form that references a macro,
>> > > Elisp will (1) expand the macro, and (2) evaluate the result of
>> > > the expansion: (foo 'quux) ⇒ Debugger entered--Lisp error:
>> > > (void-function bar) On the other hand, calling ‘macroexpand’ on
>> > > a data representation of that form will just return the
>> > > expansion result: (macroexpand '(foo 'quux)) ⇒ (bar 'quux) In
>> > > this example, I did not bother to define ‘bar’, so Elisp assumes
>> > > it would be a function and complains at evaluation time. But I
>> > > could further define ‘bar’ as a macro: (defmacro bar (&rest
>> > > body)` (baz ,@body))
>> > >
>> > > In this case, evaluating the original form shows that Elisp expanded
>> > > both macros ‘foo’ and ‘bar’, and then tried to call the undefined
>> > > function ‘baz’:
>> > >
>> > > (foo 'quux)
>> > > ⇒ Debugger entered--Lisp error: (void-function baz)
>> > >
>> > > Meanwhile, ‘macroexpand’ still just expands a single level of macros:
>> > >
>> > > (macroexpand '(foo 'quux))
>> > > ⇒ (bar 'quux)
>> > >
>> > > and you can invoke it repeatedly until you get to the fixed point:
>> > >
>> > > (macroexpand (macroexpand '(foo 'quux)))
>> > > ⇒ (baz 'quux)
>> > >
>> > > (macroexpand (macroexpand (macroexpand '(foo 'quux))))
>> > > ⇒ (baz 'quux)
>> >
>> > Then macroexpand is useful for diagnostics to expand at one level only
>> > at a time. Thusly, if I just want to get the expanded code produced by
>> > a macro, I can just do pp-to-string upon the object made by a macro.
>> >
>> > (defmacro adder (mopi mopj)
>> > `(+ ,(cl-second mopi) ,(cl-third mopj)))
>> >
>> > (princ (pp-to-string '(adder (* 3 5) (* 5 7)) ))
>>
>> ^
>> don't do this
>>
>> If you quote an expression, it won't be evaluated or macro-expanded any
>> further. You can sort-of think of a macro like a kind of inline
>> function call. The evaluation would go along these lines:
>>
>> (princ (pp-to-string (adder (* 3 5) (* 5 7))))
>>
>> will be transformed into this at macro-expansion time, and evaluation
>> would do this:
>>
>> (princ (pp-to-string (+ (cl-second '(* 3 5)) (cl-third '(* 5 7)))))
>> (princ (pp-to-string (+ 3 7)))
>> (princ (pp-to-string 10))
>> (princ "10\n")
>> "10\n"
>
> What I want to do is print the code made by adder of its final expansion code.
> Rather than the last evaluation of 10, I want to print (+ 3 7).
>
> Can my print command be modified in such a way that the message shows (+ 3 7)
> ?
> IT seems that I would need to use macroexpand-all, to get to the final
> unevaluated
> sexp.
You can modify your macro, to return a quoted expression.
(defmacro adder (mopi mopj)
`'(+ ,(cl-second mopi) ,(cl-third mopj)))
^
note this
This is synonymous with
(defmacro adder (mopi mopj)
(list 'quote (list '+ (cl-second mopi) (cl-third mopj))))
which makes sense, if you keep in mind that the result of evaluating the
macro is what replaces the macro expression in the syntax tree.
>> > I would not do
>> >
>> > (princ (pp-to-string (macroexpand '(adder (* 3 5) (* 5 7))) ))
- macros and macroexpand, Heime, 2023/08/07
- Re: macros and macroexpand, Yuri Khan, 2023/08/07
- Re: macros and macroexpand, Heime, 2023/08/07
- Re: macros and macroexpand, Philip Kaludercic, 2023/08/07
- Re: macros and macroexpand, Heime, 2023/08/07
- Re: macros and macroexpand,
Philip Kaludercic <=
- Re: macros and macroexpand, Heime, 2023/08/07
- Re: macros and macroexpand, Philip Kaludercic, 2023/08/08
- Re: macros and macroexpand, Emanuel Berg, 2023/08/08
- Re: macros and macroexpand, Heime, 2023/08/08
RE: [External] : macros and macroexpand, Drew Adams, 2023/08/07
Re: macros and macroexpand, Emanuel Berg, 2023/08/08