lowry@watson.ibm.com (Andy Lowry) (06/10/91)
Request For Discussion
Proposed New Group:
Name : comp.lang.hermes
Moderated : No
Charter : Provide a convenient forum where: (1) users of Hermes
can share their experiences with the language and
system; (2) language design issues can be discussed; (3)
system implementers can announce new releases, bug
fixes, etc.; (4) language/implementation questions can
be asked and answered in a manner that will benefit all
Hermes users; (5) Hermes implementers can solicit user
feedback to help in planning future development
directions; (6) researchers and students of programming
languages, operating systems, and distributed computing
can learn about Hermes and related work, even if they
are not activeh#m Hermes users.
Discussion Period : Now - June 30, 1991
Target Voting Period : July 1 - 31, 1991
NOTE: All discussion regarding this proposed newsgroup should take
place on the news.groups newsgroup, NOT on the news groups to which
this RFD has been sent. If you cannot post to news.groups, you may
send your comments to hermes@watson.ibm.com; unless you request
otherwise, such comments will be forwarded to news.groups.
Unless counter-indicated by the discussions resulting from this RFD, a
call for votes will be issued on or around July 1, 1991, and will be
sent to all the newsgroups to which this RFD has been sent.
- - - - - - - - - - - - - - - -
Background Information:
Hermes is a computer programming language especially suited for the
construction of distributed applications. It was designed by
researchers in the Distributed Systems Software Technology (DSST)
group of IBM's T.J. Watson Research Center. An experimental prototype
implementation is available on a number if Un*x platforms, free of
charge and without a license. Since its initial release in June 1990,
nearly 200 sites have acquired the Hermes software, initially via
physical tape cartridges and more recently via anonymous ftp
throughout the internet. A language tutorial and reference manual was
published by Prentice-Hall in February of 1991. Hermes has been
taught in courses on distributed computing as well as networking, in
the U.S. and Canada. A number of researchers are currently utilizing
Hermes as a platform for research in distributed computing and
programming languages. Hermes is an important and on-going research
project at DSST, and substantial work is in-progress and in plan, both
with respect to language design issues and regarding the prototype
implementation. A newsgroup dedicated to Hermes discussions and
announcements will be invaluable for the growing community of Hermes
users.
Some important features of Hermes are:
* Process Paradigm:
The process is the unit of modularity. Hermes processes are as
`lightweight' as procedures in Algol-like languages, and have the same
data hiding properties as `objects' in object-oriented languages. A
process is an independent active entity, consisting of private data
and a sequential program. Processes interact by issuing calls on
`output ports' (e.g. call p(a, b) sends the callmessage (a, b) on the
port p), and receiving calls on `input ports'. This model yields a
simple compositional semantics. It is easy to reason about Hermes
processes, since a Hermes process behaves the same `in isolation' as
it does when linked up to a large system.
* Tables:
There is a single type constructor for homogeneous data aggregates---a
relational table. Tables are a consistent abstraction for data which
could be implemented as strings, arrays, linked lists, hash tables,
trees, indexed files, etc. The programmer can insert and remove
elements from tables, retrieve elements by content, merge two tables,
and copy or extract selected subsets of a table. By providing tables,
Hermes makes programming simpler and more portable, gives the compiler
more freedom to provide alternative efficient data representations,
and eliminates potentially dangerous explicit pointer manipulation.
* Compile-time checking:
Hermes is strongly typed. The use of operations with operands of
the wrong type is detected at compile-time. Additionally, Hermes
introduces a dataflow-based checking called typestate checking.
Typestate checking detects such additional errors as failing to
initialize a variable, and using a variant from the wrong case.
Typestate analysis also allows the compiler to reuse storage safely
and thus avoid the need for run-time garbage collection. It is a
goal of Hermes to detect as many errors as possible before a process
begins execution. A polymorph data type is provided as an escape to
defer type and typestate checking until run-time.
* Security:
In many languages, a single erroneous module can bring down an entire
program. Because a `program' in a systems language might include
multiple users, it is important to limit the effect of programming
errors. In Hermes, an erroneous process may generate incorrect output
values of the correct type, or may fail to generate any output values,
but it can never cause other processes to crash or violate the Hermes
semantics. Hermes enforces security largely at compile-time,
thanks to typestate checking. Typestate checking improves performance
as well as reliability, since processes on a single machine can safely
share a single hardware address space, even when these processes are
acting on behalf of different users.
* Dynamic Configuration:
Using Hermes, programmers can create, link, and rebind processes
dynamically using language primitives without the need to make system
calls. Ports are first-class values in Hermes. They can be assigned
to variables, stored in tables, passed in messages, etc. The port
type determines the interface only, not the binding to code. The
effect of replacing one port value with another is to rebind a port to
a `plug-compatible' process which may have completely different code
but which is guaranteed to have the expected interface. The
combination of dynamics with security is valuable in implementing
long-lived systems that evolve over time.
* Capability-Based Access Control:
In Hermes there are no global names. A process can only interact with
processes for which it has been given ports. Since ports are
first-class, a programmer can provide controlled access to resources
by writing processes that manage the resource and giving out ports
only to these processes. This provides the flexible access control
found in capability-based systems. Using ports as capabilities is
efficient because all the checks which are needed to assure that
capabilities are not forged have been done at compile-time.