@c "chapters/types.texi"
@c $Id: types.texi,v 1.1 2007/08/20 00:02:49 fang Exp $

@node Types
@chapter Types
@cindex types

In @HAC{}, there are four classes of types to use:
parameters, datatypes, channels, and processes.  

@menu
* Parameters::
* Definitions::
* Definition Completeness and Usability::
* Definition Future extensions::
@end menu

@c ----------------------------------------------------------------------------
@node Parameters
@section Parameters
@cindex parameters, template
@cindex template parameters

Parameters differ from the others in that they don't correspond
to any physical instances; they are merely user-manipulated values.  
Currently, there are only two (built-in) parameter types: 
@pint{}, which is an integer value,
and @pbool{}, which is a boolean value.  

Parameters may be set no more than once, and they must be 
initialized before they are used.  
Using uninitialized parameters is an error.  


We cover templates more in-depth in @ref{Templates}.
@HAC{} supports parametric types, or templates, much like C++. 
Terminology: a template definition (or just template)
is a parameterized definition.  
User-defined datatypes, channels, and processes may be parameterized.  
Currently the only types that may appear in template signatures
are parameters and arrays thereof.  
Later we may add support for template template arguments, muahahaha.  

@c ----------------------------------------------------------------------------
@node Definitions
@section Definitions
@cindex definitions
@cindex type definitions

random notes, please pardon the lack of order...
we really need to re-organize this document, I know.

Consider introducing templates up front...

Describe definition and type-system, bottom-up, from instantiations?

@strong{TODO:} make the following distinctions:
A physical definition corresponds to the complete description of
a particular implementation.  
Physical definition has its own 
@emph{concrete layout map} 
@cindex concrete layout map
that translates name (possibly with index) to offset.  
(Users never directly deal with concrete layout maps.)  
Non-template definitions have only one trivially-generated 
concrete layout map.  
Template definitions, however, may have multiple @emph{layout map templates}, 
among which one is selected to generate a concrete layout map for
each instantiation.  
Layout templates are just value- and type-parameterized layout descriptions.  
(Multiple layout templates arise from partial and full specializations; 
a generic template definition contributes one layout template.)


A @emph{type} can either be a reference to a non-template definition
(which may be built-in) or a reference to a template definition
with a set of parameters.  

@strong{STALE:}
Two (non-template) types are equivalent if and only if 
they refer to the same non-template definition.  
In @ref{Templates} we extend the notion of type-equivalence
to cover types with templates.  

@menu
* Definition Physical Layout::
* Definition Names::
@end menu

@c ----------------------------------------------------------------------------
@node Definition Physical Layout
@subsection Physical Layout
@cindex definition layout

Definitions of physical entities invariably contain some table mapping
a logical member or port name to the location of the desired member.  
Such is the typical implementation of data structures in traditional
programming languages.  
Non-template definitions have only one table.  

@ref{Templates} discusses how templates affects this 
view of structures' layout tables.  
Template definitions introduce @emph{table-templates}
(necessary when members' types and sizes depend on template parameters).  
Each complete template definition (all arguments supplied) 
uses follows one table-template to generate a final layout table.  

@c ----------------------------------------------------------------------------
@node Definition Names
@subsection Names
@cindex definition names

The @emph{name} of a plain non-template definition refers to the
one definition only.  (OK, that made no sense whatsoever.)
The name of a template definition, however, refers to a @emph{family}
of definitions.  

@c ----------------------------------------------------------------------------
@node Definition Completeness and Usability
@section Completeness and Usability
@cindex complete type
@cindex type completeness

In @HAC{}, there are three levels of completeness for definitions.  

@enumerate
@item A definition is @emph{declared}
	if its template signature (which may be empty) has been defined.  
	Forward declarations of a type only specify the name
	and template parameters, and no other information.  
@item A definition is @emph{signed} if it is declared 
	and its public ports interface (which may be empty) has been defined.  
@item A definition is @emph{defined} if it is signed
	and its body has been defined.  
@end enumerate

NOTE: what about definition bindings?

Since type information only refers to template parameters, 
a type may refer to any declared definition.  

@menu
* Definition Instantiation::
* Definition Connection::
* Definition Typedefs::
@end menu

@c ----------------------------------------------------------------------------
@node Definition Instantiation
@subsection Instantiation

An instantiation is the creation of definition into a physical object.  

@c ----------------------------------------------------------------------------
@node Definition Connection
@subsection Connection

@xref{Connections}.

@c ----------------------------------------------------------------------------
@node Definition Typedefs
@subsection Typedefs

@xref{Typedefs}.

@c ----------------------------------------------------------------------------
@node Definition Future extensions
@section Future extensions

Support @samp{typeof()} operator and @samp{sizeof()} operator.  

