[e-lang] Returning guards from __getAllegedType: opinions needed

[Dean Tribble]

An interesting problem. I will try to articulate a few concerns with this,
which might help narrow the choice:

1) In OCaml and related languages with type inference, the program/module
can specify a type which is different (though related) than the inferenced
one.  Guards are operational (have effects within the program) and therefore
may be narrower in some dimension than the programmer would like to reveal.

2) For closely held guards, it's a question of what information or what
authority is by default reveled to the client.  In particular, if I have a
guard which is an unsealer, for example, does the protocol disclose the
unsealer?

I am OK with evaluating the guards at arbitrary times if we can make it make
sense :).  Thus, 1 seems plausible except for the above issues.

On 10/15/06, Kevin Reid <kpreid at mac.com> wrote:
>
> MarkM and I agree that it'd be better if the alleged type of an E
> object included any guards on its methods' parameters. However, the
> guards are specified as expressions evaluated at method invocation,
> so they may vary and are not automatically closed over.
>
> What's the best behavior?
>
> These are the options I have thought of so far; see the end of the
> message for my preference.
>
>
> 1. When __getAllegedType is invoked, evaluate all the guard
> expressions except for those which depend on the results of pattern
> matches.
>
> This is straightforwardly computable with static scope information,
> but means that miranda __getAllegedType may have side effects;
> particularly, the guard expressions would be evaluated at times the
> programmer might not have thought of.
>
>
> 2. As #1, but evaluate only guard expressions which are marked (or
> not marked) with some new keyword or symbol (e.g. 'public').
>
>
> 3a. As #1, but evaluate only expressions which are proven to have no
> side effects.
>
> This is straightforward to implement well enough: test whether the
> slots referred to by the expression are all DeepFrozen. The
> DeepFrozen auditor itself in E-on-CL does essentially the same thing.
>
> This would be promoting DeepFrozen to Kernel-E evaluator behavior
> (but then, so would the planned 'all guards are DeepFrozen' rule).
>
> A simpler test (which does not work for parameterized guards) would
> be whether a guard expression is a NounExpr whose slot is a FinalSlot.
>
>
> 3b. Same as #3a, but evaluate the expressions when the ObjectExpr is
> evaluated. This would avoid repeated work by __getAllegedType and
> make its output constant, but slow down object creation (outside of
> the Sufficiently Smart Compiler).
>
>
> 4. Evaluate those which meet the condition in #3 or have the keyword
> from #2.
>
>
> 5. Return pseudo-guard objects which you can't coerce with, but print
> as the guard expression.
>
> This is what E-on-CL currently does - useful only for documentation.
> It has the advantage of not depending on run-time values.
>
>
> 6. Return no guards.
>
> This is what E-on-Java currently does.
>
>
> At the moment, I like option #1. I argue that the side effects are
> not a problem, because if a guard expression has (significant) side
> effects, that's bad in itself; as a programmer, you shouldn't be
> doing it, and as an adversarial code reviewer, you should have
> already rejected it.
>
> --
> Kevin Reid                            <http://homepage.mac.com/kpreid/>
>
>
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20061015/781a0cf7/attachment.html