pereira@sri-unix.UUCP (03/11/84)
Andrew Taylor says: "C-Prolog design is good but the implementation very crook." I'm afraid the truth is a bit more complicated: 1. It is rather difficult to write a good, elegant and space-efficient Prolog INTERPRETER in anything but Prolog, witness the fact that most Prolog INTERPRETERS are either VERY slow, space-extravagant, or have minimal debugging facilities. I'm speaking here from experience in studying the internals of Prolog systems, my first Prolog adventure being the translation in 1975 of the original Marseille interpreter from FORTRAN to Algol 60. 2. Moral: if you want a good and elegant Prolog interpreter, write first a Prolog compiler and then write the interpreter in Prolog (that's how DEC-10/20 Prolog is built). 3. C is a poor language to implement elegantly and efficiently interpreters for tagged languages like Prolog. 4. The design of C-Prolog is far more of a crock than its implementation (refer to 1. above). The handling of database changes and the metacall call(X) in a structure-sharing system are particularly difficult and error-prone. 5. C-Prolog is a stopgap system, translated into C from IMP (you don't want to know IMP, I assure you...) in two months for a particular project. The original IMP system, imcomplete and crocky as it was, proved to be a much more solid basis than the "elegant" candidates available at the time. C-Prolog was NEVER intended as the ultimate in Prolog implementation, but as a useful local maximum in the effort/benefit curve. C-Prolog has been much improved since the initial implementation in the Summer of 1982, but it has now very nearly reached the limits of the initial design. The goal of C-Prolog was the respectable engineering goal of having a practically useful system available at the right time with the available effort. Not a few people have been able to pursue their particular line of work only because C-Prolog was available when they needed it (while waiting for better & elegant things, of course...) 6. That C-Prolog has become probably the most widespread Prolog system for VAXes comes to show that building a Prolog system that is USEFUL for serious programming (even if not elegantly designed and implemented) is more easily said than done. If anyone has used C-Prolog code (and it is not my business to comment in public on such serious allegations) , it may be that they knew better than Andrew Taylor how much effort they would have to employ to produce a comparable system from scratch, particularly when lacking experience with Prolog implementation. 7. I've seen many people working very hard for years on "better", "more elegant" or "getting rid of the disgusting crocks" Prolog implementations. Like with the witch tower of fairy tales, few are ever much heard of again, and fewer still become useful to a wider community. 8. The point bears repetition: it is a moderately simple exercise to write a minimal elegant Prolog system, but when you start running LARGE programs your elegant toy will soon become useless. 9. As Prolog becomes more seriously used, engineering and economic questions become central in Prolog implementation. This may be distasteful for people concerned with academic elegance, but REALLY elegant solutions in the real engineering world take more than home-brew aesthetics; rather, a hard-earned understanding of engineering tradeoffs and of the best tricks of the trade. 10. The Prolog world has lost its primitive innocence, as it was bound to happen if Prolog became successful. A deep understanding of Prolog implementation is now a very valuable skill, and will be the basis of the best of the coming Prolog products. For academic elegance achievable achievable with academic resources within academic timescales, we would be well advised to look elsewhere... -- Fernando Pereira