[E-Lang] pending revision of E in a Walnut

[Paul Snively]

on 8/21/01 11:10 AM, Marc Stiegler at marcs@skyhunter.com wrote:

> I have just started a major pass over E in a Walnut. So anyone who has
> comments on the book that they'd like to see incorporated in this pass,
> please feel free to send them to me sooner rather than later :-)

Since we're on the subject, something that came up on Wes Felter's weblog
has been bothering me ever since, particularly since you (MarcS) have
commented before on the primary learning curve for E newbies with respect to
designing for security vs. simply good object-oriented design being the
amount of "ambient authority" that developers tend to find in other
environments, and hence assume also exists in E.

I see a similar issue with E, and it appears explicitly in "E in a Walnut."
My initial raising of the issue is at
<http://wmf.editthispage.com/discuss/msgReader$4994?mode=day>. Dan Moniz has
responded to it, and also to a post from Jonathan Rees that essentially
re-raises the issue.

One thought that occurs to me is that E falls into the trap of not having a
functional REPL (read-eval-print loop, for those not in the Lisp tradition).
Of course, so do most Lisps. :-) The Programming Language Theory group in
the Computer Science department at Rice University encountered this issue in
a pedagogical setting and solved it in their DrScheme system
<http://www.cs.rice.edu/CS/PLT/packages/drscheme/>, implementing a
functional REPL for DrScheme.

Dan Moniz and I have the intuition, and Jonathan Rees seems to be leaning
toward it as well, that I/O is an area where there tends to be ambient
authority, as typified by the "println" example from "E in a Walnut." It
relates to the question of where any given process' initial capabilities
come from in a pure capability system, and I believe has its best resolution
by somehow reifying monads as capabilities (or capabilities as monads; I'm
not sure which direction makes the most sense).

If we're contemplating how best to revise "E in a Walnut," and "E in a
Walnut" is intended to be a good pedagogical tool, particularly with respect
to demonstrating how to design for security up front, then "Hello World in
E" would seem to be able to benefit from some strengthening. I propose that
the superficially simple-seeming issue is in fact rather complex when
generalized, and suggests that my idle question about capabilities and
monads turns out not only to have not been so idle, but is perhaps the only
way (that I can see, at any rate) to uniformly and comprehensively address
I/O in a pure capability system.

Now, of course, I realize that a great deal of attention has been given
precisely to I/O in E. :-) So let me pose a question: in the "Hello World in
E" example, where does the capability to send output, presumably to some
default device, and presumably granted to the object that "println" is
implemented on, come from, and how does the user typing come to have the
capability/object that implements "println?" It may very well be that E
routinely relies on things that category theorists would recognize as
"monads" even if I myself do not at first blush.

> 
> --marcs

Thanks and apologies for the rambling,
Paul