%\docnum{SW-0429-8}
%\status{DRAFT}
% PC OCCAM 2.5 : This document is extracted with the permission of INMOS
% from their internal technical document SW-0429-8 to
% provide a definition of the language implemented by the PC occam
% compiler from Michael Poole, and by future INMOS occam toolsets.
% The document assumes familiarity with occam 2 and merely describes
% the additional features that have now been added to the language.
%
% The text below requires LaTeX library material not included here.
%
%
%       @(#)source      1.8     94/03/01 (C) INMOS Limited, 1994
%
%
%       Approval status:        DRAFT
%
\documentstyle{article}
\title{occam-2.5 definition}
\author{Conor O'Neill}
\date{1 March, 1994}
\newcommand{\occamthreerefman}{the draft Occam3 Reference Manual dated 23/3/1992}
\newcommand{\occam}{occam}
\newcommand{\s}{\hspace{0.5em}}
\renewcommand{\ss}{\hspace{1em}}
%\makeindex
%{{{  changes to make it process on the sun.  GB 24-Jan-91
%\printer{txa7:}
%\input{macrltex}
\newcommand{\bd}{\bf}
%\makeindex
%\newcommand{\pleasecomputerputapicturehere}[2]%
%{\dimen0\linewidth\advance\dimen0-4ex\advance\dimen0-2\fboxrule\insertmacdraw{#1}{\the\dimen0}{#2mm}{2ex}}
%}}}  

%{{{  new and better example and syntax environments plus fig
\makeatletter
\newenvironment{example}{\[\parbox{.9\textwidth}\bgroup}{\egroup\]\global\@ignoretrue}
\newenvironment{syntax}%
{\[\parbox{.9\linewidth}\bgroup\it\begin{tabular}{lccl}}%
{\end{tabular}\egroup\]\global\@ignoretrue}
\newenvironment{fig}{\[\parbox{\linewidth}\bgroup\begin{center}}{\end{center}\egroup\]\global\@ignoretrue}
\newenvironment{production}[1]%
{\parbox{\linewidth}\protect\bgroup\it\begin{tabular}{@{}l}\makebox[10em][l]{#1}%
\makebox[2em][c]{\rm=}\begin{tabular}[t]{l}}%
{\end{tabular}\end{tabular}\protect\egroup}
\makeatother
\newcommand{\vbar}{$|~$}
\newcommand{\bnfor}{\end{tabular}\\\makebox[10em]{}%
\makebox[2em][c]{$|$}\begin{tabular}[t]{l}}
\newcommand{\ob}{\{}
\newcommand{\cb}{\}}
\newcommand{\rep}[1]{$_#1$}
%}}}  
\newcommand{\bold}[1]{{\bf #1}}
\newcommand{\inmosl}{INMOS Limited}

\begin{document}

\maketitle
\renewcommand{\arraystretch}{1.1}
\copyright\ 1994 \inmosl
\footnote{\occam is a trademark of \inmosl}
\tableofcontents
%{{{  intro
\section{Introduction}
This document is reproduced by permission of \inmosl.
It is derived from their internal document SW-0429-8, dated 1st March 1994,
by omission of internal change notices and discussion of history.
It describes the proposed
language extensions to occam 2 which will be supported in the Dx405 release
of the INMOS occam toolset. These constitute a subset of the occam 3 extensions
which were proposed by Geoff Barrett in ``OCCAM 3 reference manual'' dated
31st March 1992.

This document should be read in conjunction with the occam 2 Reference Manual;
(``occam 2 Reference Manual'', Prentice Hall 1988 (ISBN 0-13-629312-3)).
In particular any syntactic extensions are described in terms of the syntax
as specified in the Reference Manual.

Additional language extensions supported by existing INMOS occam toolsets
but not in the Reference manual are also included in this document.
These were previously documented by INMOS in their internal
document SW-0044-12.

\section{Change history}

{\it Section omitted}

\section{Initial proposals}

{\it Section omitted}

\newpage
%}}}  
%{{{  \section{Named types}
\newpage
\section{Named types}

%{{{  \subsection{Description}
\subsection{Description}

Permit the programmer to name basic scalar (and array) types,
so that they can be referenced by more `abstract' and/or memorable names.

Named types provide enhanced type security because each named type
may not be mixed with any other inadvertantly.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This proposal is included directly from Geoff Barrett's work on occam 3.
See section 5.1 of \occamthreerefman.
%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

Geoff provides the following syntax:
(Note - Geoff's document has changed {\em type} to {\em data.type})

\begin{syntax}
definition & = & & {\tt DATA TYPE} name {\tt IS} type {\tt :} \\
\\
type       & = & & name
\end{syntax}

Named array tables are defined in a similar way to tables, except that
the name of the array type is written at the end as a type decoration:

\begin{syntax}
table      & = & & {\tt [} \{ 1 {\tt ,} expression \} {\tt ] (} type {\tt )}\\
\end{syntax}

New keywords: {\tt DATA}, {\tt TYPE}.

This has two real implications on parsing.
Parsing the basic type declaration is trivial.
However, now whenever a type may appear, we must permit a name also.

As far as I can tell, the affected situations (pre changes) are as follows:

%{{{  syntax list
\begin{syntax}
literal & = &     & integer {\tt (} type {\tt )} \\
	&   & $|$ & byte    {\tt (} type {\tt )} \\
	&   & $|$ & real    {\tt (} type {\tt )} \\
\\
declaration & = & & type \{ 1 {\tt ,} name \} {\tt :} \\
\\
simple.protocol & = & & type \\
\\
expression & = &     & {\tt MOSTPOS} type \\
	   &   & $|$ & {\tt MOSTNEG} type \\
\\
conversion & = & & primitive.type operand \\
	   &   & $|$ & primitive.type {\tt ROUND} operand \\
	   &   & $|$ & primitive.type {\tt TRUNC} operand \\
\\
specifier & = & & primitive.type \\
\\
formal & = &     & specifier \{ 1 {\tt ,} name \} \\
       &   & $|$ & {\tt VAL} specifier \{ 1 {\tt ,} name \} \\
\\
definition & = &     & \{ 1 {\tt ,} primitive.type \} {\tt FUNCTION} name {\tt (}
		       \{ 0 {\tt ,} formal \} {\tt )}\\
	   &   &     & {\tt ~~} function.body \\
	   &   &     & {\tt :} \\
	   &   & $|$ & \{ 1 {\tt ,} primitive.type \} {\tt FUNCTION} name {\tt (}
		       \{ 0 {\tt ,} formal \} {\tt ) IS} expression.list {\tt :} \\
\\
operand         & = &     & {\tt (} value.process \\
		&   & $|$ & {\tt )} \\
expression.list & = &     & {\tt (} value.process \\
		&   & $|$ & {\tt )} \\
\end{syntax}
%}}}  

The changes have the effect of changing all occurrences of {\em primitive.type}
in the above list to {\em type}, and {\em type} now includes {\em name}.

This, however, causes an ambiguity. Once named data types are included,
it is impossible to distinguish syntactically between
a type conversion and a function instance.
Both reduce to

\begin{example}
{\em name} {\tt (} {\em expression} {\tt )}
\end{example}

We resolve this issue by delaying the decision until contextual information
about the type of {\em name} is available. If it is a type name, it is
a conversion.

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

A named type introduces a new type with the same {\em structure} as the
type listed on the right-hand side.
These types, however, are not compatible, and may not be mixed
without an explicit type conversion.

%Two named data types are equal only when their references are equal.
%{\em (Note - This is Geoff's terminology -- what are `references' ?)}
Two named data types are equal only when they refer to the same
type declaration.
For example, in:

\begin{example}\begin{verbatim}
DATA TYPE AREA IS REAL32 :
AREA a, b :
REAL32 c :
\end{verbatim}\end{example}

the types of {\tt a} and {\tt b} are the same, but the type of {\tt c}
is different.
In:

\begin{example}\begin{verbatim}
DATA TYPE AREA IS REAL32 :
AREA a :
DATA TYPE AREA IS REAL32 :
AREA b :
\end{verbatim}\end{example}

the types of {\tt a} and {\tt b} are different because the two declarations
introduce different named types, even though they are spelt the same.

{\em Note - in this respect, named types behave identically to
named protocols.}

{\tt MOSTPOS} and {\tt MOSTNEG} may be applied to named types
which are derived from an integer type.
(Also {\tt BYTE}; see section \ref{mostposbyte}.)

A named array data type is not type-equivalent to any other similarly sized
named array data type. A consequence of this is that constructors for
named array data types must have the name of the type appended
as a type decoration, except where that type can be deduced, as described
in section \ref{typedliterals}.

%}}}  

%{{{  \subsection{Constraints}
\subsection{Constraints}

\begin{itemize}
\item
A type used in a named data type declaration must be a primitive data type,
another named data type, or an array of such, where the size of the array
must be compile-time constant.

\end{itemize}
%}}}  

%{{{  \subsection{Other points}
\subsection{Other points}

Named types must be exportable from separately compiled modules,
both as exported objects themselves, and in the parameter lists of exported
procedures and functions.
%Do we simply do the same as protocols here, and require the use of
%include-files?
%{\em My assumption is - Yes.}
We implement this in the same way as we currently do for protocols --
i.e. we require the use of include-files.

%}}}  

%}}}  

%{{{  \section{Record types}
\newpage
\section{Record types}
\label{recordtypes}

%{{{  \subsection{Description}
\subsection{Description}

A way to collect together related data and to refer to the collection
by means of a single name.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This proposal is included directly from Geoff Barrett's work on occam 3.
See section 5.2 of \occamthreerefman.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

\begin{syntax}
definition & = & & {\tt DATA TYPE} name \\
	   &   & & {\tt ~~} structured.type \\
	   &   & & {\tt :}
\\
structured.type & = & & {\tt RECORD} \\
		&   & & {\tt ~~} \{ declaration \} \\
\end{syntax}

New keywords: {\tt RECORD}.

Record literals (tables) are defined in a similar way to array tables,
except that the name of the record type is written at the end
as a type decoration:

\begin{syntax}
table      & = & & {\tt [} \{ 1 {\tt ,} expression \} {\tt ] (} type {\tt )}\\
\end{syntax}

Note that record fields are accessed with the same syntax as array subscripts.
The field name replaces the array index.

\begin{syntax}
element    & = & & element {\tt [} subscript {\tt ]} \\
subscript  & = & & expression \\
expression & = & & operand \\
operand    & = & & element \\
element    & = & & name \\
\end{syntax}

%{\em
%Note:
%Geoff now says: ``It may be better to adopt {\tt '} as the field
%selector rather than the syntax I suggested, or to insist that the first
%character of a field name is a period ({\tt .})''.
%I'm not sure what he means by the second part of that sentence.
%}

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

The declarations inside a {\em structured.type} must be simple data
declarations. No channels, timers, ports, procedures, functions,
protocols, etc, may be declared there.

Records may contain fields which are themselves records, but only by
creating a named type for the sub-record.
Records may contain fields which are arrays, and arrays of records
may be constructed.

The language does not specify anything about how the fields are actually
ordered and/or packed into memory.
An implementation may re-order fields, and insert padding between fields
and at the end of the record, to facilitate access to arrays of records.
(See section \ref{packedrecords} for methods of controlling the layout
of record structures in memory.)

Record literals, however, must have fields specified in the same order as
the fields are declared.

The same field name may be used in the definition of more than one
record type. The correct record type is deduced from context.
It is an error if the same field name is used more than once in a single
record type.
See also section \ref{protocolscope} with regard to scoping of protocol tags.

Zero length records are permitted.
It is not particularly clear whether they are useful.

A record may be used in more than one component of a parallel,
provided that different fields are used.

%}}}  

%{{{  \subsection{Other points}
\subsection{Other points}

A multiprocessor implementation may restrict the types of records
(and {\tt PACKED} records, see section \ref{packedrecords})
which may be communicated between different processors.
Typically, this will be because of word size, alignment,
and endian-ness issues.

Thus, for example, an implementation might restrict the use of records
containing {\tt INT} fields, or those which naturally align to different
boundaries on different wordlengths.
%}}}  

%}}}  

%{{{  \section{Packed Record types}
\newpage
\section{Packed Record types}
\label{packedrecords}

%{{{  \subsection{Description}
\subsection{Description}

Adds a mechanism for controlling the concrete representation of
{\tt RECORD} data types.
%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This permits a programmer to use {\tt RECORD} data types to map directly
onto externally specified data formats, such as those required by
external hardware, or communications protocols, etc.

Geoff proposes different mechanisms for this in Appendix D of \occamthreerefman.
However I find his syntax obscure, and the flexibility of {\tt WIDTH}
overly complex.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

\begin{syntax}
structured.type & = & & {\tt PACKED RECORD} \\
		&   & & {\tt ~~} \{ declaration \} \\
\end{syntax}

New keywords: {\tt PACKED}.

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

A record type may be declared as a {\tt PACKED RECORD}.
This type is then different from any similarly shaped {\tt RECORD}.
%The record type must be a data record type; {\tt PACKED} channel records
%are not permitted.

The fields of a {\tt PACKED RECORD} will be laid out in memory in the
order specified in the declaration of the record.
The implementation may not re-order fields,
nor may it introduce padding between fields, or at the end.

The layout of a nested field of {\tt RECORD} type is not specified
unless that type is {\tt PACKED}.
Otherwise it is unspecified which order the bytes of a multiple-byte field
are stored in memory.

An implementation may restrict the {\tt PACKED RECORD}s which it accepts;
an implementation may insist that data types are only placed
at appropriate boundaries,
or that {\tt BYTESIN} a {\tt PACKED RECORD} be a multiple of the machine's
word size.
However, any record declaration which is accepted must be treated as a
first class object; it may be assigned, and passed as a parameter, etc.

Note that it is vital that it is made clear in the documentation
and/or diagnostics
that there might be implementation restrictions here.

%}}}  

%{{{  \subsection{Other points}
\subsection{Other points}

Note that `direct' type conversion between {\tt PACKED} and non-packed
{\tt RECORD}s is not supported.
A user may supply explicit conversion functions, which perform
field-by-field copying.
See section \ref{fixedlengthfuncs}.

An implementation must define the size and alignment requirements of each
of the primitive types, together with user defined types, record types,
and arrays.

%}}}  

%}}}  

%{{{  \section{BYTESIN operator}
\newpage
\section{BYTESIN operator}
\label{bytesin}

%{{{  \subsection{Description}
\subsection{Description}

Permit access to the size of a data type (and/or variable), in bytes.
We also extend the semantics and syntax of the {\tt SIZE} operator
to permit it to be applied to user defined types.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This is needed to find out the size of a record type.
It is obvious that if implemented, it should not be restricted just to
record types.

I've just discovered that Geoff had already proposed this as
{\tt WIDTHOF}.
See section D.5 of \occamthreerefman.
I find {\tt WIDTHOF} to be counter-intuitive, and others have
agreed that they prefer {\tt BYTESIN}.

%In the absence of pointers, and dynamic memory allocation, etc,
%I cannot see any use for an {\tt OFFSETOF} operator.
%Is there one?
See also {\tt OFFSETOF} in section \ref{offsetof}.

Given that {\tt BYTESIN} should work on types, it seems obvious that
{\tt SIZE} should too.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

By analogy with the {\tt SIZE} operator, {\tt BYTESIN} should be simply a
monadic operator. However, this won't permit operating directly on
a type rather than on a item of a type.

\begin{syntax}
expression & = & & monadic.operator operand \\
\end{syntax}

Presumably this implies (though it is not specified):

\begin{syntax}
monadic.operator & = & & {\tt SIZE} $|$ {\tt +} $|$ {\tt -} $|$ ...
\end{syntax}

To permit {\tt SIZE} to operate on types, we must add:

\begin{syntax}
expression & = &     & {\tt SIZE} type \\
\end{syntax}

\begin{syntax}
operand & = &     & {\tt BYTESIN (} operand {\tt )} \\
	&   & $|$ & {\tt BYTESIN (} type    {\tt )} \\
\end{syntax}

%Should we insist on parentheses around the operand or type, to make it look
%like a function call?
Note the presence of parentheses around the operand or type.
This makes it look like a function call, and is why it is defined
as an {\em operand}, rather than an {\em expression}.

New keywords: {\tt BYTESIN}.

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

{\tt BYTESIN} returns an {\tt INT} containing the number of bytes
required to represent the type/object.

Consider

\begin{example}
{\tt x := BYTESIN ( } {\em expression} {\tt )},
\end{example}

For objects and expressions, this is equivalent to:

\begin{example}
{\tt VAL []BYTE temp RETYPES} {\em expression} {\tt :}\\
{\tt x := SIZE temp}
\end{example}

The value returned by {\tt BYTESIN} for a type will be the number of bytes
which are required when the type is used in an array.
Thus in a record type, it would include any trailing padding.
This also implies that, for all types:

\begin{example}
{\em {\tt BYTESIN ([}n{\tt ]} type{\tt )} == n * {\tt ( BYTESIN (}type{\tt ) )}}
\end{example}

It is invalid to apply the {\tt BYTESIN} operator to an object
whose size cannot be represented as an integral number of bytes.
This might occur because it is too large,
or because the object is not packed into an integral number of bytes,
eg. {\tt BOOL} objects might be packed into single bits.
({\em Note - this is no different than the current situation with
{\tt RETYPES}.})

{\tt SIZE} can now be applied to a type, including user defined types.
It is invalid to apply it to any type which isn't an array.
{\tt SIZE} returns the number of elements in the array.

{\tt BYTESIN} is syntactically an {\em operand},
(unlike {\tt SIZE} which is an {\em expression}),
so that it looks syntactically like a function call,
and doesn't need superfluous brackets when used in expressions.
Hence it may be used in circumstances where {\tt SIZE} is not permitted, eg:

\begin{example}
\begin{verbatim}
x := BYTESIN(a) + BYTESIN(b)  -- legal
x := SIZE a     + SIZE b      -- illegal
x := (SIZE a)   + (SIZE b)    -- legal
\end{verbatim}
\end{example}

%}}}  
%}}}  

%{{{  \section{OFFSETOF operator}
\newpage
\section{OFFSETOF operator}
\label{offsetof}

%{{{  \subsection{Description}
\subsection{Description}

An operator which returns the `offset' in bytes of any particular
field of a record or packed record type.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

Allow low-level manipulation of record types, to permit the use of
{\tt RETYPES} etc.
See also {\tt BYTESIN} in section \ref{bytesin}.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

\begin{syntax}
operand & = &     & {\tt OFFSETOF (} name {\tt ,} name {\tt )} \\
\end{syntax}

New keywords: {\tt OFFSETOF}.

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

{\tt OFFSETOF ( {\em type}, {\em name} )}
returns an {\tt INT} containing the number of bytes
(as determined by the implementation's layout of the record)
from the start of an object of record type {\em type} to the beginning of
field {\em name}.

It is invalid if {\em type} is not the name of a record or packed record type,
or if {\em name} is not a field of that record type.

It is invalid to apply the {\tt OFFSETOF} operator to a field
whose offset cannot be represented as an integral number of bytes.
This might occur because it is too large,
or because the field is not aligned to an integral number of bytes,
eg. {\tt BOOL} objects might be packed into single bits.

{\tt OFFSETOF} is syntactically an {\em operand},
so that it looks syntactically like a function call,
and doesn't need superfluous brackets when used in expressions.

\begin{example}
\begin{verbatim}
x := OFFSETOF(type1, field1) + OFFSETOF(type2, field2) -- legal
\end{verbatim}
\end{example}

%}}}  
%}}}  

%{{{  \section{Typed literals}
\newpage
\section{Typed literals}
\label{typedliterals}

%{{{  \subsection{Description}
\subsection{Description}

Permits scalar and array literals to have their type deduced from the
context in which they are written, so that a user does not need to
add the type decorations to literals.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

A common complaint among occam 2 programmers is that literals
(especially real-valued literals) are cumbersome to write because of
the need to follow each literal value with a type specifier.

In most cases the compiler could deduce this itself.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

The only syntactic change is to permit untyped real literals:

\begin{syntax}
literal & = &     & real \\
\end{syntax}

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

A type decoration may be omitted when there is only one decoration
which would type-check correctly.
In the following circumstances contextual information is used to deduce type:

\begin{itemize}

\item Inside a single expression.

%(We need to be careful about {\tt VALOF}s here!)
In this context, no information about expression types is passed either
`into' or `out of' a {\tt VALOF} expression.

\item Expressions in process constructs where only one data type is
permitted are assumed to have that type:

\begin{itemize}
\item Array size and subscript expressions must be of type {\tt INT}.

\item Start and length expressions of segments must be of type {\tt INT}.

\item Guards of conditional processes and loops, and boolean guards of
alternatives, must be of type {\tt BOOL}.

\item Start and length expressions of replicator variables must be of
type {\tt INT}.

\item Shift counts must be of type {\tt INT}.

\end{itemize}

\item Assignment and output use the types of the variables or
protocol of the channel.

\item In abbreviations, the type of the expression is inferred from
the type of the abbreviation.
This rule also applies to the actual parameters of functions and procedures.

\item
The types of expressions in a {\tt RESULT} list of a function use the
return type of the function.

\item
The types of constant expressions in a {\tt CASE} selection use the type of
the selecting {\tt CASE} expression.

\item
Expressions inside a {\em table} construct use the type of the known
context of the table, together with any optional literal decoration,
to deduce the types of each expression.

\end{itemize}

%}}}  
%}}}  

%{{{  \section{BYTE arithmetic}
\newpage
\section{BYTE arithmetic}
\label{bytearith}

%{{{  \subsection{Description}
\subsection{Description}

Permit the integer arithmetic operations on {\tt BYTE} variables.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

It is cumbersome to convert {\tt BYTE}s to {\tt INT}s and back again
every time it is required to do any arithmetic or bit manipulation.
These conversions may introduce many conversion checks.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

No extensions required.
%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

Arithmetic operations are permitted on {\tt BYTE}s as follows.
Overflow occurs (where applicable) when the value of the result
exceeds the range 0 to 255 inclusive.

\begin{tabular}{|c|l|l|}
\hline
\multicolumn{3}{|c|}{Monadic operators}\\
\hline
{\tt -}     & negation        & NOT permitted - meaningless\\
{\tt MINUS} & modulo negation & Eight bit two's complement\\
\verb|~|    & bitwise not     & Eight bit one's complement\\
\hline
\multicolumn{3}{|c|}{Conversion operators}\\
\hline
{\tt ROUND} & \multicolumn{2}{|l|}{round to nearest integer}    \\
{\tt TRUNC} & \multicolumn{2}{|l|}{truncate to nearest integer} \\
\hline
\end{tabular}

\begin{tabular}{|c|l||c|l|}
\hline
\multicolumn{4}{|c|}{Dyadic operators}\\
\hline
{\tt +}     & addition             & {\tt PLUS}  & modulo addition    \\
{\tt -}     & subtraction          & {\tt MINUS} & modulo subtraction \\
{\tt *}     & multiplication       & {\tt TIMES} & modulo multiplication \\
{\tt /}     & division             & {\tt REM}, \verb|\| & remainder \\
\verb|/\|   & bitwise and          & \verb|\/|   & bitwise or \\
{\tt ><}    & bitwise exclusive or & {\tt AFTER} & later than \\
{\tt >>}    & shift right          & {\tt <<}    & shift left \\
\hline
\end{tabular}

Note that {\tt AFTER} needs some further description.
`{\tt x AFTER y}' is specified as `{\tt (x MINUS y) > 0}' for all current
data types.
However, with an {\em unsigned} data type, the comparison against
zero succeeds for all non-zero values, making `{\tt x AFTER y}' equivalent
to `{\tt x <> y}'.
Instead, (for {\tt BYTE}s only),
we must effectively consider the result of the {\tt MINUS} operator
to be a signed type before comparing against zero, giving

\begin{example}
{\tt x AFTER y {\em ==} ((x MINUS y) > 0) AND ((x MINUS y) < 128)}\\
{\tt x AFTER y {\em ==} ((x MINUS y) MINUS 1) < 127}
\end{example}

Type conversions are permitted on {\tt BYTE} objects in the same way as
other integer types. Thus, conversion to and from {\tt REAL32} and
{\tt REAL64} are permitted, by using the {\tt ROUND} and {\tt TRUNC}
operators.
Note that conversions between {\tt BYTE} and the other integer types
are already permitted in occam 2.

%}}}  
%}}}  

%{{{  \section{MOSTPOS and MOSTNEG BYTE}
\newpage
\section{MOSTPOS and MOSTNEG BYTE}
\label{mostposbyte}

%{{{  \subsection{Description}
\subsection{Description}

Extend {\tt MOSTPOS} and {\tt MOSTNEG} to {\tt BYTE} types,
and those types derived from {\tt BYTE}.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This means greater abstraction; it is possible to use {\tt MOSTPOS}
and {\tt MOSTNEG} on named types without caring whether they are
implemented as an integer type or as {\tt BYTE}.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

No extensions required.
%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

{\tt MOSTPOS BYTE} evaluates to {\tt 255(BYTE)}.
{\tt MOSTNEG BYTE} evaluates to {\tt 0(BYTE)}.

%}}}  
%}}}  

%{{{  \section{FUNCTIONs returning fixed-length objects}
\newpage
\section{FUNCTIONs returning fixed-length objects}
\label{fixedlengthfuncs}

%{{{  \subsection{Description}
\subsection{Description}

{\tt FUNCTION}s should be permitted to return records, and fixed
length arrays.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

It is obvious that {\tt FUNCTION}s must be able to return user-defined
types to be usable.
Given this, they should be able to return record types,
and arrays whose size are known at compile-time.
Note that such arrays can be considered to be homogeneous records.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

The type returned from a {\tt FUNCTION} may be any type, rather than
just a {\em primitive.type}.

\begin{syntax}
definition & = &     & \{ 1 {\tt ,} type \} {\tt FUNCTION} name {\tt (}
		       \{ 0 {\tt ,} formal \} {\tt )}\\
	   &   &     & {\tt ~~} function.body \\
	   &   &     & {\tt :} \\
	   &   & $|$ & \{ 1 {\tt ,} type \} {\tt FUNCTION} name {\tt (}
		       \{ 0 {\tt ,} formal \} {\tt ) IS} expression.list {\tt :} \\
\end{syntax}

(Note that this change is already subsumed in the changes permitting
user defined types.)

We also must change the syntax of an {\em operand}, so that functions
can return arrays and records which can then be subscripted:

\begin{syntax}
operand & = & & operand {\tt [} subscript {\tt ]}
\end{syntax}

(Note that Geoff proposed that {\em expressions} should be subscripted,
rather than {\em operands}, but he has agreed that {\em operands} are better,
because this reduces the need for `superfluous' brackets when used inside
more complex expressions.)
%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

Same as {\tt FUNCTION}s returning scalar variables.
All the aliasing rules still apply.

Since the sizes of the results are known at compile-time, the compiler
can allocate temporaries if required.

Since a {\tt FUNCTION} can return an object of array or record type,
the function call may be subscripted directly.

%}}}  

%{{{  \subsection{Other points}
\subsection{Other points}

It may be that we have to do some work to make this efficient:
In many cases where a temporary might be used, without too much cost,
for scalar types, this will be unsatisfactory for array types,
because of the repeated copying which this implies.
Therefore, the compiler must attempt to remove the temporaries.

An example might be a user routine written as follows:

\begin{example}\begin{verbatim}
[n]INT FUNCTION double.array(VAL [n]INT arg)
  [n]INT temp :
  VALOF
    SEQ i = 0 FOR n
      temp[i] := arg[i] * 2
    RESULT temp
:
[n]INT x :
x := double.array[x]
\end{verbatim}\end{example}

In a naive implementation, this will involve assembling the result in
{\tt temp}, then copying this to the actual result,
which may also be a temporary, in the {\tt RESULT} statement.
There might then be a final copy to the real result.
In the example just given, this will require two copies.

Since the aliasing rules of our implementation of occam imply that
the formal result parameter of the call (which is passed as a pointer)
cannot alias the formal parameter, the compiler is permitted to
remove {\tt temp} entirely, and to use the formal result parameter
directly.
In the previous example, this will remove one of the array copies.

A heuristic might be:
if a local variable is declared inside the function,
  and is returned directly as a {\tt RESULT},
  and the size of that variable is larger than some cutoff size,
then the local variable is removed
  and all references to it are replaced with references to the
  formal result variable.

%}}}  

%}}}  

%{{{  \section{Dropping FROM and FOR in segments}
\newpage
\section{Dropping FROM and FOR in segments}

%{{{  \subsection{Description}
\subsection{Description}

Permit either the {\tt FROM} phrase or the {\tt FOR} phrase (not both)
to be dropped from segments of arrays.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

Typographical convenience in the common cases where the start ({\tt FROM})
value is 0, or the length ({\tt FOR}) value is the `rest of the array'.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

\begin{syntax}
element & = &     & {\tt [} element {\tt FROM} subscript {\tt FOR} count {\tt ]}\\
	&   & $|$ & {\tt [} element                      {\tt FOR} count {\tt ]}\\
	&   & $|$ & {\tt [} element {\tt FROM} subscript                 {\tt ]}\\
\\
table   & = &     & {\tt [} table   {\tt FROM} subscript {\tt FOR} count {\tt ]}\\
	&   & $|$ & {\tt [} table                        {\tt FOR} count {\tt ]}\\
	&   & $|$ & {\tt [} table   {\tt FROM} subscript                 {\tt ]}\\
\end{syntax}
%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

When the {\tt FROM} part is omitted, this is inferred to be constant zero.

When the {\tt FOR} part is omitted, this is inferred to mean
`the rest of the array'. Thus

{\em {\tt [} name {\tt FROM} start {\tt ]}}
is equivalent to:
{\em {\tt [} name {\tt FROM} start {\tt FOR} {\tt ( SIZE} name {\tt ) -} start {\tt ]}}

%}}}  
%}}}  

%{{{  \section{RESHAPING arrays}
\newpage
\section{RESHAPING arrays}

%{{{  \subsection{Description}
\subsection{Description}

Provide a new operator {\tt RESHAPES}, with similar syntax to {\tt RETYPES}.
Permit an array item to be {\tt RESHAPE}d into an array of the same base type,
where one or more dimension has a size which is variable,
provided that the total size is still equal to the size of the right-hand-side.
The number of dimensions of the left-hand-side does not need to be identical
to that of the right-hand-side.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This allows `re-shaping' arrays into other shapes.
This is useful when an array is available as a `scratch area', but must
be used as a temporary array of a different shape.

Note that the use of the word {\tt RESHAPES} rather than {\tt RETYPES}
is because this construct does not rely on bit pattern `punning', etc,
it relies purely on the (documented) layout of arrays as contiguous
regions of memory. As such, the use of {\tt RESHAPES} does not make
a program non-portable.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

\begin{syntax}
definition & = &     & specifier name {\tt RESHAPES} element {\tt :} \\
	   & = & $|$ & {\tt VAL} specifier name {\tt RESHAPES} element {\tt :} \\
\end{syntax}

New keywords: {\tt RESHAPES}.

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

The compiler will calculate the size of the {\tt RESHAPE} by multiplying
together the sizes of all known dimensions, whether they are constant
or variable. One `open' dimension is permitted.

It is invalid if the base type of the new array is not the same as the
base type of the old array.

It is invalid if the size of the new array specified is not equal
to that of the old.

As in the current implementation of {\tt RETYPES}, it is an error
if any dimension of an array cannot fit in an {\tt INT}.
In some cases, this will require a run-time check.

%}}}  
%}}}  

%{{{  \section{Scoping of PROTOCOL tags}
\newpage
\section{Scoping of PROTOCOL tags}
\label{protocolscope}

%{{{  \subsection{Description}
\subsection{Description}

The tags used in a variant {\tt PROTOCOL} are currently included
as globally visible names.
Since these cannot be used except in a communication, they could
be scoped into a private namespace for each {\tt PROTOCOL}
(aka {\tt RECORD}s).

This would be an upwards-compatible change, and would not affect
any purely-occam code.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This is proposed to simplify the writing of programs with many protocols,
and to provide consistency with record field names
(see section \ref{recordtypes}).

This proposal is included directly from Geoff Barrett's work on occam 3.
See section 6.4.4 of \occamthreerefman.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

No changes.
%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

{\tt PROTOCOL} tags are not visible to the programmer, except in certain
contexts:

\begin{itemize}
\item As part of a channel output expression.
\item As part of a tagged channel input expression.
\item As part of a variant channel input expression.
\end{itemize}

In each case, the scoping of the tag
is determined from the protocol of that channel.

%}}}  

%{{{  \subsection{Other points}
\subsection{Other points}

There is an existing undocumented ability to read {\tt PROTOCOL} tag
values as if they were {\tt BYTE} constants. This will not be supported
in occam 2.5.

%}}}  

%}}}  

%{{{  \section{Constant fold `single-line' FUNCTIONs}
\newpage
\section{Constant fold `single-line' FUNCTIONs}

%{{{  \subsection{Description}
\subsection{Description}

Specify that `single-line' {\tt FUNCTION}s 
may be used where compile-time constants are required,
when all parameters and free variables are compile-time constants.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

Permits better abstraction for the programmer.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

No changes.
%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

We must extend the definition of `compile-time constant' to include
appropriate (`single-line')\\
{\tt FUNCTION}s.

(We probably have to first establish what the existing rules
are for `compile-time constant'.)

%}}}  

%}}}  

%{{{  \section{INLINE routines}
\newpage
\section{INLINE routines}
\label{inlining}

%{{{  \subsection{Description}
\subsection{Description}

The keyword {\tt INLINE} may be used in conjunction with {\tt PROC}
and {\tt FUNCTION} as a hint to the compiler that a routine should
be inlined. The compiler is not {\em required} to actually support this,
but it should accept the keyword.

This enhancement has previously been implemented in INMOS's occam 2 compilers.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

Permits better abstraction for the programmer.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

\begin{syntax}
definition & = &     & \{ 1 {\tt ,} type \} [ {\tt INLINE} ] {\tt FUNCTION} name {\tt (}
		       \{ 0 {\tt ,} formal \} {\tt )}\\
	   &   &     & {\tt ~~} function.body \\
	   &   &     & {\tt :} \\
\\
	   &   & $|$ & \{ 1 {\tt ,} type \} [ {\tt INLINE} ] {\tt FUNCTION} name {\tt (}
		       \{ 0 {\tt ,} formal \} {\tt ) IS} expression.list {\tt :} \\
\\
	   &   & $|$ & [ {\tt INLINE} ] {\tt PROC} name {\tt (} \{ 0 {\tt ,} formal \} {\tt )}\\
	   &   &     & {\tt ~~} procedure.body \\
	   &   &     & {\tt :} \\
\end{syntax}

New keywords: {\tt INLINE}.

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

The compiler is advised by the programmer that this routine is a good
candidate for `inline expansion' whereever that routine is called.
The semantics of the call are otherwise identical to any normal call.

Note that the {\em declaration\/} of the routine is marked with the keyword,
but each {\em call\/} site is affected.

%}}}  

%}}}  

%{{{  \section{Channel RETYPEing}
\newpage
\section{Channel RETYPEing}
\label{channelretype}

%{{{  \subsection{Description}
\subsection{Description}

Channels may be {\tt RETYPE}d to and from channels of a different protocol.

This enhancement has previously been implemented in INMOS's occam 2 compilers.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This is sometimes required when accessing specific hardware,
in a similar manner to data {\tt RETYPES}.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

No changes.
%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

A channel may be {\tt RETYPE}d to another channel of a different protocol.
{\tt VAL RETYPES} are not permitted.

%}}}  

%}}}  

%{{{  \section{Channel constructors}
\newpage
\section{Channel constructors}

%{{{  \subsection{Description}
\subsection{Description}

Arrays of channels may be constructed out of a list of other channels.

This enhancement has previously been implemented in INMOS's occam 2 compilers.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This makes it easier to use 'generic' routines which manipulate arrays
of channels, from existing individual channels.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

No changes.
%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

A channel constructor creates an array of channels out of existing channels.
The array may be subscripted, etc, and used like any other array of
channels. All channels in the array must be used in the same direction.

%}}}  

%}}}  

%{{{  \section{PROTOCOL name IS ANY}
\newpage
\section{PROTOCOL name IS ANY}
\label{protocolnameisany}

%{{{  \subsection{Description}
\subsection{Description}

The anarchic protocol {\tt ANY} may now be specified as part of
a named, sequential, or variant {\tt PROTOCOL}.
It indicates that a single data item
of any type may be communicated as part of that protocol.

This enhancement has previously been implemented in INMOS's occam 2 compilers.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This permits a programmer to distinguish effectively and securely
between two different anarchic protocols, by giving them different
protocol names.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

\begin{syntax}
simple.protocol & = & & {\tt ANY}\\
\end{syntax}

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

A single communication of type {\tt ANY} on a channel as part of a
larger communication of named protocol is treated exactly like that
of a {\tt CHAN OF ANY}, as described in section 4.3.5 of the
occam 2 Reference Manual.

%}}}  

%}}}  

%{{{  \section{Allocations}
\newpage
\section{Allocations}

%{{{  \subsection{Description}
\subsection{Description}

{\em Allocations} must be written immediately after the declaration
to which they refer.

{\em Note:} This is a change from strict occam 2 behaviour.
However, a minor source code edit will always permit the code to be
accepted.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

The occam 2 Reference Manual does not place any constraints on the location
of an {\em allocation} when it described them in section A.3.
We propose to enforce that the allocation is written immediately after
its referenced declaration.
This ensures that a compiler can process the allocation before processing
any uses of that declaration.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

No change.

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

An {\em allocation} must occur immediately after the {\tt declaration}
to which it refers. The only intervening syntactic entities which may
occur are other {\em allocation}s of names declared in the same
{\em declaration}.

%}}}  

%}}}  

%{{{  \section{Counted array input}
\newpage
\section{Counted array input}

%{{{  \subsection{Description}
\subsection{Description}

The semantics of counted array input are not exactly the same as those
described in the occam 2 Reference Manual.
A counted array input of the form

\begin{example}
{\tt message ? len :: buffer}
\end{example}

is no longer permitted to refer to the {\tt len} as part of the expression
{\tt buffer}.

{\em Note:} This is a change from strict occam 2 behaviour.

%}}}  

%{{{  \subsection{Rationale}
\subsection{Rationale}

This makes it possible to treat the input as a single input,
which communicates the data and the length of the data as a single item.

%}}}  

%{{{  \subsection{Syntax}
\subsection{Syntax}

No change.

%}}}  

%{{{  \subsection{Semantics}
\subsection{Semantics}

\begin{example}
{\tt message ? len :: buffer}
\end{example}

This input receives an integer value which is assigned
to the variable {\tt len}, and that number of components, which are assigned
to the first components of the array {\tt buffer}. The assignments to
{\tt len} and {\tt buffer} happen in parallel and therefore the same rules
apply as for parallel assignment.  That is, the name {\tt len} may not appear
free in {\tt buffer}, and vice versa.

%}}}  

%{{{  \subsection{Backwards compatibility}
\subsection{Backwards compatibility}
\label{countedarraybackwards}

As a concession to backwards compatibility, the compiler permits
communications of the form:
   
{\em channel.exp} {\tt ?} {\em name} {\tt :: [} {\em array.exp}
{\tt FROM 0 FOR} {\em name} {\tt ]}

These are transformed into the equivalent form:

{\em channel.exp} {\tt ?} {\em name} {\tt ::} {\em array.exp}
%}}}  

%}}}  

%{{{  \section{Future directions}
\newpage
\section{Future directions}

%{{{  \subsection{CHAN OF ANY}
\subsection{CHAN OF ANY}

{\tt CHAN OF ANY} should be considered obsolete;
it should be replaced by a named {\tt PROTOCOL}
(which may be of type {\tt ANY}), to give greater security.
See section \ref{protocolnameisany}.

%}}}  

%{{{  \subsection{Counted array input}
\subsection{Counted array input}

The ability to name the length of a counted array input as the length
of the receiving buffer is obsolescent. The programmer should rewrite
the statement using the equivalent form.
See section \ref{countedarraybackwards}.

%}}}  

%}}}  

\end{document}
