Why is quasiquote so complicated? about mal HOT 3 OPEN

Hello.

I have made the same suggestion in #384. The issue is long, here is the specific quote:
I agree that it is a bit more readable and is almost certainly more efficient. The main problem with this is that it is quite different from how most (maybe all) other implementations and also different from the pseudo-code in the guide. If you want to go this path, then I would want to see the guide and other implementations changed to match. If you go that route just be cognizant of the impact this may have on implementations that do their own GC/ref counting since any functions that take an environment and/or call EVAL tend to have GC/ref count subtleties that need to be taken into account.
In a follow-up discussion that I cannot find anymore right now, kanaka also explains that the intent is to teach LISP, and that quasiquote is a pure rewrite-before-eval process in most (maybe all) implementations. Performance or minimalism are not priorities.
Most MAL implementations use the same structure for lists and vectors, which would make little sense for a real language.

Ideally, this choice for quasiquote should be documented more explicitly in the process guide...

from mal.

"different from most implementations". That is a strange remark to make as the MAL goal is to stimulate the independant development from specification in an idiomatic way, depending on the language. Pseudo code in the guide should merely be a proposal, and not force an implementation. My conclusion is that the pseudo code is handy for lisp, where you can cut a list easily between a first element and the remainder, and not at all handy for other languages. Could I trust my interpretation of the specification, quasiquote c.s. cost me 4 lines of code instead of 40.

from mal.

My answer was unclear.
Kanaka wants quasiquote as a macro because it is representative of existing implementations of actual LISP variants*, hence part of the specification/purpose of the MAL project.
A divergence between most MAL implementations and the MAL pseudo code is less important, but implies a learning cost for new implementors and a maintenance cost for him.
do results from a similar compromise. It could be implemented with fn* and if.

from mal.