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

[Kevin Reid]

On Oct 16, 2006, at 2:01, Dean Tribble wrote:
> On 10/15/06, Kevin Reid <kpreid at mac.com> wrote:
>> 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.
...
> 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.

A principle which accounts for both of these is that anything between  
the 'def' and the method bodies --

   def foo extends bar implements baz { to run(arg :guard) :int  
{ return 99 } }
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

is public. This would not quite be true, as 'baz' is not exposed  
except by __auditedBy, i.e. you can only tell if you already have  
baz, but it's close.

If the programmer wishes to hide a powerful guard, or a more specific  
guard, they can re-coerce inside the body:

   def f(box :Box) {
     def thing :Unseal := box
   }

Now, revealing guards is slightly more failure-prone, in that the  
programmer might not realize that they are revealed. However, there  
is much value in an object's protocol displaying the guards, and I  
feel this is more important. We can always include warnings in E-in-a- 
Walnut (etc.) when we introduce the concept of patterns/guards as  
parameters.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>