On 10/4/06, Kevin Reid <kpreid at mac.com> wrote:
> On Oct 4, 2006, at 12:24, Mark Miller wrote:
> > def x implements ..., PassByCopy, ... {
> > to __optUncall() {
> > return [__eval, "run", [meta.context().getSource(),
> > meta.getState()]]
> > }
> > ...
> > }
>> I am quite aware of this intent, and I do not see how my proposal
> prevents it. The bindings used by the auditor exprs would be included
> in meta.getState().
> When I say hidden, I mean in the sense of a HideExpr; the bindings
> *made* by the auditor exprs would not be visible to the script.
I had indeed misunderstood what you meant by "hidden". I thought you
were suggesting that the auditorExprs are as-if removed from the
object as considered from the perspective of meta.getState() (and
perhaps of meta.context().getSource() as well). This stance would be
consistent but unpleasant: the object would unserialize as an object
with corresponding state and behavior, but lacking corresponding
certifications. In any case, I'm glad to see that we've actually
arrived at similar proposals.
> > A draconian by simple way to avoid the scope confusion issues you
> > raise is to outlaw them: We could say that none of the auditorExprs
> > may shadow any variable
> > used freely by any previous occurrence in the same implements list.
>> I don't see how this is necessary or relevant. The auditorExprs
> together are scoped like an argument list/sequence, so any bindings
> made by them are internal and do not need to appear in meta.getState().
You're correct -- the above restriction isn't relevant. I withdraw it.
> > Further, if necessary, we could say that the object itself may not
> > use freely any variable defined by any of the auditorExprs, and
> > that therefore meta.getState() must contain all the object's
> > instance variables.
>> I agree that this would also be a solution to the original problem.
>> It would be equivalent to state that auditor exprs are hidden, and
> furthermore that their names may not /appear/ to be reused, much as
> we do in cases of apparently reversed scoping (e.g. 'for'). This
> seems cleaner to me at the moment, because the semantics minus
> "confusing scope restrictions" then do not have the original problem.
Yes, this is equivalent. I have no opinion as to which is more easily
understood, and so am happy with this way of explaining the
restriction. Any objections to this proposed restriction?
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM