Some thoughts on the 'reveal' operator

[Marc Stiegler]

Having thought about this more than it probably deserves in the last few
days, doug's Mesa approach and my earlier

def method() reveals result{}

suggestion have really grown on me as the types of variations that I like
for E (and shares the properties I like with the Joule solution, which seems
not directly applicable in E syntax):

The thing I really like about declaring returned values in the definition
line is that it reduces the cost of the security audit. In versions of
revelation wherein the the revelation declaration occurs in the middle of
the method somewhere (often in several different somewheres!) the security
auditor must inspect the entire method body just to determine whether there
is a security question to address; in the current form, auditors also have
to discriminate reveal operators that are at the outermost scope from inner
scope reveals.

If revelation is declared in the definition line, when the auditor comes to
the method he can often determine at a glance that there is no question
about revelation. Of course, if there is a revelation, the auditor still has
to go through the whole method to see all the variations the revelation
might experience.

On the one hand, easily spotting non-revealing methods as an audit cost
reduction measure is a drop in the bucket; thousands of cost reductions of
this size would be needed to make security audits not-cost-prohibitive. On
the other hand, it is a start :-)

--marcs

-----Original Message-----
From: Douglas Crockford <crock@communities.com>
To: Marc Stiegler <marcs@skyhunter.com>; Chip Morningstar
<chip@communities.com>; e-lang@eros-os.org <e-lang@eros-os.org>
Date: Wednesday, September 29, 1999 1:29 PM
Subject: Re: Some thoughts on the 'reveal' operator


>Mesa had a construct that might be useful here: named return parameters.
>
>A procedure definition could look something like
>
>        foo: PROCEDURE (arg ...) RETURNS (result)
>
>result looked just like a local variable, except that it would be passed
>back to the caller when the procedure returned. I especially liked that
>there could be more than one return parameter,
>
>        swap: PROCEDURE (argOne, argTwo) RETURNS (resultOne, resultTwo) {
>                    resultOne := argTwo;
>                    resultTwo := argOne;
>        }
>
>        a, b := swap (a, b);
>
>