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

[Kevin Reid]

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