COMMENT ⊗   VALID 00013 PAGES 
RECORD PAGE   DESCRIPTION
 00001 00001
 00003 00002	This file contains some descriptions of some known bugs which have not
 00004 00003	1. Calling  a parametric procedure whose actual is not in the same file
 00006 00004	2. FOREACH searches with one ELEMENT ANY and one unbound local sometimes
 00008 00005	3. Calling a procedure with an expression where a reference parameter is
 00010 00006	4. There is no way to use a derived set simply within a FOREACH context.
 00011 00007	5. ERASES  sometimes cause havoc within foreaches.
 00013 00008	7. PROFIL does not seem to know about CONTINUE's which exit the current
 00014 00009	8. Reference variables and global variables kept in ac's cause problems.
 00016 00010	9. ON "FATAL END OF SOURCE" error message, gives line within page (+1)
 00017 00011	10. With /H (HISEG) compilation, own arrays whose virtual origin is before
 00019 00012	11. IDPB, DPB should do an ALLSTO(?)
 00020 00013	12. No check is made that the formals to a procedure passed as a parameter
 00021 ENDMK
⊗;
This file contains some descriptions of some known bugs which have not
been fixed either because it is not known how to fix them or it is
more trouble to fix them than they are worth.

1. Calling  a parametric procedure whose actual is not in the same file
   and is not SIMPLE or an outer block procedure will cause an infinite
   loop in the procedures prologue because the static link cannot be
   calculated by following the current static link.
   E.G.

   Program 1:
   BEGIN "PRG1"
	EXTERNAL PROCEDURE FOO(PROCEDURE BAZ);
	REQUIRE "PRG2" LOAD_MODULE;
	PROCEDURE F1(INTEGER X);
	BEGIN
		PROCEDURE FUBAR;
		BEGIN
			OUTSTR("HI"&CVS(X));
		END;

	        FOO(FUBAR);
	END;
	F1;
   END "PRG1"

   Program 2:
   ENTRY FOO;
   BEGIN "PRG2"
	INTERNAL PROCEDURE FOO(PROCEDURE BAZ);
	BEGIN
		BAZ;
	END;
   END "PRG2"
2. FOREACH searches with one ELEMENT ANY and one unbound local sometimes
   returns duplicates of satisfier.

   E. G. if associative store contains:

		A1⊗O1≡V1
		A1⊗O2≡V1
		A1⊗O3≡V1

	FOREACH X | X⊗ANY ≡ V1 DO
		DATUM(X)←DATUM(X)+1;

   The datum of A1 will be incremented by 3, rather than the 1 which is
   expected. Note that this is different than the duplicate satisfiers
   obtained when a list search containing multiple instances of an item
   is used to bind a local. Note that the semantics of

	FOREACH x | x ε LIST1 ∧ A⊗x≡V DO

   is different from the semantics for

	FOREACH x | A⊗x≡V ∧ x ε LIST1 DO

   as the first allows duplications of "x" while the second does not.
3. Calling a procedure with an expression where a reference parameter is
   required (i. e. when a CORTMP must be allocated such as for all
   FORTRAN procedures passed expressions) from within a recursive context
   sometimes fails because the CORTMP is remopped too early (before the ISUCAL)
   used to save some random accumulator.

   E.G.

   BEGIN
	INTEGER PROCEDURE FOO(REFERENCE INTEGER A,B);
		RETURN(A+B);
	RECURSIVE PROCEDURE MUMBLE;
	BEGIN
		INTEGER A,B;
		A ← 2;
		B ← 3;
		A ← (A+B)+FOO(A+0,B);
	END;
	MUMBLE;
   END;

   This particular case will probably not cause very many difficulties as
   a warning message about passing A+0 by reference is given and most
   people would recompile. However if the procedure FOO were a FORTRAN
   procedure no such message would be emitted and the user would have
   no way of knowing he should suspect his results.
4. There is no way to use a derived set simply within a FOREACH context.
   This at least gives an error message to the user when he compiles a
   construct such as:

	FOREACH x | x ε A⊗B DO

   The problem is that RFS made work for
	FOREACH y | A⊗(A⊗B)≡y DO

   It is very difficult to get it to work both ways.

   The same problem exists with bracketed triples within foreaches.
5. ERASES  sometimes cause havoc within foreaches.
	If an association is erased which is pointed to by some SCB
	that pointer should be altered in some way to indicate it
	is no longer valid so that at least an error message can be given
	This is very difficult to handle efficiently because it entails
	a search of every active SCB and in the majority of cases
	this search is for naught. Also some SCB's are hidden on the
	stack such as within make and erase breakpoints.

	Processes add even more hair in finding all the SCB's

6. Changing a set or list variable which is being searched within some encompassing
	FOREACH (dynamic) can sometimes cause the FOREACH interpreter to
	end up searching the free-storage list.


	This can occur when we REMOVE the next item that would have been
	returned, or when we change the value of the variable by assignment.
	
	This is almost impossible to detect without extreme overhead  in
	the set and list assignment code to check each node in the old value
	of the set to see if it is pointed to by some SCB.

	We can always get around this by making a temp set by concatenating a
	nil list or unioning a phi set to copy the list or set variable.
7. PROFIL does not seem to know about CONTINUE's which exit the current
8. Reference variables and global variables kept in ac's cause problems.
   When we pass the same variable to two differrent reference parameters
   SAIL does not realize that it cannot keep track "INAC" property of the
   parameters. Similar problem when pass as reference parameter, a variable
   used globally within the procedure.

   begin "refbug"
	   integer b;
	   procedure refref(reference integer a,b);
	   begin "refref"
		   a ← a+1;
		   b ← b+1;
		   outstr(cvs(a+b)); "here SAIL assumes that A is still valid
				      in the ac, but it was really changed
				      by the assignment to B when A and B
				      are passed the same variable"
	   end;
	   procedure refglb(reference integer a);
	   begin "refref"
		   b ← b+1;
		   a ← a+1;
		   outstr(cvs(a+b)); "here SAIL assumes that A is still valid
				      in the ac, but it was really changed
				      by the assignment to B when B was passed
				      to the procedure as a parameter"
	   end;
	   b ← 0;
	   outstr('15&'12&"SAME ARGUMENTS S/B 4= ");
	   refref(b,b);
	   b ← 0;
	   outstr('15&'12&"ARG SAME AS GLOBAL S/B 4 = ");
	   refglb(b);
	   outstr('15&'12);
   end "refbug"
9. ON "FATAL END OF SOURCE" error message, gives line within page (+1)
   rather than SOS line number.

   Problem is that ASCLIN ( cell which holds ASCII representation of current
   line number ) is updated by EOL code to be BINLIN. Only when a real
   SOS line number (bit 35 on) is read is ASCLIN changed. In the EOF case
   the final line of the file is processed, ASCLIN is changed to BINLIN, but
   no SOS line number is read to overwrite ASCLIN.
10. With /H (HISEG) compilation, own arrays whose virtual origin is before
	the beginning of the rel file. e.g. 

		INTEGER ARRAY FOO[100000:100001];

	are not allowed. This restriction is caused by the way the loader
	decides which relocation factor (hiseg, or lowseg) to use in relocating
	address fields. When the virtual origin of the array is before the beginning
	of the relfile, when used in an instruction it will look like a number
	greater than '400000 rather than a negative number. The loader then
	uses the hiseg relocation amount rather than the low segment one.


	The fix if anyone is willing, is to make such references POLISH fixups.

	e.g.  	movei  2,-3'	; where -3 is virt origin of array

	into    movei  2,1'+-4  ; thus the relocated quantity in the POLISH fixup
				; will be less than '400000 so the correct relocation
				; will be used.
11. IDPB, DPB should do an ALLSTO(?)

 SAIL COMPILER BUG:
 THE FOLLOWING SEQUENCE--
 BP ← POINT (6, FOO, -1);
 FOO ← GEORGE;
 IDPB (0, BP);
 GEORGE ← FOO;
 --  RESULTS IN NO APPARENT CHAGE TO FOO OR GEORGE.
 REASON SEEMS TO BE THAT SAIL 'KNOWS' THAT FOO IS STILL COPIED
 IN AN AC, AND DOESN'T NEED TO   MOVE  AC,FOO   BEFORE MOVEM'ING.
 OH, WELL, I CAN ALWAYS GET AROUND IT.
 
 FROM C. BACON, N.I.H. DCRT.  BETHESDA, MD.  INITIALS CRB.
12. No check is made that the formals to a procedure passed as a parameter
    (an actual to a para