monads, modules, sandboxes

[Richard Uhtenwoldt]

Daniel Crealer writes:

>I came across interesting concept of monad, and that is
>what inspired the following idea.  I would just like to know if anyone 
>thinks it's interesting and if someone has already developed it.

Yes it is interesting, and the fact that you thought of it might mean
you have valuable "insight skills" in computing.  Similar ideas are
already in circulation --since the 70s in the research OS community in
fact-- but dressed not in the guise of the monad but rather in the
guise of something called a capability as in "capability OSes" like
GNOSSIS, KeyKOS, Extremely-Reliable OS, etc, or "capability PLs" like
Hewitt's Actors framework, Joule, Mozart/Oz, E and --lately-- dozens
of others.

A capability is essentially a pointer that is unforgeable because of
care taken in implementing the OS or the language runtime.  Note that
there is something in Unix called a capability which is not a "real"
capability and which you can safely ignore.

>                                                  I download a program
>off the Internet that claims to do some interesting transformation on
>my data.  But I don't trust the application not to send my secret data
>back to the web site.  I could achieve this by running the program in a 
>sandbox that doesn't allow it to send data over the Internet.  But maybe the 
>program has legitimate reasons to send data, e.g., the company charges based 
>on how much data I transform, so the program wants to periodically send 
>messages to the web site saying it performed some units of work.

This is a standard application of capabilities; the downloaded program
is said to be "confined" by the local OS or runtime.  

Unfortunately I am unwilling at this time to learn enough Caml to
decipher your pseudo-Caml.  If you learn enough Haskell to rewrite
it in Haskell I'll take a look.

The reason capabilities can do such things as confinement is that they
are "totalitarian" in the sense that going through a capability is the
*only* way for the programmer to access or consume some interesting
set of resources.  (In fact, capability OSes and runtimes are
carefully audited by security engineers to ensure that property.)

Like capabilities, monads can easily be made "totalitarian".  In fact,
modulo functions with "unsafe" in their name and modulo (the kludge
of) semi-closed handles and modulo unintentional "security holes" and
modulo maybe one or two other warts I'm not recalling right now,
Haskell and GHC's IO monad already is "totalitarian" with respect to
most side effects, eg, almost all I/O.

While many have suspected a similarity between monads and
capabilities, no one to my knowledge has worked out even in principle
how to do security engineering of software with monads (so we could be
wrong about the similarity).  I am uninterested in following up on
this similarity, and most capability experts prefer dynamically typed
OOPLs in the Smalltalk tradition though in the past a language in the
Prolog tradition was used.

It is easy to get the impression that OOP is sort of stupid.  That's
what I thought till I discovered capability PLs.  I now think the body
of ideas around capability PLs (again mostly dynamically-typed OOPLs
these days) is likely to be richer and more scientifically fertile for
the long term than FP even.  Right now, mostly only security engineers
know about it as it is the technically superior way to construct
"unhackable" software, but it deserves more attention from
computer science researchers.

I'm concentrating on on FP for essentially social and economic
reasons, not technical superiority to the capability-PL approach.  by
"social" reason I mean mainly that it is easier to spot (and ignore!)
the low-IQ programmers on FP mailing lists whereas on, eg, the average
OOP mailing list or newsgroup the low-IQ folks waste a lot of your
time.  (But the E mailing list mentioned below has a very very bright
membership.)

A point of intersection between capability PLs and FPLs is that both
have been used to formalize financial contracts.

Also, E is the only language I know of besides the FPLs where the
standard variable-binding construct, namely def foo := bar, introduces
an "immutable" variable, namely foo.  An "immutable" variable is one
that cannot later be assigned a different value.  even in the
almost-functional language Scheme the variable, namely foo, bound by
the standard variable-binding construct, namely (let ((foo bar))
body), can be mutated, namely by (set! foo bar2), and Scheme has no
alternative to the let special form that can produce an immutable
variable.  (In E, there's another construct, namely var foo := bar,
that will introduce a mutable variable.)

The motivation for E's offering immutable variables is not the
standard FP motivation of referential transparency but rather the
observation that they make it easier for the programmer to avoid
the unintentional creation of certain classes of security holes.

The best place on the 'Net to learn about capabilities is on the
mailing list (which is at least twice as busy as the Haskell mailing
list BTW) for the E programming language at
http://www.eros-os.org/pipermail/e-lang/.

If you post to this mailing list, please tell them I sent you!  I
participated on this list till earlier this month.

Finally, my favorite intros to capability thinking are:
<LI><a href="http://mumble.net/jar/pubs/secureos/">Rees's 1995 paper "Security Kernel"</a>
<LI><a href="http://www.sims.berkeley.edu/~ping/sid/ideus.html#design">Design of a Secure Desktop Interface, chapter 5 of Ping's draft paper.</a>

-- 
Richard Uhtenwoldt
"It's a mammal thing; you wouldn't understand."