                The ASpecT System V2.0


                     An Overview
                    -draft 01/92-





                   Joern von Holten


                   
                  University of Bremen

                  aspect@ubrinf@unido




Requirements
------------

The ASpecT System is running on several machines because one of the design
criterias is easy portability. Thus the C code generated by the system is
compatible to the ANSI standard and to the Kernighan/Ritchie style.
Currently the system has been ported to the following platforms:

- SUN workstations. The system has been developed on SUN 3/50 and SUN 3/60
  workstations running SunOS (UNIX). Recently is has been moved to SPARC SLC
  with only some problems concerning the calling conventions on a SPARC
  architecture (these problems have now been fixed). It is running on other
  compatible SUN SPARC architectures too (i.e. SUN SPARC ELC, SUN-4/75).
  A C compiler is required. We use the SUN cc compiler or the GNU C compiler.
  We have no experience with other C compilers running on SUN machines now.

- VAX, microVAX. The system has been moved to a VAX computer running UNIX.
  We used the standard C compiler (cc).

- MacIntosch IIfx. The system has been compiled on a MacIntosh IIfx running
  UNIX. We used the GNU C compiler.

- IBM RS6000. The system has been moved to a IBM RS6000 running UNIX. We
  used the GNU C compiler.

- NeXT. The system has been moved to a NeXT running MACH. We used the GNU C
  compiler.

- AMIGA. A former version has been moved to an AMIGA computer. We tried
  the AZTEC and the Lattice C compiler with no problems. A GNU C compiler is
  available for AMIGA too but it has not been tested now.
  Compiling relative large programs (more than 2000 Lines) makes problems
  on an AMIGA without memory extensions.

- IBM PC. A former version has been moved to an IBM AT computer running 
  MS-DOS 3.3. We used Microsoft C 5.0 with no problems. The IBM computer
  should have at least 1.5 MB memory.

It is planned to transfer the system on an ATARI ST.

Our experience showed that the installation of the system on a machine with
at least 1 MB main memory and a standard C compiler is just a question of
moving the C sources to this machine and run the generated batch files -
the ASpecT system has an installation mode which is used to generate the
C sources in a filesystem independent way. A batch file for the compilation
and linking of the C files on the target system may be generated too. The
only thing which has to be changed (re-designed) is the system description
file.



Inhomogenous network with shared filesystem
-------------------------------------------

The system may even run on a network of different machines (i.e. SUN SPARC,
SUN 3/60, VAX and MacIntosh). In such a case the executables and object files
are different of cause. On a specific machine a special directory is linked
where the executables of the ASpecT system and the system description file
(defaults.cmd) is found. While starting the ASpecT system, it would then read
the respective system description. It is a good idea to have special postfixes
for the object files on the different systems (i.e. xyz.4.o (SUN SPARC) or 
xyz.3.o (SUN 3/60) or xyz.nx.o (NeXT) or xyz.mac.o (MacIntosh)).
While compiling the ASpecT sources on a different machine - assuming it has
been compiled and ready to run on another machine - the ASpecT make tool would
only recompile the C files and re-link.




The system components
---------------------

The ASpecT system consists of some components (man-pages are available)

- scanner/parser
- C generator (including a termination check)
- make utility
- runtime library (including the debugger)
- standard library


The scanner/parser
------------------
As the name states the scanner/parser component is used to check ASpecT
sources syntactically and semantically. A special make feature is included
into this component which checks included modules as well.

The C generator
---------------
This component is used to translate the internal forms (produced by the 
scanner/parser) into C programs. Before that several optimisations are
done including
- efficient compilation of pattern matching
- actualisation of the modules (we have code sharing)
- common subexpression elimination, code fusion/motion, unfold
- optimising the memory management (ASpecT uses reference counts, the
  garbage collection is done 'on the fly').
- recursion removal
- sharing/reusage analysis
On command the C generator includes the code for the debugger.
The C generator also contains a termination check which can be invoced
on request. This check performs a kind of recursive path ordering on the
program and shows up probably non-termination calls. The termination
check is currently under development and is subject of major improvements.

The make utility
----------------
Due to the complex dependencies in ASpecT programs (actualisations, local
imports) a programmer would be overcharged to have all these in mind or
even write a makefile for use with standard (UNIX) make utilities. Therefore
a special make utility is the central component of the ASpecT system.
The make utility reads a special system describtion file which includes
informations which describe
- a command mask how to invoce the other components, the 
  C compiler and the linker
- the used postfixes and the dependencies between them
Such a system description may vary from source to source to have the
possibility to link special libraries (i.e. X-lib, yacc, ...) if one uses
the EXTERN feature of the ASpecT language.
Futhermore some environment variables are read which informs the make
utility
- where to search for the source files (like the path-variable in UNIX)
- about some very special system features (i.e. where a backslash (/) is
  used under UNIX to seperate the path you have to use the forward-slash (\)
  under MS-DOS).
The make utility then checks the involved files and initiates the required
actions. Seperate compilation is performed of cause.
The make utility has some command line switches for
- compiling some modules in non-debugger/debugger mode
- generating a batch file instead of executing the commands
- going into an 'installation mode' (used while porting a program)

The runtime library
-------------------
The runtime library consists of some C files which contains the stuff needed
to run ASpecT programs.
The debugger is a part of the runtime library too (it is linked with the
executables on demand as stated in the system description file).
The debugger is called by special calls which are compiled into the modules
by the C generator. This means that it is possible to include the debugger
only in some of the modules. The others are executed in full speed.
The debugger stops the execution of the program and the user has the following
common possibilities (some of them)
- step to the next call
- skip to a given call level (a level is the nesting depth of the calls)
- set/remove breakpoints (on the call of a function)
- leap to the next breakpoint
- print the current term (a term depth can be set and is used to shorten 
  large terms)
- show the call stack  
- 'walk' into a term (to view special subterms in detail)
- call an interpreter (very rudimental since overloading and other features
  are not resolved yet - this would require to include large parts of the
  scanner/parser)
- show the type of a term
Unlike other systems functionals are not printed as ("<functional>") but in
detail.


The standard library
--------------------
The standard library is a collection of several source files which realise the
most common datatypes. A short overview is given next:

- Boolean.     everything needed for booleans (i.e. not, (&&) ...). Booleans
               are a built in sort in ASpecT (because of the built in lazy
               if-function) and most of the functions included here are
               written in C.
- Integer.     everything needed for integers (i.e. (+), (-) ...). Integers
               are a built in sort in ASpecT (due to scanning) and most of
               the functions included here are written in C.
- Char.        everything needed for chars. Chars are a built in sort in
               ASpecT (due to scanning) and most of the functions included here
               are written in C.
- String.      everything needed for strings. Strings are a built in sort in
               ASpecT (due to scanning) and most of the functions included here
               are written in C.
- System.      everything one needs to access the surrounding system (i.e.
               input, output, ...)
- Lists.       Common list functions (including those which are included in
               the Miranda standard environment)
- Functionals. Common functionals (map,fold,reduce,filter,function composition,
               zip, find, fixp, ...)
- Array.       a special implementation of an external sort array is realised
               which combines referential transparence and efficiency.

Futhermore there are modules realising Sets, Stacks, Queues, rational numbers,
streams, graphs and sorted lists just to name a few as well as special
algorithms realising sorting, hashing etc.

