[E-Lang] Springtime musings...

[Dan Moniz]

Hi everyone,

I'm attempting, in the next few days, to go through all my current mail and
get around to being somewhat regular on all the critical lists I subscribe
to. As a result of this, I've been making various dents in the 960 or so
unread messages in my mail client's e-lang folder (down to 833 at the time
of writing).

The purpose of this mail, if it can be said to posses one, is just to throw
out some ideas (and not a whole lot more than that, indeed, if there is any
substance to the following, it's mostly by a serendipitous conjunction of
thought and a random amount of follow-through, itself almost certain to be
of low quality) and receive some feedback in return.

Note that this is not normally my mode: I'd be much more enthusiastic if I
had an up-to-date state of affairs of various e-lang topics, but I think
that the clean up on old messages may take far longer than anticipated, and
I'd rather talk about these things now (I'm impatient, and I apologize). I
may cover some things which have already been discussed and decided, and if
so, I apologize up front for the overlap.

As for slant, I don't think I have a lot to offer, at the moment, in the
discussions on syntax (itself seemingly mostly resolved with "deprecated",
"pocket", and various other constructs now in the language roadmap). Those
of you who know I advocated the dot syntax, take heart: I still do, but
MarkM had a compelling argument in that it would break all existing code.
Perhaps there is some mutually acceptable solution that will present itself
sometime in the future. Instead, most of the following is centered on more
blue sky ideas, many which may only become relevant when E reaches a state
that is more complete than the current incarnation (but perhaps not, and if
not, great!).

And so, without further ado,

Some time ago, I was mentioning, broadly, the idea of Design by Contract in
E. I didn't do much more than ask if Design by Contract was doable, in some
sense, in E (to which MarkM replied to, and justified that yes, you can, of
a sort, in a great outline) and then to postulate that if it was, would it
be possible to implement a sort of mobile code/auto-generation of code using
E, Smart Contracts, and Design by Contract (recognizing the namespace
collision in "Contract" inherent in both terms). MarkM was basically of the
mind that, yes, there's some similarity in both abstract concepts that may
or may not work together, but any practical use, let alone the work involved
in constructing the framework to realize any practical use, was pretty far
off the toughness scale.

With all that workup, you may be thinking I have something. I don't. At
least, not for now.

But, to flesh it out a bit more, what I was looking at was more or less the
synthesis of two related concepts that differ in implementation. Briefly:

0.

1. Smart Contracts express a secure transaction process, based on secure,
distributed capabilities.

2. Design by Contract expresses a robust process of constructing code

I'm also be willing to go out on a limb and say that, depending on toolset,
Design by Contract also supports a corresponding compilation/execution model
of code (i.e. code that will only compile when it's components adhere to the
contracts stipulated).

So, from there:

0.

1. I write a E program that constructs "quux" objects. The purpose of any
given quux object is to self-replicate the code that created it (the quux
object) once and only once. I do so in a manner which utilizes a complete
Design by Contract framework (which is somewhat fictional in E as it stands,
although as MarkM pointed out in his reply to my original message, E's
Design by Contract conceptual support in it's syntax is pretty good).

2. I use my fictional "E with Design by Contract (DbC) support" compiler,
"DeBaClE", to compile said program, "quux-maker.dce" (.dce meaning Design by
Contract E, a special E variant used in DeBaClE -- I had designs to use
.deb, but it's used by the Debian Linux project as a package format, and I
wanted to distinguish this fictional code from E). Assuming I've followed
all my rules inside of the code, and have written sane contracts, the code
compiles and leaves me with an executable.

3. I run the executable simply as "quux-maker.exe", for instance, and I am
returned a log of internal execution process (for debugging) and output
consisting of a running process (Vat -- I'm assuming one Vat per process)
with one quux object in it. The quux object has only one method, which is
"replicate", and when used, it returns the code used by quux-maker to
construct a quux object.

Note that in this case, code can refer to many things depending on
implementation -- a simple print of the relevant source code that is inside
the source of quux-maker.dce itself, for instance. I find it more
interesting to use bytecode of a VM. We'll assume that DeBaClE is hosted
atop of Java and that we have a working E/DeBaClE to JVM bytecode compiler
(more on that in a bit).

4. After returning this code, the quux object may either destroy itself or
simply refuse to do anything more when the method is used, depending on
implementation. I'm feeling mortal tonight, so I'll say it commits suicide,
and you're left with it's output and a running Vat that quux-maker started.
In this example, you can go no farther than to exit the process, and kill
the Vat. You're have, at that point, with the output of the quux object's
method and a debug log (execution trace).

That's a relatively simple framework. Indeed, I've not done more than
provide a sample circumstance and included, obliquely at best, the notion of
more complete DbC support in a fictional E variant with a more robust set of
tools. So, to build upon this:

5. Distribute this problem across two machines. I have two Vats, one on each
individual machine. The machines are at different locations on an untrusted
network and are mutually suspicious hosts. The operator of Machine Foo,
Alice, is running quux-maker in her Vat. It has not yet produced any quux
objects. It may only produce one quux object. The Vat has not yet been
accessed; accessing it immediately creates a quux object.

6. Bob, operator of Machine Bar, is running a Vat. His Vat is empty, and is
waiting to receive a quux object.

7. Alice offers up a Smart Contract that grants the buyer a capability to
her Vat, and one-time only access to any one object within it, and to all
the available methods of that object. For this, Alice wants one dollar ($1
USD)

8. Bob negotiates with Alice over the Smart Contract she has offered, and
includes trusted third party Carol in the standard ERTP system. I'm going to
fudge a lot here and say that Alice received Bob's dollar and Bob received
Alice's capability to her Vat.

9. Bob invokes Alice's capability, which grants him access to her Vat. Since
this is the first access of this Vat, a quux object is constructed.

10. Bob inspects the quux object and finds it's "replicate" method, and uses
it. Bob is returned the output of the quux object as above and his access to
the Vat is terminated.

11. Bob thinks that the code he has is valid code to place in his Vat in
order to create quux objects, but isn't sure. How can he verify that the
code is good without running it?

Here's where I go into free-thought land. In keeping with the model thus
far, what I would have happen next is this:

In the Smart Contract that Alice and Bob negotiated and settled, Bob was
given representative source code which used DbC and DeBaClE as a stipulation
of the contract. That code detailed the construction of quux objects. In
order for the Smart Contract to be satisfied, that code would have to pass
scrutiny of a test compilation in DeBaClE, ostensibly meaning that the code
had fulfilled all of it's "contracts". It would also mean that the output
code would have to be identical to the code Bob now has.

There are a number of points here. I can't help but feel that I'm
simultaneously over-engineering a solution to a problem which we already
have a more concise solution for but feel is solid conceptually. I'm certain
I'm leaving out critical points in both concept and in fictional
implementation that vastly effect the practice and outcome of this sort of
thing. And there are plenty of practical points I've glossed over, such as
the problem of having to verify large amounts of code in a test compilation
leading to lengthy transaction times.

Indeed, perhaps this fruit is too far from the ground. Still, I think it's
interesting, and it's managed to hold on to my interest this far. It's more
likely that the usefulness of DbC is not in far-flung automatic code
generation or code proving, but in programmer oriented methodologies. There
are some additional thoughts I've had with respect to E, DbC, and Aspect
Oriented Programming, but I'll leave those for a potential future
discussion. I'm _REALLY_ interested on all sorts of feedback on the above
though, and I'll be happy to clarify wherever I've been too gray on things.
I'm especially interested in comparing the framework thatıs in my head to
KeyKOS-style  "factories".

As for the E compiler I mentioned long ago (tentatively dubbed "Eco"), it's
still ubernascent, but with the recent anoncvs access, may find it's way
into the risky and dangerously alpha branch of the tree sometime in the
moderately distant future.

Other ideas: caplab.{net,org} -- a site for capability projects of all types
(languages, code, software, books, etc. A community site for the capability
curious. Something to point new people to. Content would probably be an
amalgamation of what Norm has on cap-lore.com and various expository bits
from the key sites in the capability web ring MarkM setup. Also could
provide a sort of "mini sourceforge" for embryonic capability projects in
terms of public web space, maybe mailing list hosting. caplab.com is taken,
unfortunately.

E Documentation Project -- I've been talking with some of the chief people
in both the Linux Documentation Project and the Zope Documentation Project
for pointer and hints, as well as to relate their experiences. More soon,
including a beta framework/layout for people to sink their teeth into.

Caps in other languages -- modifying other suitable "out-of-the-box"
languages with the basics to support capabilities. Particularly Python and
Ruby (my new language du jour; as Steve Jenson can attest, I'm a language
nerd through and through). More exotic choices currently on the docks are
Common Lisp/CLOS, Haskell (monads as caps), and Smalltalk-80 (as implemented
in Squeak). Something I'm particularly interested in learning more about and
wondering if it could be done at all, caps in a prototype-centric language
(non-class based) like Self.

More soon...


-- 
Dan Moniz <dnm@pobox.com> [http://www.pobox.com/~dnm/]