How to use the PSF Toolkit.

1) Make a PSF specification.
Produce either one big file or several smaller ones.  The compiler runs
slightly faster if the specification is stored using a separate file for
each module.

2) Compile the specification to internal (TIL) code.
Compile the specification with

  psf filenames

If the specification contains no syntax or type errors, a file
'topmodulename.til' will be created, which contains the compiled
specification in TIL format.  Psf guesses which module is the top
module, unless it's specified using the -m option:

  psf -m topmodulename filename1 filename2 ....

Psf usually guesses correctly, though.

3) Use either one of the following tools to manipulate the specification:

3a) Test the term rewriting system induced by the data specification.
3b) Simulate the behaviour of the specified processes.
3c) Verify corectness of the specification. (This version of the PSF-Toolkit
    has only limited capabilities with respect to this point).

ad 3a) (see the manual pages for detailed operating instructions).
       Individual terms can be rewritten into normal form with the 'trs' tool.

	 trs topmodulename.til

       This command invocates the term rewriter. The input terms are read
       from the file 'topmodulename.trm' and the result is written to the
       file 'topmodulename.out'. If the file with input terms does not exist,
       the terms are read from standard input and the results are written to
       standard output.

ad 3b) Simulate the behaviour of a process using the sim tool.
       
	 sim topmodulename.til

       This program lets you interactively walk through the execution
       of the process. Select the process to simulate and the actions
       to trace (or select 'default trace') and then repeatedly
       choose the action to be executed. This choice can also be made
       using a random generator.

ad 3c) <to be supplied>

Notes:
i)    For using 'sim' the X window system must be active.
ii)   Sim will not handle specifications which involve the general
      sum and merge correctly.  Sometimes using the -s option to psf helps.
	--should be updated
iii)  The description provided above is short and incomplete. Refer to the
      user manuals (forthcoming) for a more thorough description.
      See [2], [3] or [4] for a detailed description of the PSF language.
      See [1] for a detailed description of data modules and the modular
      structure.

References
[1] J.A. Bergstra, J. Heering & P. Klint (eds.), Algebraic Specification,
    ACM Press Frontier Series, Addison-Wesley, 1989.
[2] S. Mauw, PSF: A Process Specification Formalism, PhD thesis, University
    Amsterdam, 1991.
[3] S. Mauw & G.J. Veltink, A process specification formalism, Fundamenta
    Informaticae XIII, pp. 85-139, 1990.
[4] S. Mauw & G.J. veltink, An introduction to PSFd, Proc. Int. Joint Conf.
    on Theory and Practice of Software Development, TAPSOFT '89, (J. Diaz,
    F. Oregas, eds.) LNCS 352, pp. 272-285, Springer verlag, 1989.


Appendix A: Libraries

It is possible to store a collection of often used (and possibly
pre-compiled) modules in a directory and use that as a kind of library.
Such modules must be stored one module per file. Moreover, there is a
strict way of naming a PSF file which depends on the name of the module it
contains.  The file name must be:  <module-name>.psf.  Compilations of the
module into the intermediate languages MTIL and ITIL may be stored in the
same directory, using the extensions .mtil and .itil, respectively.
The easiest way to obtain those files is probably to copy them from the
scratch directory in which psf leaves them after a successful compilation
(see the explanation of the PSFTMPDIR environment variable in the manual
page for psf).

To draw the attention of psf to the existence of such library directories,
set the PSFPATH environment variable to a colon-separated list of their names.
