Why is quasiquote so complicated?

[albertvanderhorst]

I would specify the quasiquote as follows:

For each item in a list:
- append the item to a news list unless:
-- It is an unquote list. Evaluate the list item first before appending it
-- It is a splice-unquote list. Instead of appending the list, append the items in the list in sequence.

The evaluation is not ambiguous, assuming quasiquote is not supposed to change the environment.
If the items do that as a side effect, I'm totally lost, especially if they are calculated from behind.

This is trivial to implement to the manipulation compared to with cons and concat. What am I missing here?
List and vectors in my implementation are consequitive, not linked. So each times rest is called I'm obliged to allocate a fresh area and copy the whole bunch. If the specification in terms of the classic cons has to do with ease of implementation?

[asarhaddon]

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...

[albertvanderhorst]

"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.

[asarhaddon]

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.