Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#297 Should circular defines be allowed in Expanded-E?

Need_by_1.0
open
5
2006-12-08
2006-07-23
No

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

Discussion

  • 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()

     
    • milestone: 495443 --> Need_by_1.0