Re: A thought experiment: Minimal-E
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
On 7/2/06, Kevin Reid <kpreid@...> wrote:
> a := b