[ThatGeoGuy]

I don't mean to be a pedant, but the author mentions a "syntax for patterns", basically claiming that Lisp doesn't have one. But, isn't syntax-rules (a la scheme) already a form for matching / macro-ing patterns? From my understanding the author seems to want macros that can be specialized for new forms.

I may be confused about what the exact claim is here, but I don't see how this has anything to do with whether or not something is an expression. I don't quite understand how having "not everything is an expression" helps solve this problem.

[rntz]

Author here!

syntax-rules is a form of pattern matching (mentioned in footnote 2). But it's only for matching on syntax, not on ordinary values. I can't write the fibonacci function using syntax-rules.

The idea behind "not everything is an expression" is that ordinary macros only extend the expressions in a language. But languages have more than expressions to them - they also have patterns, and possibly other syntax classes (loop formats, LINQ, monadic do-syntax). I think those syntax classes ought to be macro-extensible as well. That's what I mean when I say that ordinary macros don't acknowledge that not everything is an expression.

It's rather a roundabout way to say it, I guess.

[malisper]

Well iterate[0], which is a lispy version of loop, is actually extendable through macros[1]. So what you are looking for is just a generic way to enable that for all macros? Iterate does it by having a code walker go over the code and macroexpand the extendable parts. It shouldn't be too hard to apply that method to new DSLs by specifying the syntax of the DSL to the code walker.

[0] https://common-lisp.net/project/iterate/

[1] https://common-lisp.net/project/iterate/doc/Rolling-Your-Own...

[rntz]

Yup, I pretty much want it to be trivially easy for define macros that are themselves macro-extensible. It's definitely possible to do this in Lisp, but:

(a) it's not a well-known technique

(b) it's not in the standard library of any Lisp I know of

(c) there are interesting open design questions to be answered in the implementation of such a system

I hope this article will get folks thinking about these issues.

For example, walking the AST and calling macroexpand will work, but then you can't have a macro that expands differently in different contexts - when interpreted as an expression versus as a pattern, for example. I think this is an important feature.

[malisper]

> you can't have a macro that expands differently in different contexts

This[0] may be of some help. You could set it to expand macros differently according to the current context (some global variable).

You could also write your own macroexpand function which would default to the implementation's macroexpand.

This is definitely something interesting to think about. Thank you for the discussion.

[0] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...

[DalekBaldwin]

The macroexpansion hook isn't nearly as powerful or useful as it could be because the process of macroexpansion is not recursive. Although expansion functions can access information about the lexical environment via an &environment parameter, the invocations of those expansion functions do not share any dynamic context with other invocations at nodes above or below them in the syntax tree.

Here's a more thorough summary of the problem: http://qiita.com/guicho271828/items/07ba4ff11bff494dc03f

[malisper]

I managed to get the code from the post you mentioned to work[0] by using macroexpand-dammit[1].

Coincidentally, you have contributed to that, so I thought I would ask you what is the problem with using macroexpand-dammit?

[0] https://gist.github.com/malisper/055848f4e593af5ca1b1

[1] https://github.com/guicho271828/macroexpand-dammit

[arohner]

> The idea behind "not everything is an expression" is that ordinary macros only extend the expressions in a language.

That sounds great, for lisps, when everything is an expression. I feel like you haven't fully embraced lisp, because the article just kind of asserts that not everything is an expression, without justifying it.

In lisp the point of expressions isn't that everything has a return value, the bigger gain is that everything fits together, like legos. One of the big wins is that you can use your same toolkit, functions & macros, on everything. The point of the article seems to desire restricting that.

[kd0amg]

because the article just kind of asserts that not everything is an expression, without justifying it.

Without justifying? The article gives some sample code (in a lisp) colored according to what syntax class each bit of code belongs to. The code is not all red (like it would be if it were only expressions).