                        PCN Release 2.0


Outstanding Bugs and Planned Additional Features
================================================

This file contains a list of outstanding bugs in this release and some
additional features that we plan to add in future releases.

PCN compiler bugs include:

------------------------------------------------------------------
  The use of a mutable as the size in an array declaration could cause
a race condition.  For example:

	p(s)
	int s;
	int a[s];
	{...} 

Could cause a race condition on the use of 's' in determining the size
of array 'a'.

Workaround: Always use definitional variables for the array size.  In
the above example, this means either simply changing 's' to be a
definitional variable, or wrapping a procedure around p() to do the
conversion, such as:

	p(s)
	int s;
	{;  def_s = s, p_1(s, def_s) }
	p_1(s, def_s)
	int s;
	int a[def_s];
	{...} 
------------------------------------------------------------------
  Expressions with variables in array declaration sizes are not yet
supported.  However, constant integer expressions are.  Therefore,
this will not work:
	p(s)
	int a[1+s];
	{...} 
but this will:
	#define SIZE 1
	p()
	int a[1+SIZE];
	{...} 
------------------------------------------------------------------
  An error message should be generated if `default' is not the last
gaurd in a choice block instead of having the compiler crash.
------------------------------------------------------------------
  Lint (the first code checking stage of the compiler) should print
file and line numbers in its messages.
------------------------------------------------------------------
  Doesn't support variable expressions in mutable array declarations.
For example, allow the following declaration of integer array 'i':
	p(a,b)
	int i[a+b];
	{...}
  Note: Constant expressions are supported, such as:
	p()
	int i[1+2];
	{...}
------------------------------------------------------------------
  Allow for the following: ``x = length("hello")'' instead of making
the user do ``w = "hello", x = length(w)''
------------------------------------------------------------------
  Having "t[0] ?= {whatever}" in a guard does not work, because the
PCN grammer does not allow for subscripted variables on the left hand
side of the match operator (?=).
------------------------------------------------------------------
  Building large tuples or lists in a procedure can cause the compiler
to give the following error message:
	Error: Subroutine too large: getmodules
This affects code such as:
	p(t)
	{||
		t = [1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,2,3,4,5,6,7,8,9,0,98,8,7,6,5,4,3,2,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,2,3,4,5,6,7,8,9,0]
	}

  Note: This does NOT mean there is a limit to the size of tuples, but
only that you cannot create large tuples at compile time in this way.

The workaround is to break the tuple creation into pieces and spread
it across multiple procedures.  For example:
	p(t)
	{||
		p1(t, t1),
		p2(t1, t2),
		p3(t2, [])
	}
	p1(t_b, t_e)
	{||
	    t_b = [1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,1,2,3,4,5,6,7,8,9 | t_e]
	}
	p2(t_b, t_e)
	{||
	    t_b = [0,9,8,7,6,5,4,3,2,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,2,3,4,5,6,7,8,9,0,98,8,7 | t_e ]
	}
	p3(t_b, t_e)
	{||
	    t_b = [6,5,4,3,2,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,1,2,3,4,5,6,7,8,9,0,9,8,7,6,5,4,3,2,1,2,3,4,5,6,7,8,9,0 | t_e]
	}
------------------------------------------------------------------



Other, bugs/future features include:

------------------------------------------------------------------
  On some machines (NeXT running 3.0, Sequent Symmetry running Dynix
(not PTX), fprintf() does not return the number of characters that
were printed.  On these machines, stdio:fprintf() is hacked to return
non-zero upon non-failure so that it is at least somewhat compatible
with other machines.  However, the returned value may not be correct.
The PCN_FPRINTF_HACK flags is used in the config file to turn this on.
------------------------------------------------------------------
  The temporary C file that is output by pcnlink is quite large -- sometimes
large enough to break the C compiler on some machines (symmetry, rs6000, 
ipsc860).  The following needs to be done to alleviate this problem:
	1) Remove duplicate constants
	2) Split up the single pcnt.c file into multiple files
------------------------------------------------------------------
  The X windows based Gauge interface still has some display bugs.  It
also isn't as portable as the rest of the system -- it won't compile
cleanly on some machines.
------------------------------------------------------------------

