[E-Lang] Authority -- what is its dual?

[Marc Stiegler]

>From: "Jonathan S. Shapiro" <shap@eros-os.org>

> MarkM and I just got off the phone and a lengthy conversation. I'm writing
> to summarize the conclusion.
>
> First, we both agree that immutable things can carry authority. To say
that
> these things carry no authority is simply not right. The real question
here
> is not "What are authorities?" but rather "What authorities should be
> permitted in the universal environment?"
>
> What we are trying to capture here is the idea of transitive immutability.
> This is what we need a term for. MarkM also wants a term for single-level
> immutability.

Actually, that is not the only idea we are trying to capture, as discussed
at the end of this message.

I myself just got off of a lengthy phone call with markm, since I was
seriously disturbed by where this thread more or less ended; I myself have
no sense of closure, or having answered mark seaborn's original question
successfully. The answer does live in the thread, but is obscured (at least
for me) by the discussion. Also, I have a pedagogical requirement upon which
the above "everything is an authority" definition leaves me zapped.

So, in a summary answer to Mark Seaborn, here are some statements I now
think are true:

1) Walnut says, "Only immutables that encapsulate no authority actually move
across computational
boundaries''. This is wrong, and will be changed in a future release of
Walnut to say something like, "Only transparent immutables (that don't
encapsulate anything) actually move across computational
boundaries''.

2) I had hoped to let Walnut slide through the world without defining the
term, "authority", and letting folks' intuition be good enough to get them
through the opening days of programming. Perhaps, if Walnut were able to
serve only its intended audience of beginning E programmers with no
background who just want to get some software going, this would have worked.
However, Walnut is stressed by the fact that, as the only extensive work on
E available at the moment, it must serve more purposes (such as answer mark
seaborn, who doesn't fit my audience definition because he is too advanced
for it :-) So I can't totally dodge the question , but I must mostly dodge
the question (for the sake of the intended audience). All of which is leadup
to the hard problem I have:

Walnut also says, "it only imports those parts of the Java API that have
been audited for capability security and found to convey no authority" and
"the Vector class conveys no authority''. This could be corrected by
replacing "conveys no authority" with "is deep frozen". However, though the
resulting sentences would be correct, they would be non-motivating: what is
so special about deep frozen stuff that it is allowed and nothing else is?
The reason has to do with security, somehow: though deep frozen stuff may be
conveying authority by someone's elegant formal definition, in fact the
authority being conveyed is somehow weak enough/unimportant enough/ to be
granted to every silly goose of a library package that shows up, no matter
how badly written or maliciously intended.

For Walnut, I need a term that will clearly convey the idea that this is a
security issue, that I don't need to take a page defining, that doesn't
sound like an acronym invented by NASA, that is the term that means, "all
the stuff that is not deep frozen".

I am open to suggestions for what this term should be. Unless and until a
term is identified that works well for this purpose, my plan for the next
version of Walnut is this: I will explain that I am going to use a formally
incorrect definition, and define the concept of "conveying authority" to
mean "not deep frozen", and continue to use the term "authority", and put in
a link to something that does a proper job of defining the proper meaning of
proper authority (Jonathan, do you have a proposal for the link?).

I fear the deep thinkers about capabilities and authorities will find it
distressing if no alternative is found. But one way or the other, Walnut
must have a term, not a term paper :-)

--marcs