Extending macros

[rvirding]

One thing that is difficult and limited with macros as they are today
is trying to explicitly do macro expansion inside a macro. While it is
easy to call the macro expansion functions in lfe_macro there is no
way to access the current macro environment which means you can only
use the built-in predefined macros. A serious limitation. I found this
for myself when trying to write macros for match specifications and
query list comprehensions (which soon both be testable).

I have a suggestion how to solve this. In the macro body there will be
a predefined variable which is bound to the environment, $ENV perhaps,
which can be used when explicitly calling the macro expansion
functions. There is a problem of how to handle this if macrolet is
used in the macro body but it might not be serious. Does anyone use
macrolet? Get rid of macrolet?

This would be implemented by changing the macro function from a
function of one argument to a function of two arguments. It would not
be noticeable when using defmacro, only when using the primitive form
define-macro.

Comments please.

Robert

[Wojciech Kaczmarek]

Hello.

I was using macrolet a lot when I was coding in LFE some macro stuff heavily inspired by the excellent "Let Over Lambda" book. If I decipher my past code & intentions correctly, macrolet was invaluable when writing macros-writing macros; it was cool and it worked. Unfortunately, I don't write such stuff regularly so I can't back up my gut feeling with some more concrete experience of how macrolet can be substituted with something else or not (and if not, why) for such purpose.

One bunch of macros I was just able to resurrect, written for the LFE v0.4 AFAIR, goes like this: 

https://gist.github.com/1098058

at the end there's a macro (test) which shows how all that voodoo constructs can be used ;).

Please note I didn't run it since autumn 2009 so maybe there were more changes in LFE which render it all inoperable. These macros were rather kind of exploratory programming, I was checking what I am able to write & use; I don't have any production code relying on this stuff.

I don't have many occasions to go back to LFE; certainly I plan to finally blend it into my commercial projects but it didn't happen yet. By the way, thank you Robert & all the users for gradually making this excellent project growing and keeping it alive.

Back to your question: I guess the most insightful route would be to go through couple chapters of "Let Over Lambda" [1], where the author is using macrolet quite extensively, and then decide whether such kind of tool is a very desirable thing or rather a rarely used arcane voodoo. I'm thinking of the former, but as I don't use LFE seriously right now and many of you probably do, it doesn't seem right to have my feeling influence your decision.

[1] it is really remarkable book written by skilled hacker and most of its content is freely available on the web.

cheers,

-- wojtek

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To post to this group, send email to lisp-flavo...@googlegroups.com.
To unsubscribe from this group, send email to lisp-flavoured-e...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lisp-flavoured-erlang?hl=en.

[Jonathan Smith]

On Jun 14, 8:21 pm, rvirding <rvird...@gmail.com> wrote:
> One thing that is difficult and limited with macros as they are today
> is trying to explicitly do macro expansion inside a macro. While it is
> easy to call the macro expansion functions in lfe_macro there is no
> way to access the current macro environment which means you can only
> use the built-in predefined macros.

Sorry for the late reply, I missed this message when it first was
posted.

Do you mean, for example, calling a function like 'macroexpand-all'
and expanding all macros and walking the resulting tree? Or do you
mean simply using macros inside the body of other macros? Both can be
problematic IIRC. The second would be very useful.

> A serious limitation. I found this
> for myself when trying to write macros for match specifications and
> query list comprehensions (which soon both be testable).
>
> I have a suggestion how to solve this. In the macro body there will be
> a predefined variable which is bound to the environment, $ENV perhaps,
> which can be used when explicitly calling the macro expansion
> functions. There is a problem of how to handle this if macrolet is
> used in the macro body but it might not be serious. Does anyone use
> macrolet? Get rid of macrolet?
>

The $ENV idea sounds good. Not sure why you would have to remove
macrolet, however. Wouldn't it just be temporarily adding the macro-
function to the $ENV variable? (or it could be done a different way).

It might have to be some sort of specially handled form I suppose.