Jean Abou Samra <[email protected]> writes: > Le 25 juil. 2022 à 14:51, David Kastrup <[email protected]> a écrit : >> >> syntax-rules/syntax-case introduce a completely new and arbitrary syntax >> intended to be human-readable. That's sort of a counterthesis to the >> LISP philosophy of representing programs by the data representation of >> their parse tree, skipping a human-readable abstraction for the sake of >> making it easy to programmatically generate and analyze programs. >> >> Macros, in contrast, are just a flag on functions telling the evaluator >> "evaluate the function result instead of its arguments". That is an >> almost trivial tweak. > > Modulo the fact that IIRC, Guile 1 would only run the macro the first > time the form was evaluated, but I see what you mean.
I was not really talking about Guile. Guile is a comparatively faithful Scheme implementation. It was more about the LISP/Scheme difference in philosophy. LISP is at its heart, conception and inception an interpreted language. Compilation is an afterthought, just like demand-paging is an afterthought for UNIX, with the original concept having just one process in memory and the difference between swapping and forking essentially being that swapping pulled in a process image before continuing execution and forking just continued running, as "child", the process image it just wrote to disk. The original simplicity that allowed running stuff in 64k of memory or less has not been retained either way. In Guile 1, I've successfully used call/cc for implementing a fairly trivial local-eval that was able to deal with closures. <https://guile-devel.gnu.narkive.com/m42DJSjd/summary-lilypond-lambda-and-local-eval#post4> That doesn't work with the compilation complexity of Guile 2 since this trick obviously falls apart really hard with anything operating in multiple passes. >> More complex, indeed, is the quasiquote mechanism that operates to a >> good degree in the LISP reader and makes it comparatively easy to >> handle the creation of material suitable as macro body. >> >> In contrast to syntax-rules/syntax-case this reflects more a >> philosophy rather than a religion since it isn't arbitrary. Using it >> is more a matter of understanding rather than learning it. > > > There are two mostly unrelated parts in the Scheme macro system that > differentiate it from the traditional Lisp system: the pattern > matching language, and hygiene. Effective hygiene can be achieved with make-symbol. But of course once you stop having an interpreter, the conceptual simplicity is not continued into the implementation, particularly if you want compiled-language efficiency. And Scheme also has thrown the conceptual simplicity overboard along with the simple implementation. > The first part is definitely not all lilies and roses. It’s weird to > have a separate namespace for the pattern variables bound by > syntax-case. It’s weird that the primitive way to analyze syntax > objects is not a set of simple procedures like syntax-pair?, > syntax-car, but only syntax-case pattern matching, against the > traditional Scheme principle that complex tools (like syntax-case) are > built at will on top of very simple tools. It’s weird that syntax > pairs aren’t normal pairs, so you can’t use list functions on them > directly. It’s weird that #'(pat …) doesn’t return a syntax list but > just a plain list (at least in Guile, didn’t check the standard). > > Still, this macro system gives you a form of lexical scoping and > hygiene, and allows things like renaming syntax keywords when > importing them, which is really nifty and the main reason why I prefer > writing syntax-rules/case macros. I like the principle of annotated > symbols containing scope information. It’s not that I’m fond of the > tools provided to manipulate them. I feel similar with regard to C++'s implementation of the template system: the goals are worthwhile and they are accomplished, but the syntax appears foreign to the base language and has been dragged in from elsewhere (in C++'s case, basically from Ada with subsequent cancerous proliferation), at considerable cost that seems like too much of an uncalled-for expense. -- David Kastrup
