industry. This interest was a direct result of the excitement and interest that the FGCS 
project aroused. 

Some comments on the "Achievements of the FGCS Project" report 

I shall now offer what I hope is some constructive criticism via some comments on this 
short (two page) report that you gave me to look at as part of the evaluation. 

In this report you make several claims which I believe to be true but as yet unproven in the 
eyes of the world outside Japan, a world that is perhaps uncharitably looking for any 
excuse to claim that the project was a failure. 

"Thus, .. (KL1) makes it possible to quickly develop application programs which make full 
use of parallel machines with hundreds to thousands of processors." 

To convince the rest of the skeptical world you have to properly document KL1 and the 
KL1 programming methodogies that you have developed. You have an impressive range 
of applications on display at the exhibition and described in the conference, but the program 
level anatomy of the applications is not adequately described. Programming a large 
application in Prolog is not easy for beginners, programming in any parallel language is 
worse. The LISP or C++ hacker building AI applications will believe that programming in 
a concurrent LP language must be near to impossible. Of course they are wrong, but 
convince these AI application developers that you do have an easy to use language and 
good application development support tools. Describe them much more fully, in clear 
English. Show step by step how to develop a model application. I know that writing such 
documentation is an onerous ask, for which researchers have no appetite. But it needs to 
be done, perhaps by writers skilled in the art of technical documentation who have been 
shown how to use the software, and who are helped in the task by its developers and 
expert users. Your experiments in quickly building highly parallel applications need to be 
repeatable, by people who have not helped develop the technology or been subcontracted 
by ICOT to do it, if the truth of the above claim is to have the impact that it should. 

Doing such documentation is also necessary if the excellent policy of making the software 
freely available is to have any effect. 

Under the time and resource constraints that you had, I do not believe that you could have 
done such documentation before now. Indeed, many of the tools and methodologies 
would only recently have been developed. But please seriously consider doing such 
documentation in the final nine months of the project, or in the first year of a follow up 
project. 

"(Pim) is now providing the most powerful symbol processing capability in the world " 

Again, to be really convincing on this claim you should compare the implementations of 
KL1 and PIMOS on your Pims with an implementation on a standard multiprocessor, 
ideally one that uses a RISC processor. Many are skeptical about the need for special 
purpose processors and language dedicated machines. The LISP machines failed because 
LISP was as fast, or nearly as fast, implemented via a good compiler on a general purpose 
machine. The PSI machines surely do not have a market because the latest Prolog 
compilers, compiling down to RISC instructions and using abstract interpretation to help 
optimize the code, deliver comparable performance. Such compilers run on $5000 
workstations that offer all the other UNIX tools on which many have become to depend. 
Might not clever implementation on standard multiprocessors offer acceptable performance 
for parallel applications developed in KL1 and its extensions. If that is the case, the major 


					- 50 -