perm filename NTFIXD.WRU[DOC,AIL]2 blob
sn#061544 filedate 1973-09-09 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00008 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 This file contains some descriptions of some known bugs which have not
C00004 00003 1. Calling a parametric procedure whose actual is not in the same file
C00006 00004 2. FOREACH searches with one ELEMENT ANY and one unbound local sometimes
C00008 00005 3. Calling a procedure with an expression where a reference parameter is
C00010 00006 4. There is no way to use a derived set simply within a FOREACH context.
C00011 00007 5. ERASES sometimes cause havoc within foreaches.
C00013 00008 7. PROFIL does not seem to know about CONTINUE's which exit the current
C00014 ENDMK
C⊗;
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) from within a recursive context sometimes fails
because the CORTMP is remopped too early (before the ISUCAL) and is
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