% (C) Copyright International Business Machines Corporation 23 January 
% 1990.  All Rights Reserved. 
%  
% See the file USERAGREEMENT distributed with this software for full 
% terms and conditions of use. 
\section{Unsupported Features and Known Bugs}
\label{Unsupported}
This section summarizes the Hermes language features which are not yet
supported in the current implementation, as well as bugs known to
exist.

\begin{itemize}

\item Constraints.  There are no support for user-defined constraints and
the {\bf assert} and {\bf drop} statements.

\item Checking of Polymorphs.  Type and typestate information is not associated
with a polymorph value, so polymorphs are unchecked and hence insecure.  This
means that the {\bf type of} and {\bf typestate of} operators do not work
properly.

\item Constant lists on blocks are not supported.

\item Parameter lists using association notation are not supported; only
positional notation may currently be used.

\item Programs as objects.  Program objects that are written by the compiler
(the {\tt *.po} files) do not include the abstract program object; thus all the 
fields of objects of type {\bf predefined!program} are not initialized.  
Accessing these fields will cause unpredictable results.  

In addition, the {\bf checked} attribute is not supported because it was 
intended to be a constraint.

\item Nominals.  Two invocations of the interpreter generate identical
nominals, though in most situations this should be highly unlikely.
On very fast machines, compilation of multiple definitions modules via
the standalone parser is likely to result in different compiled
definitions modules with the same module ID.  This can result in
mysterious compilation errors later for both definitions and process
modules.  The standalone parser is not expected to be used other than
by the build process, which artificially slows down this phase of the
build to prevent this problem from occuring.

\item Function calls are expressions and should only be able to modify their
result argument; however, the abstract program fails to distinguish between
function calls and call statements, rendering this check impossible.

\item Checking of typestates in definition modules.  There are a number of
checks that are not done to verify the validity of typestates: matching the
parameter counts and types for built-in attributes (preventing {\bf init(x,y)}
and {\bf case(x,y)}); checking for impossible typestates; checking that constant
parameters have the same entry typestate in their inport definition as in the
callmessage exits; and checking that the minimum of a call is the lowest exit
typestate.  Most of these things will be uncovered when typestate checking a
program module that uses the incorrect definitions module.

\item Reals.  The real number type family is not supported.

\item {\tt rem} operator.  The sign of the result of {\tt a rem b} is
guaranteed positive if both {\tt a} and {\tt b} are positive.
Otherwise, the sign is not guaranteed.  It should be the same sign as
{\tt a} in all cases.

\item Checkdefinitions.  The {\bf checkdefinitions} operation is not supported,
nor is the {\bf checkeddefinitions} typestate attribute.
% *** Should we at least put in comments for it or something?

\item Coercion of Callmessages and Variants.  At typestate merge points (such
as the end of an conditional statement or the beginning of a loop) coercions
may be inserted by the typestate checker to discard callmessages and hide
variants.  These operations are incompletely implemented and may lead to 
values not being discarded when they should.    This is only a problem for 
inport, outport, and callmessage values 

\item Copying tables containing uncopyable objects.  If a table that might
contain uncopyable objects (inports or callmessages) is copied, it should
generate a run-time {\bf Uncopyable} exception; however, the current
implementation will not raise the exception until either the original or the
copy is modified (due to copy-on-write sharing of tables), meaning that the
exception might be raised at the wrong place (such as an {\bf insert}).

\item Hidden table copying.  Some Hermes operations that are not
allowed to raise {\bf Uncopyable} exception nevertheless may, because
their current implementation involves copying potentially uncopyable
objects.  This includes {\bf inspect\_table}, {\bf for\_inspect}, and
{\bf extract}.

\item Position of bug.  This is a very arcane bug: if you inspect an object
in a table using positional notation, and then use the {\bf position of}
operation on it, if there are other objects in the table with the same value,
you may get the position of one of the equal values instead of the one you
actually have.

\item Keys cannot contain polymorphs, programs, or callmessages.  A
comparison operator required for our implementation of keyed tables
has not yet been implemented for polymorphs, programs, or
callmessages.  Any table type defined with keys that make use of such
types is likely to malfunction.

\item Inspected polymorphs not modifiable.
In INSPECT-POLYMORPH, the unwrapped object should be held constant,
but the polymorph itself should not.  Currently, modifying the
polymorph in the body of an INSPECT-POLYMORPH is not supported, and
doing so will likely cause the interpreter to crash.

\item Depletion handling.  
If memory runs out during execution, a {\bf depletion} exception should
be raised.  This has not been adequately tested, so may be unreliable.  

\item Failures cause Hermes to abort.
Many failures that may occur during the operation of the Hermes
interpreter are not yet properly handled.  In many cases, the
current implementation simply shuts down, even when a reasonable
alternative exists.  All such situations are considered to be
extremely unlikely, and should be fixed in due time.

\item Deadlocks in distributed applications.
If two interpreters send each other very large messages, they may
deadlock due to flow-control mechanisms in the underlying
communications protocols.  This is because synchronous {\tt write}
operations are used to send messages.

\item Inports incorrectly garbage collected.
Updating of reference counts for inports with remote connected
outports is subject to a race condition that can cause the interpreter
to crash.

\item File descriptor depletion.
Programs that create many windows or link to several remote
interpreters may cause the interpreter to run out of file descriptors.
There may be cases where this will cause the interpreter to either
hang or crash.

\item Distributed interpreters never exit.  An interpreter in which
the {\tt start network} C-Hermes process has been invoked will never
terminate, waiting instead for incoming messages from the network.
Typing control-C at the controlling terminal should halt such an
interpreter.


\end{itemize}

