#297 Should circular defines be allowed in Expanded-E?
>> But I think the real answer is to get rid of
meta.getState() from
>> Kernel-E. Instead, in a scope containing x and y,
the expansion from
>> Expanded-E to Kernel-E should expand
>>
>> meta.getState()
>>
>> to
>>
>> ["&x" => &x, "&y" => &y]
>
> What, then, does e`meta.getState()` return?
Currently, expansion (as I
> know it) can be performed without any known lexical
environment.
> 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?
Logged In: YES
user_id=54168
See
http://www.eros-os.org/pipermail/e-lang/2006-February/011133.html
Also:
>> Currently, a cycle containing a meta.getState() on the
right is not
>> handled correctly, and it is hard to see how it could be.
>>
>> What does E-on-CL currently do on this case?
>
> E-on-CL currently uses E-on-Java's expander, from
necessity (and the
> ANTLR branch, while it implements expansion itself, is not
specifically
> different), so it is treated identically:
>
> e-on-cl? thunk { def x := meta.getState() } ()
> # value: [].asMap()