%
%  The Regina Rexx Interpreter
%  Copyright (C) 1992-1994  Anders Christensen <anders@pvv.unit.no>
%


\chapter{Implementation Limits}
\label{ch:limits}

\begin{it}
This chapter lists the implementation limits required by the
{\rexx} standard. All implementations are supposed to support at least
these limits.
\end{it}


\section{Why Use Limits?}

Why use implementation limits at all? Often, a program (ab)uses a
feature in a language to an extent that the implementor did not
foresee. Suppose an implementor decides that variable names can not be
longer than 64 bytes. Sooner or later, a programmer gets the idea of
using very long variable names to encode special information in the
name; maybe as the output of a machine generated program. The result
will be a program that works only for some interpreters or only for
some problems.

By introducing implementation limits, {\rexx} tells the implementors
to what extent a implementation is required to supprt certain
features, and simultaneously it tells the programmers how much
functionality they can assume is present.

Note that these limited are required minimums for what an
implementation must allow. An interpreter is not supposed to enforce
these limits unless there is a good reason to. 



\section{What Limits to Choose?}

A limit must not be perceived as an absolute limit, the implementor is
free to increase the limit. To some extent, the implementor may also
decrease the limit, in which case this must be properly documented as
a non-standard feature. Also, the reason for this should be noted in
the documentation.

Many interpreters are likely to have ``memory'' as an implementation
limit, meaning that they will allow any size as long as there is
enough memory left. Actually, this is equivalent to no limit, since
running out of memory is an error with limit enforcing interpreters as
well. Some interpreters let the user set the limits, often controlled
through the {\tt OPTIONS} instruction.

For computers, limit choices are likely to be powers of two, like 256,
1024, 8192, etc. However, the {\rexx} language takes the side of the
user, and defines the limits in units which looks as more ``sensible''
to computer non-experts: most of the limits in {\rexx} are numbers
like 250, 500, 1000, etc.


\section{Required Limits}

These are the implementation minimums defined by {\rexx}:
\begin{description}
\item[Binary strings]
   must be able to hold at least 50 characters after packing. That
   means that the unpacked size might be at least 400 characters, plus
   embedded white space.

\item[Elapse time clock]
   must be able to run for at least 10**10-1 seconds, which is
   aproximately 31.6 years. In general, this is really a big overkill,
   since virtually no program will run for a such a period. Actually,
   few computers will be operational for such a period.

\item[Hexadecimal strings]
   must be able to hold at least 50 characters after packing. This
   means that the unpacked size might be at least 100 characters, plus
   embedded white space.

\item[Literal strings]
   must be able to hold at least 100 characters. Note that a double
   occurence of the quote character (the same character used to
   delimit the string) in a literal string counts as a single
   character. In particular, it does not count as two, nor does it
   start a new string.

\item[Nesting of comments] 
   must be possible to in at least 10 levels. What happens then is not
   really defined. Maybe one of the syntax errors is issued, but none
   is obvious for this use. Another, more dangerous way of handling
   this situation would be to ignore new start-of-comments designators
   when on level 10. This could, under certain circumstances, lead to
   running of code that is actually commented out. However, most
   interpreter are likely to support nesting of comments to an
   arbitrary level.

\item[The Number of Parameters]
   in calls must be supported up to at least 10 parameters. Most
   implementations support somewhat more than that, but quite a few
   enforce some sort of upper limit. For the built-in function, this
   may be a problem only for {\tt MIN()} and {\tt MAX()}. 

\item[Significant digits] 
   must be supported to at least 9 decimal digits. Also, if an
   implementation supports floating point numbers, it should allow
   exponents up to 9 decimal digits. An implementation is allowed to
   operatate with different limits for the number of significant
   digits and the numbers of digits in exponents. 

\item[Subroutine levels]
   may be nested to a total of 100 levels, which counts both internal
   and external functions, but probably not built-in functions. You
   may actually trip in this limit if you are using recursive solution
   for large problems. Also, some tail-recursive aproaches may crash
   in this limit. 

\item[Symbol (name) length]
   can be at least 50 characters. This is the name of the symbol, not
   the length of the value if it names a variable. Nor is it the name
   of the variable after tail substitution. In other words, it is the
   symbol as it occurs in the source code. Note that this applies not
   only to simple symbols, but also compound symbols and constant
   symbols. Consequently, you can not write numbers of more than 50
   digits in the source code, even if {\tt NUMERIC DIGITS} is set
   high.

\item[Variable name length]
   of at least 50 characters. This is the name of a variable (which
   may or may not be set) after tail substiution. 
\end{description}


\section{Older (Obsolete) Limits}

First edition of {\trl} contained some additional limits, which have
been relaxed in the second edition in order to make implementation
possible for a large set of computers. These limits are:
\begin{description}
\item[Clock granularity] was defined to be at least of a millisecond.
   Far from all computers provide this granularity, so the requirement
   have been relaxed. The current requirement is a granularity of at
   least one second, although a millisecond granularity is advised.
\end{description}


\section{What the Standard does not Say}

An implementation might enforce a certain limit even though one is not
specified in the standard. This section tries to list most of the
places where this might be the case:
\begin{description}
\item[The stack] 
   (also called: the external data queue) is not formally defined as a
   concept of the language itself, but a concept to which the {\rexx}
   language has an interface. Several limits might apply to the stack,
   in particular the maximum length of a line in the stack and the
   maximum number of lines the stack can hold at once. 

   There might also be also be other limits related to the stack, like
   a maximum number of buffers or a maximum number of different stack.
   These concepts are not refered to by {\rexx}, but the programmer
   ought to be aware of them. 

\item[Files]
   may have several limits not specified by the definition of {\rexx},
   e.g.~the number of files simultaneously open, the maximum size of a
   file, and the length and syntax of file names. Some of these limits
   are enforced by the operating system rather than an implementation.
   The programmer should be particularily aware of the maximum number
   of simultaneously open files, since {\rexx} does not have a
   standard construct for closing files. 

\item[Expression nesting]
   can in some interpreters only be performed to a certain level. No
   explicit minimum limit has been put forth, so take care in complex
   expressions, in particular machine generated expressions. 

\item[Environment name length]
   may have some restrictions, depending on your operating system.
   There is not defined any limit, but there exists an error message
   for use with too long environment names. 

\item[Clause length]
   may have an upper limit. There is defined an error message ``Clause
   too long'' which is supposed to be issued if a clause exceds a
   particular implementation dependant size. Note that a ``clause''
   does not mean a ``line'' in this context; a line can contain
   multiple clauses. 

\item[Source line length]
   might have an upper limit. This is not the same as a ``clause''
   (see above). Typically, the source line limit will be much larger
   than the clause limit. The source line limit ought to be as large
   as the string limit. 

\item[Stack operations]
   might be limited by several limits; first there is the number of
   strings in the stack, then there is the maximum length of each
   string, and at last there might be restrictions on the character
   set allowed in strings in the stack. Typically, the stack will be
   able to hold any character. It will either have ``memory'' as the
   limit for the number of string and the length of each string, or it
   might have a fixed amount of memory set aside for stack strings.
   Some implementations also set a maximum length of stack strings,
   often 2*8 or 2*16. 

\end{description}



\section{What an Implementation is Allowed to ``Ignore''}

In order to make the {\rexx} language implementable on as many
machines as possible, the {\rexx} standard allow implementation to
ignore certain features. The existance of these features are
recommended, but not required. These features are:

\begin{description}
\item[Floating point numbers]
   are not required; integers will suffice. If floating points are not
   supported, numbers can have not fractional or exponential part. And
   the normal division will not be available, i.e. the operator ``{\tt
   /}'' will not be present. Use integer division instead.

\item[File operations] 
   are defined in {\rexx}, but an implmentation seems to be allowed to
   differ in just about any file operation feature. 
\end{description}




\section{Limits in {\regina}}

{\regina} tries not to enforce any limits. Wherever possible,
``memory'' is the limit, at the cost of some CPU whenever internal
datastructures must be expanded if their initial size were too small.
Note that {\regina} will only increase the internal areas, not
decrease them afterwards. The rationale is that if you happen to need
a large internal area once, you may need it later in the same program
too.


In particular, {\regina} has the following limits:

\begin{center}
\begin{tabular}{ll}
Binary strings          & source line size\\
Clock granularity       & 0.001-1 second (note 3)\\
Elapse time clock       & until ca.~2038 (note 1)\\
Hexadecimal strings     & source line size\\
Literal string length   & source line size\\
Nesting of comments     & memory\\
Parameters              & memory\\
Significant digits      & memory (note 2)\\
Subroutine levels       & memory\\
Symbol length           & source line size\\
Variable name length    & memory (note 2)\\
\end{tabular}
\end{center}

Notes:
\begin{enumerate}
\item
   {\regina} uses the Unix-derived call {\tt time()} for the elapse
   time (and time in general). This is a function which returns the
   number of seconds since January 1st 1970. According to the ANSI C
   standard, in which {\regina} is written, this is a number which
   will at least hold the number 2**31-1. Therefore, these machines
   will be able to work until about 2038, and {\regina} will satisfy
   the requirement of the elapse time clock until 2006. By then, 
   computers will hopefully be 64 bit. 

   Unfortunately, the {\tt time()} C function call only returns whole
   seconds, so {\regina} is forced to use other (less standardized)
   calls to get a finer granularity. However, most of what is said
   about {\tt time()} applies for these too. 

\item
   The actual upper limit for these are the maximum length of a
   string, which is at least 2**32. So for all practical purposes, the
   limit is ``memory''.

\item
   The clock granularity is a bit of a problem to define. All systems
   can be trusted to have a granularity of about 1 second. Except from
   that, it's very difficult to say anything more specific for
   certain. Most systems allows alternative ways to retrieve the time,
   giving a more accurate result. Wherever these alternatives are
   available, {\regina} will try to use them. If everything else
   fails, {\regina} will use 1 second granularity. 

   For most machines, the granularity are in the range of a few
   milliseconds. Some typical examples are: 20 ms for Sun3, 4 ms for
   Decstations 3100, and 10 ms for SGI Indigo. Since this is a
   hardware restriction, this is the best measure anyone can get for
   these machines.  
\end{enumerate}
