[e-lang] Yet Another Revision

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Wed Jun 29 19:55:44 EDT 2005


Mark Miller wrote:
> Besides suggestions for improvements, please let us know whether you 
> think of the new Title, Abstract, and Intro work. Thanks!

They're a significant improvement. However, I think perhaps the introduction
is a bit too enthusiastic about the desirability, and success, of "systems too
complex for anyone to understand as a whole". Modularity and abstraction
are helpful at any level of complexity, but many of the systems that are
too complex for a single person to understand shouldn't be, and have no good
reason to be so complex. (Backward compatibility isn't in itself a good
reason.)

I know that the introduction doesn't literally say that "any amount of
complexity is just fine as long as you have abstraction mechanisms to deal
with it", but that's how it reads. Philosphically, my stance on this is much
closer to the following passage from "Design Principles of Smalltalk"
<http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html>:

# Just to get warmed up, I'll start with a principle that is more social than
# technical and that is largely responsible for the particular bias of the
# Smalltalk project:
#
#    Personal Mastery: If a system is to serve the creative spirit, it must be
#    entirely comprehensible to a single individual.
#
# The point here is that the human potential manifests itself in individuals. To
# realize this potential, we must provide a medium that can be mastered by a
# single individual. Any barrier that exists between the user and some part of
# the system will eventually be a barrier to creative expression. Any part of the
# system that cannot be changed or that is not sufficiently general is a likely
# source of impediment. If one part of the system works differently from all the
# rest, that part will require additional effort to control. Such an added burden
# may detract from the final result and will inhibit future endeavors in that area.


====
Anyway, here's my next batch of comments:

- The "eventual" option corresponds to the human notion of a "to-do" list: the
- item is queued for later execution. This is much like asynchronous messaging
- (or non-strict eager evaluation) but with some crucial differences. E provides
- direct support for this execution option, represented by the "<-" or
- eventual-send operator.

The fact that direct language support is provided is not a difference from
(some) other asynchronous messaging systems. The implied other differences from
asynchronous messaging are left dangling: it isn't clear what parts of the
subsequent paragraphs are describing differences.

In fact I think this part of E isn't just *like* an asynchronous messaging
system; it *is* one. The category of asynchronous messaging systems is fairly
wide.

The connection to non-strict eager evaluation is obscure. Since there isn't
room to explain it, just drop it:

+ The "eventual" option corresponds to the human notion of a "to-do" list:
+ the item is queued for later execution. E provides direct support for this
+ asynchronous messaging option, represented by the "<-" or eventual-send
+ operator.


   Because computation never blocks, all deadly embrace hazards are eliminated
   from E computation.

This seems too strong. Isn't datalock a "deadly embrace hazard"?
(I don't particularly like the term "deadly embrace" anyway.)


   We will refer to the set of all elements on which P relies as P’s /reliance set/.

Bravo. Much better than "TCB".


- (**MARK not sure this is coherent) It is important to note that the defensive
- properties have some composability properties. If P relies on R, unless R is
- defensively consistent, P also relies on the correctness of R’s other clients.
- This is because without defensive consistency, R cannot actually ensure that
- it provides correct behavior to P.

"Composability properties" isn't right here. Just delete it:

+ Note that if P relies on R, unless R is defensively consistent, P also relies
+ on the correctness of R’s other clients. This is because without defensive
+ consistency, R cannot actually ensure that it provides correct behavior to P.


- Conventional OSes provide some support for inter-user protections from each
- other's misbehavior.
+ Some conventional operating systems attempt to provide support for protecting
+ users from each other's misbehavior.

Implying that there are any conventional OSes that actually *succeed* at protecting
users from each other's misbehavior is arguably too strong. And some nominally
multi-user OSes don't try very hard.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>





More information about the e-lang mailing list