AssignExpr
a := b
def r__1 := b; &a.setValue(r__1); r__1
CallExpr is in Minimal-E.
CatchExpr
try { a } catch b { c }
__Mcatch(fn { a }, fn b { c })
CdrPattern
[a] + b
via (__Mcdr(1)) [a, b]
DefineExpr, EMatcher, EMethod, EScript are in Minimal-E.
EscapeExpr
escape a { b } catch c { d }
__Mescape("a", fn a { b }, fn c { d })
FinalPattern
a
via (__Mfinal) &a
FinallyExpr
(Continue reading)
I like this notion of defining a Minimal-E, as a way of defining much of the semantics of Kernel-E in terms of further expansions. Do you suggest any operational role for Minimal-E (as opposed to Kernel-E)? Since reflection (e.g., by audting or 'meta.context().getSource()') does reveal the expansion to Kernel-E, these equivalences, and any others, are only "operationally equivalent up to reflection". I have seen some other language use similar weasel words for the same reason. Further, many of these expansions break a single object up into several objects, e.g., by repackaging an internal block as a closure. This changes the semantics of constructs that are sensitive to the placement of object boundaries, such as the 'meta...' expressions, as well as garbage collection obligations: In a given computational state, what is considered reachable? If we consider weak pointers to be a kind of reflective operation, we can include all these within the same weasel words "operationally equivalent up to reflection". One possible operational use I can see is for an auditor to first expand its ObjectExpr to Minimal-E to reduce the number of cases it needs to care about. Even though this might transform nested ObjectExprs in such a way that they would no longer pass their auditors, this auditor needn't care about that, since those other auditors will only see the un-transformed versions of their ObjectExprs. On 7/2/06, Kevin Reid <kpreid@...> wrote: > AssignExpr > > a := b(Continue reading)
On Jul 5, 2006, at 20:29, Mark Miller wrote: > I like this notion of defining a Minimal-E, as a way of defining > much of the semantics of Kernel-E in terms of further expansions. > Do you suggest any operational role for Minimal-E (as opposed to > Kernel-E)? Not at the moment. > Since reflection (e.g., by audting or 'meta.context().getSource()') > does reveal the expansion to Kernel-E, these equivalences, and any > others, are only "operationally equivalent up to reflection". ... > Further, many of these expansions break a single object up into > several objects, e.g., by repackaging an internal block as a > closure. This changes the semantics of constructs that are > sensitive to the placement of object boundaries, ... I agree. This 'Minimal-E' is not intended to be suitable for expansion of Kernel-E; merely demonstrates equal expressiveness. > One possible operational use I can see is for an auditor to first > expand its ObjectExpr to Minimal-E to reduce the number of cases it > needs to care about. Interesting idea. Perhaps a Minimal-E transformer should be written; it would somehow include notes about the above reflective shortcomings. > Neither Kevin's __Mcatch nor the attached __try can itself be > implemented in Minimal-E. In order for try-catch to not be a > special form in Minimal-E, either __Mcatch or __try would need to(Continue reading)
RSS Feed