>> But I think the real answer is to get rid of
>> Kernel-E. Instead, in a scope containing x and y,
the expansion from
>> Expanded-E to Kernel-E should expand
>> ["&x" => &x, "&y" => &y]
> What, then, does e`meta.getState()` return?
Currently, expansion (as I
> know it) can be performed without any known lexical
> Changing this should be considered with extreme caution.
> Also, what exactly is 'Expanded-E'?
Expanded-E is the expansion of E performed by the
e`...` quasi-parser. This expansion does indeed need to
be context-independent, as otherwise one could not
compose quasi-literal program fragments. Expanded-E
gets further expanded to Kernel-E prior to evaluation.
This latter expansion could depend on context, as
suggested above. OTOH, if this only remaining case
requiring us to distinguish Expanded-E from Kernel-E,
then it would probably be better to collapse the
Expanded-E vs Kernel-E distinction, and keep the
MetaStateExpr in Kernel-E.
Currently, circular defines are expanded by the e`...`
quasi-parser, but the determination of whether we have
a cycle is exactly the sort of context dependency that
creates quasi-literal composition problems. It is
plausible to me that this may also move to the
Expanded-E to Kernel-E expansion, in order to aid
quasi-literal composition. What other cases are there?