A stab at the sealer in E

[Ka-Ping Yee]

On Tue, 2 Nov 1999, Mark S. Miller wrote:
> >Notes:
> >     1.  This is personal, but it seems surprising that "==" means
> >         object identity here, and i can imagine a novice asking
> >         "Why can't i get the contents of just any envelope with
> >         envelope getContents([])?"  I'm very hooked on Python's
> >         "is" and "is not" operators.
> 
> You'll have to remind me about Python's equality semantics.  Not knowing
> which is Python's object identity operation, or what the other means, I did
> not get the point of your comment.

Sorry.  I am used to "==" being an "equals" that depends on the
object (as in C++, Python, Perl) and "is" being the same-identity
operator.  You can define a method to implement "==", but you can't
escape "is".  "is" is "is"... if two things are "is", they are one
and the same object.  (Sorry, i'm having perverse fun with grammar
here.)

> You are correct.  The state of documentation on the E language still sucks.

My comment was not intended as direct criticism, just pointing out
places where a little filling in might be good.

> I like the idea of having such a convention.  In fact, I like it a lot!!  My
> immediate reaction is that I hate leading "_" as a convention, but maybe I
> would get used to it.

Not sure.  I guess it is kind of strange-looking, but the idea of
having to capitalize a variable just to make it private seems even
more repulsive, and we don't have any other choices besides _ and
letters...

... for a naming convention anyway.  I suppose one might consider
a declarative notation like

    define private key := ...
    private key := ...

    define secret key := ...
    secret key := ...     # avoids confusion with C++/Java "private"

but that requires more thought on semantics -- is it straightforward
to see what the compiler/interpreter should do?  Hmm.  I guess it
probably is...

Hmm.  Declaration is easier to read than a naming convention,
but a distinctly-named variable is easier to spot buried in
code.  Does the latter concern become less relevant if we can
rely on a compiler to do the check?  Calling things "secret"
has a definite aesthetic appeal to me...

> "[]" evaluates to a ConstList.

Oops, yes, i expected it to be mutable.  More Python heritage
showing... []s are mutable lists, ()s are immutable lists.

> The problem is that the unsealer is giving the alleged envelope the key it
> is supposed to keep secret.  In fact, you could have caught this security
> breach using your own suggested convention!  The line
> "envelope getContents(_key)" visibly passes out a variable that starts with
> an underbar.

Man, i feel *so* stupid.  :)  Of course, you are quite right.

See my other message for a second attempt.



-- ?!ng