[E-Lang] E FAQ

[Ken Kahn]

MarkM wrote:
>
> To get an Actor-like (or Joule-like, or Concurrent Prolog-like) program,
> replace every immediate call with an eventual send.  Now the arrival order
> of Bob's message to Carol and Alice's message to Carol is
non-deterministic.
> This has advantages and disadvantages over conventional
> sequential-imperative programming.  But the fatal disadvantage is a severe
> loss of familiar guarantees, and a consequent need to relearn how to
program
> without them.
>
and
>
> I speculate that any program that would be correct in this weaker language
> would also be correct in E, but E, by providing more guarantees (that in
> practice cost nothing), such as the isolation turns from each other,
allows
> more useful programs and patterns to be correct.  For example, I don't
think
> MarcS' notaryMaker http://www.skyhunter.com/marcs/ewalnut.html#SEC45 could
> be written in Actors without an unreasonable amount of pain.  (When I
first
> saw him use this technique, it took me fully by surprise, as I'd gotten
used
> to such things being impossible.)
>
>

For ToonTalk I don't have to be concerned much with a "severe loss of
familiar guarantees" since for my users nothing is familiar and there is
nothing they need to "relearn".

But I'm not convinced in the general case (E and Mozart/Oz). Earlier this
month I was visiting with some of the Mozart people at SICS and this topic
came up frequently. The Mozart people were supporting MarkM's argument.
Here's my (biased) summary of the argument:

Without language support to express sequential computations programming
becomes awkward. But how awkward? The consensus was that you can easily
express it using two extra arguments to everything that you might want to
sequentialize. One to know that earlier computations have completed and
another to tell computations downstream that this one has finished.

Given that that is awkward the argument then goes how frequently is this
sequentiality needed and what is the conceptual cost? An argument was made
that it is very frequent when dealing with external devices (e.g. file i/o
or screen graphics). Let's consider graphics more carefully. At first it
might seem clear that you need sequential control so that things are drawn
properly. But the increasing common way of programming graphics, especially
3D, is that your program manipulates a model that a separate engine renders
to the screen. I suspect that the normal manipulations of such a model (e.g.
adding and removing objects or moving them around) can be done
non-deterministically in nearly all cases. And maybe this style can be
replicated for other situations. File i/o can perhaps be performed by
manipulating a description that is "rendered" to a file.

Ueda has been attempting to keep the concurrent logic programming flame
alive. He makes some very good arguments for simplicity. I enjoyed reading
the following:

http://www.ueda.info.waseda.ac.jp/~ueda/pub/LPP-ueda2.ps

Kazunori Ueda, Concurrent Logic/Constraint Programming: The Next 10 Years.
In The Logic Programming Paradigm: A 25-Year Perspective, K. R. Apt, V. W.
Marek, M. Truszczynski, and D. S. Warren (eds.), Springer-Verlag, 1999,
pp.53-71.
Concurrent logic/constraint programming is a simple and elegant formalism of
concurrency that can potentially address a lot of important future
applications including parallel, distributed, and intelligent systems. Its
basic concept has been extremely stable and has allowed efficient
implementations. However, its uniqueness makes this paradigm rather
difficult to appreciate. Many people consider concurrent logic/constraint
programming to have rather little to do with the rest of logic programming.
There is certainly a fundamental difference in the view of computation, but
careful study of the differences will lead to the understanding and the
enhancing of the whole logic programming paradigm by an analytic approach.
As a model of concurrency, concurrent logic/constraint programming has its
own challenges to share with other formalisms of concurrency as well. They
are: (1) a counterpart of lambda-calculus in the field of concurrency, (2) a
common platform for various non-sequential forms of computing, and (3) type
systems that cover both logical and physical aspects of computation.

Best,

-ken kahn ( www.toontalk.com )