% (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 is no support for user-defined constraints and
the {\bf assert} and {\bf drop} statements.

\item Checking of Polymorphs.  Typestate information is not associated
with a polymorph value, so polymorphs are not completely
checked and hence insecure.  This
means that the {\bf typestate of} operator does not work properly, and
that unwrap and inspect-polymorph do not raise the mismatch exception
for incompatible typestates.

\item Constant lists on blocks are not supported.

\item Parameter lists using association (also called keyword) notation are not
supported; only positional notation may currently be used.

\item Nominals.  Two invocations of the interpreter may generate identical
sequences of nominals, though this is highly unlikely.  The invocations must
sample the {\bf UNIX} system clock within the same millisecond to achieve this
effect.  If they sample the clock within different seconds, their sequences
are guaranteed disjoint for at least the first 3 billion nominals.  If they
sample the clock within the same second, but N milliseconds apart, the
earlier invocation must generate N million nominals before its sequence
overlaps the sequence of the later invocation.  An invocation samples the
clock initially when generating its first nominal.  It samples it again after
3-4 billion nominals, and thereafter in a period of $ 2^{32} $ nominals.

\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 Reals.  The accuracy attribute is not supported.  An out-of-range
real literal is compiled as real zero, without diagnostic.

\item Checkdefinitions.  The {\bf checkdefinitions} operation is not supported,
though the {\bf checkeddefinitions} typestate attribute is handled by
the typestate checker.  The {\tt defintionschecker} resource can be
used to check definitions modules.

\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, as these are the only types
for which discards can have visible side-effects.

\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 {\bf 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 {\bf Position of} again.  This has the same underlying cause as
the previous bug.  If you inspect an element of an ordered table,
delete the element you're inspecting, and then attempt to find its
position via {\bf position of}, you will probably get a result that is
one greater than the size (after the remove) of the table.  You may
get a different answer if there is another table element equal to the
one you were inspecting.

\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.  This has never been observed in practice.

\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.

\item No user exceptions from C-Hermes processes.  Our mechanism
supporting Hermes system processes written in C does not allow the return
of user-defined exceptions.  Therefore, such processes are incapable
of returning the exceptions defined with the interfaces to which they
otherwise adhere.  In all such cases, the processes currently discard
the callmessage.

\item Signed integer and real literals are incorrectly parsed.  A plus or minus
sign (+ or -) immediately preceding an integer literal is tokenized as
part of the literal in all cases.  This means that expressions like
``a+1'' end up getting parsed incorrectly (the parser sees a variable
followed by an integer literal with no intervening operator).  The
workaround for this bug is to interpose a space between the sign and
the first digit of the literal (as in ``a\ +\ 1'').

\item Inconsistent and/or unhelpful error messages.  Some of the
Hermes system modules (like root, cache, shell, etc.) either do not
check for common errors or do so inadequately (like via an ``on
(others)'' clause at the end of the module), and therefore produce
terribly inadequate diagnostics when errors arise.

\item Carriage return not a line terminator.  A carriage return should
be recognized as an end-of-line character by the compiler.  The line
counter should be incremented for each CR not appearing with an
accompanying LF, and for each LF.

\item Incorrect reports of dead code.  If a process module contains
only statements that cannot raise exceptions, the compiler will
complain about dead code in the block and refuse to compile the
program.  This is due to an implicit ``on(others)'' handler that is
wrapped around the entire process body.  If the process is immune from
exceptions, that handler cannot ever be entered. 

\item Expression block scope violation.  The result variable appearing
in an expression block (evaluate...from statement) is currently placed
in the scope containing the expression block, rather than the new
scope created for the expression block.  This means that you cannot
currently have two expression blocks naming the same result variable
in overlapping scopes.

\item Tracing of C-Coded programs.  When a C-Coded program is
executing only the residual LI instructions remaining in the
transformed {\tt .po} file (usually, just {\tt ESCAPE} instructions)
are traced.

\item Depletion exceptions in {\tt block} statements.  Although the
language definition specifies that the {\tt block} statement can raise
{\tt Depletion}, the typestate checker does not account for this
possibility.  The most likely visible effect of this is an error
message from the typestate checker claiming that your {\tt Depletion}
exception handler is unreachable.

\end{itemize}

