[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
[xanadu!CUNYVM.CUNY.EDU!jlevy%ee.technion.ac.il: Announcement of a language called Hermes]
- To: <us@xxxxxxxxxxx>, <hallway@xxxxxxxxxxx>
- Subject: [xanadu!CUNYVM.CUNY.EDU!jlevy%ee.technion.ac.il: Announcement of a language called Hermes]
- From: Mark S. Miller <vlad!mark>
- Date: Thu, 5 Apr 90 17:02:29 PDT
Interesting. It's predecessor, NIL, was a truly excellent piece of
Date: Thu, 5 Apr 90 23:22:38 +0200
From: Jacob Levy <xanadu!CUNYVM.CUNY.EDU!jlevy%ee.technion.ac.il>
Subject: Announcement of a language called Hermes
I think I would like to check out this language.
From: qtny!dagobah!arnor!strom@xxxxxxxxxxxx (Rob Strom)
Subject: Hermes Language Availability
Date: 21 Mar 90 17:47:18 GMT
Hermes Language Availability
The Hermes language system, developed at the IBM T.J. Watson
Research Center, is now available. The Hermes distribution
includes source code, does not require a license agreement, and
is free of charge.
Hermes is a very-high-level integrated language and system for
implementation of large systems and distributed applications, as
well as for general-purpose programming. It is an imperative,
strongly typed, process-oriented language. Hermes hides
distribution and heterogeneity from the programmer. The
programmer sees a single abstract machine containing processes
that communicate using calls or sends. The compiler, not the
programmer, deals with the complexity of data structure layout,
local and remote communication, and interaction with the
operating system. As a result, Hermes programs are portable and
easy to write. Because the programming paradigm is simple and
high level, there are many opportunities for optimization which
are not present in languages which give the programmer more
direct control over the machine.
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 insert automatic finalization code
(`typestate coercions'). 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.
The Hermes system is written in a combination of C and Hermes,
and should port easily to most 32-bit Unix systems. It currently
runs under 4.3 BSD on the IBM RT, Sun 3's and 4's running SunOS,
and on the IBM RISC System/6000. The compiler and run-time
environment are highly modular, table-driven, and extensible.
Existing and de-facto standards have been used wherever possible.
Hermes is based on previous work on the Network Implementation
Language (NIL), which is described in the September 1989 issue of
The system is being made available both for those wishing a
simple and secure language for writing distributed programs and
for those interested in using Hermes as a testbed for their own
research in programming languages, distributed systems,
optimization techniques, or programming environments. Hermes is
an experimental language, and will continue to evolve. The
Hermes group is eager for feedback regarding implementation bugs
and suggestions for enhancement. Your input will be valuable in
directing future work on Hermes. However, we obviously cannot
guarantee the same level of service as a commercial product.
The prototype Hermes system includes a compiler and interpretive
run-time system, interface to the Unix stdio library, make tool,
shell, disassembler, Gnu Emacs mode, and, as a demonstration
application, a distributed appointment scheduler. The
documentation includes a tutorial, a reference manual, an
installation guide, and the formal tables which drive the
compiler source code.
To request a copy of the Hermes system or manual, or if you wish
to be added to the Hermes mailing list, send mail with your
e-mail and postal address to hermes-request@xxxxxxxx We'd
appreciate your including in your request a brief description of
your interest in Hermes.
David Bacon, Arthur Goldberg, Andy Lowry, Rob Strom, Dan
Yellin, Shaula Yemini
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
Programming Languages for Distributed Computing Systems, by
Henri E. Bal, Jennifer G. Steiner, and Andrew S. Tanenbaum,
Computing Surveys Vol. 21 No. 3, September 1989.
NIL: An Integrated Language and System for Distributed
Programming, by Robert E. Strom and Shaula Yemini,
Proceedings of the SIGPLAN '83 Symposium on Programming Issues in
Software Systems, June 1983.
Typestate: A Programming Language Concept for Enhancing
Software Reliability, by Robert E. Strom and Shaula Yemini, IEEE
Transactions on Software Engineering, Vol. SE-12, No. 1,
Rob Strom, strom@xxxxxxx, (914) 784-7641
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY 10958