Re^4: Amicable divorce (Macros)

> Arguably, Common Lisp macros are a preprocessor, itself written in Lisp; consider the MACROEXPAND and MACROEXPAND-1 builtins from this perspective

Nope. Syntactic macros are lightyears ahead of preprocessor stuff.

Source filters are fancy preprocessors and failed to deliver because they require an extra parsing phase and understanding of the grammar at a distance.

Lisp macros look like functions but expand in the very same parsing phase, no confusion here. Eg a macro in a comment will never be expandend!

And they get their arguments as code before it's evaluated and can reconfigure it. Eg a deeply nested peace of syntax.

That's incredibly powerful.

Switch.pm (and so many things more) as syntactic macro would actually really work.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

Comment on Re^4: Amicable divorce (Macros)

Replies are listed 'Best First'.
Re^5: Amicable divorce by jcb (Parson) on Jul 17, 2020 at 04:28 UTC
To me, the only difference is that the Lisp macro facility does not actually print its result for the next stage to read back in, but it could do that and still work. The difference from a preprocessor seems to me to be an implementation detail. I am currently up late drafting a Meditation on the broader topic. I hope to have it posted soon.	[reply]
Re^6: Amicable divorce by salva (Canon) on Jul 17, 2020 at 08:13 UTC
That is the same as saying that all programming languages are equal because they are Turing complete. Common Lisp macro facility is far more than a preprocessor. It allows manipulation of the language AST using the full language and the mechanic is perfectly ingrained into it. That allows the programmer to create new abstractions, domain specific languages, or to add support for new programming paradigms (as for instance, logic programming or as suggested by LanX, alternative OO systems).	[reply]
Re^7: Amicable divorce (Macros & AST) by LanX (Saint) on Jul 18, 2020 at 14:46 UTC
> It allows manipulation of the language AST using the full language and the mechanic is perfectly ingrained into it. ~~`perlcompile` lists~~ perlcompile listed so many backends to analyze the op-tree. It's unfortunate that there is no mechanism to preserve the original code-snippets in these tree nodes. FWIW one can (ab)use `use` as a macro mechanism, you might be interested in my talk about Fun with Macros Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^6: Amicable divorce by LanX (Saint) on Jul 17, 2020 at 04:52 UTC
That's like carriage vs rocket. The preprocessor struggles to parse the code. The only thing you can statically parse in Perl is POD.° But the lisp macro gets the code (or rather AST) for free. No confusion where it begins or ends and about the elements in between. When OOP became popular, various lisp dialects just added some macros for implemention. Backwards compatibility included. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery} °) well as POD, you can't make it to code. Mind you: POD inside a here doc is both string code and extractable comment.	[reply]